Redis分布式集群实战（四）——Redis cluster高可用集群的搭建部署

在前面的文章中，我们介绍了redis的主从和哨兵两种集群方案，redis从3.0版本开始引入了redis-cluster(集群)。
从 主从-哨兵-集群可以看到redis的不断完善； 主从复制是最简单的节点同步方案，但无法自动故障转移。 哨兵可以同时管理多个主从同步方案同时也可以处理主从自动故障转移，通过配置多个哨兵节点可以解决单点网络故障问题，但是单个节点的性能压力问题无法解决。 集群解决了前面两个方案的所有问题，下面我们就学习redis cluster。

一、redis集群之redis cluster

对于Redis集群方案有好多种，基本常用的就是twemproxy，codis，redis cluster这三种解决方案。Redis Cluster是Redis官方提供的Redis集群功能

1.1为什么要用Redis Cluster

除了主从复制无法自动故障转移和哨兵无法解决单个节点的性能压力问题外，还有数据量的增加，当现有服务器内存不能满足业务数据的需要时，单纯向服务器添加内存不能达到要求，此时就需要考虑分布式需求，把数据分布到不同服务器上，还有就是网络流量需求，当业务的流量已经超过服务器的网卡的上限值，就需要使用分布式来进行分流。

1.2数据分布

1、 数据分布的目的

全量数据，单机Redis节点无法满足要求，按照分区规则把数据分到若干个子集当中。

2、 常用数据分布方式之顺序分布

顺序分布常用在关系型数据库的设计.
比如：1到100个数字，要保存在3个节点上，按照顺序分区，把数据平均分配三个节点上,1号到33号数据保存到节点1上，34号到66号数据保存到节点2上，67号到100号数据保存到节点3上

3、 常用数据分布方式之哈希分布(虚拟槽分区是Redis Cluster采用的分区方式)

例如1到100个数字，对每个数字进行哈希运算，然后对每个数的哈希结果除以节点数进行取余，余数为1则保存在第1个节点上，余数为2则保存在第2个节点上，余数为0则保存在第3个节点，这样可以保证数据被打散，同时保证数据分布的比较均匀

哈希分布方式分为三个分区方式：

• 节点取余分区：比如有100个数据，对每个数据进行hash运算之后，与节点数进行取余运算，根据余数不同保存在不同的节点上
  
  优点：客户端分片,配置简单：对数据进行哈希，然后取余
  缺点：数据节点伸缩时，导致数据迁移,迁移数量和添加节点数据有关，建议翻倍扩容
  节点取余分区方式有一个问题：即当增加或减少节点时，原来节点中的80%的数据会进行迁移操作，对所有数据重新进行分布，节点取余分区方式建议使用多倍扩容的方式，例如以前用3个节点保存数据，扩容为比以前多一倍的节点即6个节点来保存数据，这样只需要适移50%的数据。数据迁移之后，第一次无法从缓存中读取数据，必须先从数据库中读取数据，然后回写到缓存中，然后才能从缓存中读取迁移之后的数据

• 一致性哈希分区: 原理： 将所有的数据当做一个token环，token环中的数据范围是0到2的32次方,然后为每一个数据节点分配一个token范围值，这个节点就负责保存这个范围内的数据。
  
  对每一个key进行hash运算，被哈希后的结果在哪个token的范围内，则按顺时针去找最近的节点，这个key将会被保存在这个节点上。

在下面的图中，有4个key被hash之后的值在在n1节点和n2节点之间，按照顺时针规则，这4个key都会被保存在n2节点上，
如果在n1节点和n2节点之间添加n5节点，当下次有key被hash之后的值在n1节点和n5节点之间，这些key就会被保存在n5节点上。
在此例子里，添加n5节点之后，数据迁移会在n1节点和n2节点之间进行，n3节点和n4节点不受影响，数据迁移范围被缩小很多，同理，如果有1000个节点，此时添加一个节点，受影响的节点范围最多只有千分之2。
一致性哈希一般用在节点比较多的时候

优点：采用客户端分片方式：哈希 + 顺时针(优化取余)；节点伸缩时，只影响邻近节点，但是还是有数据迁移
缺点：翻倍伸缩

• 虚拟槽分区:预设虚拟槽，每个槽就相当于一个数字，有一定范围。每个槽映射一个数据子集，一般比节点数大。Redis Cluster中预设虚拟槽的范围为0到16383

步骤：

1.把16384槽按照节点数量进行平均分配，由节点进行管理
2.对每个key按照CRC16规则进行hash运算
3.把hash结果对16383进行取余
4.把余数发送给Redis节点
5.节点接收到数据，验证是否在自己管理的槽编号的范围
    如果在自己管理的槽编号范围内，则把数据保存到数据槽中，然后返回执行结果
    如果在自己管理的槽编号范围外，则会把数据发送给正确的节点，由正确的节点来把数据保存在对应的槽中

需要注意的是：Redis Cluster的节点之间会共享消息，每个节点都会知道是哪个节点负责哪个范围内的数据槽
虚拟槽分布方式中，由于每个节点管理一部分数据槽，数据保存到数据槽中。当节点扩容或者缩容时，对数据槽进行重新分配迁移即可，数据不会丢失。
虚拟槽分区特点: 使用服务端管理节点，槽，数据：例如Redis Cluster；可以对数据打散，又可以保证数据分布均匀

二、Redis Cluster基本架构

Redis-Cluster采用无中心结构，每个节点保存数据和整个集群状态,每个节点都和其他所有 节点连接。其redis-cluster架构图如下：

图中描述的是六个redis实例构成的集群

• 6379端口为客户端通讯端口

• 16379端口为集群总线端口

集群内部划分为16384个数据分槽，分布在三个主redis中。
从redis中没有分槽，不会参与集群投票，也不会帮忙加快读取数据，仅仅作为主机的备份。

三个主节点中平均分布着16384数据分槽的三分之一，每个节点中不会存有有重复数据，仅仅有自己的从机帮忙冗余。

2.1 结构特点

1、所有的redis节点彼此互联(PING-PONG机制)，内部使用二进制协议优化传输速度和带宽。

2、节点的fail是通过集群中超过半数的节点检测失效时才生效，只有当集群中的过半节点同时fail整个集群才fail。
3、客户端与redis节点直连，不需要中间proxy层。客户端不需要连接集群所有节点，连接集群中任何一个可用节点即可。
4、redis-cluster把所有的物理节点映射到[0-16383]slot上，cluster 负责维护node<->slot<->value。
5、Redis集群预分好16384个桶，当需要在 Redis 集群中放置一个 key-value 时，根据 CRC16(key) mod16384的值，决定将一个key放到哪个桶中。

2.2 节点分配

假设我们现在有三个主节点，分别是：A, B, C 三个节点，它们可以是一台机器上的三个端口，也可以是三台不同的服务器。那么，采用哈希槽
(hash slot)的方式来分配16384个slot 的话，它们三个节点分别承担的slot 区间是：

节点A覆盖0－5460；
节点B覆盖5461－10922；
节点C覆盖10923－16383

获取数据：

如果存入一个值，按照redis cluster哈希槽的算法： CRC16(‘key’)%16384 = 6782。
那么就会把这个key 的存储分配到 B
上了。同样，当我连接(A，B，C)任何一个节点想获取’key’这个key时，也会这样的算法，然后内部跳转到B节点上获取数据。

新增一个主节点：
新增一个节点D，redis
cluster的这种做法是从各个节点的前面各拿取一部分slot到D上，我会在接下来的实践中实验。大致就会变成这样：

节点A覆盖1365-5460
节点B覆盖6827-10922
节点C覆盖12288-16383
节点D覆盖0-1364,5461-6826,10923-12287

同样删除一个节点也是类似，移动完成后就可以删除这个节点了。

2.3 Redis Cluster主从模式

为了保证数据的高可用性，加入了主从模式，一个主节点对应一个或多个从节点，主节点提供数据存取，从节点则是从主节点拉取数据备份，当这个主节点挂掉后，就会有这个从节点选取一个来充当主节点，从而保证集群不会挂掉。

上面那个例子里，集群有ABC三个主节点,如果这3个节点都没有加入从节点，如果B挂掉了，我们就无法访问整个集群了。A和C的slot也无法访问。

 所以我们在集群建立的时候，一定要为每个主节点都添加了从节点， 比如像这样,集群包含主节点A、B、C,，以及从节点A1、B1、C1，那么即使B挂掉系统也可以继续正确工作。

 B1节点替代了B节点，所以Redis集群将会选择B1节点作为新的主节点，集群将会继续正确地提供服务。 当B重新开启后，它就会变成B1的从节点。

不过需要注意，如果节点B和B1同时挂了，Redis集群就无法继续正确地提供服务了。

三、Redis Cluster搭建

节点准备（官方推荐三主三从的配置方式。）
redis3.0及以上版本实现，集群中至少应该有奇数个节点，所以至少有三个节点，每个节点至少有一个备份节点，所以下面使用6节点（主节点、备份节点由redis-cluster集群确定）。

实验步骤如下所示：

1、设置overcommit_memory为1

• /proc/sys/vm/overcommit_memory，是一个内核对内存分配的一种策略。overcommit_memory取值又三种分别为0， 1， 2。0， 表示内核将检查是否有足够的可用内存供应用进程使用；如果有足够的可用内存，内存申请允许；否则，内存申请失败，并把错误返回给应用进程。1， 表示内核允许分配所有的物理内存，而不管当前的内存状态如何。2， 表示内核允许分配超过所有物理内存和交换空间总和的内存。

2、停掉redis服务（redis服务本身监听的端口是6379端口），创建目录，用于存放redis Cluster对应的节点配置文件

[root@server1 ~]# /etc/init.d/redis_6379 stop
[root@server1 ~]# mkdir /usr/local/rediscluster
[root@server1 ~]# cd /usr/local/rediscluster/
[root@server1 rediscluster]# mkdir 700{1..6}
[root@server1 rediscluster]# ls
7001  7002  7003  7004  7005  7006

3、编写redis Cluster对应的节点的配置文件，并启动redis Cluster对应的所有节点，下面给出的是一个节点7001的配置文件（其余节点的配置文件跟这个配置文件类似，只需要将其中的7001改为对应的节点即可）

[root@server1 rediscluster]# cd 7001/
[root@server1 7001]# vim redis.conf
 port 7001                    
 		#端口
 cluster-enabled yes          
 		#如果是yes，表示启用集群，否则以单例模式启动
 cluster-config-file nodes.conf     
 		#请注意，尽管有此选项的名称，但这不是用户可编辑的配置文件，而是Redis群集节点每次发生更改时自动保留群集配置（基本上为状态）的文件，以便能够 在启动时重新读取它。 该文件列出了群集中其他节点，它们的状态，持久变量等等。 由于某些消息的接收，通常会将此文件重写并刷新到磁盘上。
 cluster-node-timeout 5000     
 		#Redis群集节点超过不可用的最长时间，而会将其视为失败。 如果主节点超过指定的时间不可达，它将由其从属设备进行故障切换。 此参数控制Redis群集中的其他重要事项。 值得注意的是，每个无法在指定时间内到达大多数主节点的节点将停止接受查询。
 appendonly yes     
 		#是否开启appendonlylog，开启的话每次写操作会记一条log，这会提高数据抗风险能力，但影响效率。
 daemonize yes        
 		#打入后台，否则会占用我们的终端
[root@server1 7001]# redis-server redis.conf   #启动7001节点 
[root@server1 7001]# netstat -antlp | grep 7001

在其余目录里面也是一样的操作，记得对应的目录就是文件里面写的端口。

     cp redis.conf ../7002
     cp redis.conf ../7003
     cp redis.conf ../7004
     cp redis.conf ../7005
     cp redis.conf ../7006

在7002目录下：

在7003目录下：

在7004目录下：

在7005和7006目录下：

查看所有端口：

 ps aux | grep 700*

4、创建集群（集群中的主从节点是随机的），节点全部启动后，每个节点目前只能识别出自己的节点信息，彼此之间并不知道对方的存在；实现集群的快速搭建，需要使用redis-cluster来创建集群

[root@server1 ~]# redis-cli --cluster create --cluster-replicas 1 127.0.0.1:7001 127.0.0.1:7002 127.0.0.1:7003 127.0.0.1:7004 127.0.0.1:7005 127.0.0.1:7006   #输入yes
# 使用create命令创建集群 --replicas 1 参数表示为每个主节点创建一个从节点，其他参数是实例的地址集合。

创建过程中会显示出主从节点角色的关系，如下图所示

5、我们可以使用下面的命令，来查看集群的主节点信息等

redis-cli --cluster info 127.0.0.1:7001 

用下面这个命令查看该集群的具体信息

redis-cli --cluster check 127.0.0.1:7001 

6、测试存取值：
客户端连接集群redis-cli需要带上 -c

redis-cli -c -p　　７００１

我们在7004节点获取name值，也是跳转到7002

但是，在7002节点获取name值，就不会跳转，因为本来就存储在7002节点。

四、Redis cluster集群的故障迁移

1、模拟节点7002挂掉：

2、查看集群的信息，可以看到7004节点，接替7002为新的主节点。

此时，我们在节点7001，获取name值，自动跳转到7004节点，仍可以获取name值，服务不受任何影响。

3、此时，如果将7004节点也手动down掉，那么该集群也就费了，因为至少三个master。

4、那如何恢复数据呢？我们进入7004的目录，可以查看数据文件。

查看集群的主节点信息，看到集群已经恢复。

登录7001获取name值，可以获取到，会跳转到7004，只要数据文件没有丢失，我们恢复好master后，依旧可以看到数据。