redis3.0以前的版本要实现集群一般是借助哨兵sentinel工具来监控master节点的状态，如果master节点异常，则会做主从切换，将某一台slave作为master，哨兵的配置略微复杂，并且性能和高可用等方面变现一般，特别是在主从切换的瞬间存在访问瞬断的情况，而且哨兵模式只有一个主节点对外提供服务，没法支持很高的并发，且单个主节点内存也不宜设置的过大，否则会导致持久化文件过大，影响数据恢复或主从同步的效率。

        redis3.0以后推出了高可用集群模式redis cluster。

 redis cluster集群是一个由多个主从节点集群组成的分布式服务集群，它具有复制、高可用和分片特性。cluster集群不需要sentinel 哨兵也能完成节点移除和故障转移的功能。需要将每个节点设置成集群模式，这种集群模式没有中心节点，可水平扩展，根据官方文档称可以线性扩展到上万个节点(官方推荐不超过1000个节点)。cluster集群的性能和高可用性均优于之前的哨兵模式，且配置非常简单。

redis cluster高可用集群搭建：

redis集群需要至少三个master节点，我们这里搭建三个master节点，并且给每个master再搭建一个slave节点，总共6个redis节点，搭建集群步骤如下：

三个主节点：6382、6383、6384

三个从节点：6385、6386、6387

step1:在redis-5.0.3文件夹下新建文件夹cluster，在cluster中新建6382、6383、6384、6385、6386、6387六个文件夹

将上篇文章中用到的redis.conf配置文件copy到6382下，修改下面内容：

• daemonize yes
• port 6382
• pidfile  /var/run/redis_6382.pid
• dir  /usr/local/redis-cluster/6382/
• cluster-enabled yes #启动集群模式
• cluster-config-file  nodes-6382.conf  #这里名字随便，最好就是node-端口.conf
• cluster-node-timeout 10000
• #bind 127.0.0.1
• protected-mode no #关闭保护模式
• appendonly yes

#如需设置密码需要增加如下配置：

• requirepass  123456 #设置redis访问密码
• masterauth  123456 #设置集群节点间访问密码

step2:将6382下的redis6382.conf复制到6383、6384文件夹下，修改相关配置

 step3:将6382下的redis6382.conf复制到6385、6386、6387三台从机文件夹下，修改同上

 step4：分别启动6个redis实例，然后检查是否启动成功

step5：用redis-cli创建整个redis集群(redis5之前版本集群是依靠ruby脚本redis-trib.rb实现的)

 src/redis-cli -a 123456 --cluster create --cluster-replicas 1 116.62.71.39:6382 116.62.71.39:6383 116.62.71.39:6384 116.62.71.39:6385 116.62.71.39:6386 116.62.71.39:6387

注意： --cluster create --cluster-replicas 1  这里面的1表示为每个主服务器创建一个从服务器

       

 可以看到6382、6383、6384是主机，其余三个是从机

step6：验证集群

连接任意一个客户端：src/redis-cli -a -c -h -p (-a访问服务端密码，-c表示集群，指定ip和端口)

例如：src/redis-cli -a 123456 -c -h ip -p 6382

 查看集群信息：cluster info

 查看节点列表：cluster nodes  可以看到主从关系

 set数据验证：

 

注意：关闭集群需要逐个redis进行关闭

例如：src/redis‐cli ‐a 123456 ‐c ‐h 192.168.0.60 ‐p 6382 shutdown

src/redis‐cli ‐a 123456 ‐c ‐h 192.168.0.60 ‐p 6383 shutdown

src/redis‐cli ‐a 123456 ‐c ‐h 192.168.0.60 ‐p 6384 shutdown 等等逐个关闭

Java操作redis集群：待补充：01：05

Redis cluster集群原理分析：

        redis cluster将所有数据划分为16384个 slots(槽位)，每个节点负责其中一部分槽位。槽位信息存储于每个节点中。

        当redis cluster的客户端来连接集群时，它也会得到一份集群的槽位配置信息并将其缓存到客户端本地。这样当客户端要查找某个key时，可以直接定位到目标节点，同时因为槽位的信息可能会存在客户端与服务器不一致的情况，还需要纠正机制来实现槽位信息的校验调整。

槽位定位算法：cluster 默认会对key值使用crc16算法进行hash得到一个整数值，然后用这个整数值对16384进行取模来得到具体槽位 HASH_SLOT=CRC16(key)  mod  16384

 

 可以看到对key为name1进行计算出来的结果是相同的

跳转重定位：当客户端向一个错误的节点发出了指令，该节点会发现指令的key所在的槽位并不归自己管，这时它会向客户端发送一个特殊的跳转指令携带目标操作的节点地址，告诉客户端去连接这个节点获取数据。客户端收到指令后除了跳转正确的节点上去操作，还会同步更新纠正本地的槽位映射表缓存，后续所有key将使用新的槽位映射表。

 Redis集群节点间的通信机制：redis cluster节点间采取gossip协议进行通信

gossip通信的10000端口：redis cluster每个节点都有一个专门用于节点间gossip通信的端口，就是自己提供服务的端口号+10000，比如6379，那么用于节点间通信的就是16379端口。每个节点每隔一段时间就会往另外几个节点发送ping消息，同时其他节点收到ping消息后返回pong信息。

网络抖动：为了解决网络抖动导致的集群节点之间突然不可访问，然后很快又恢复正常的情况，cluster提供了一个配置 cluster-node-timeout ,表示当某个节点持续timeout时间失联时才认定该节点故障然后进行选举新的主节点。

redis cluster集群选举原理：当slave发现自己的master变为FAIL状态时，便尝试进行Failover，以期成为新的master ,由于挂掉的master可能会有多个slave，从而存在多个slave竞争成为master节点的过程，过程如下：

1、salve发现自己的master变为了FAIL

2、将自己记录的集群currentEpoch加1，并广播FAILOVER_AUTH_REQUEST信息

3、其他节点收到该信息，只有master响应，判断请求者的合法性，并发送FAILOVER_AUTH_ACK，对每一个epoch只发送一次ack

4、尝试failover的salve收集master返回的FAILOVER_AUTH_ACK

5、salve收到超半数master的ack后变成新的master（这也是集群需要至少三个主节点原因）

6、salve成为master后广播消息通知其他节点

注意：从节点并不是在主节点一进入FAIL状态就马上尝试进行选举，而是有一定延迟，一定的延迟确保我们等待FAIL状态在集群中传播，salve如果立即尝试选举的话其他master或许尚未意识到FAIL状态，可能拒绝投票。

延迟计算公式：DELAY = 500ms + random(0 ~ 500ms) + SLAVE_RANK * 1000ms

SLAVE_RANK表示此slave已经从master复制数据的总量的rank。Rank越小代表已复制的数据越新。这种方 式下，持有最新数据的slave将会首先发起选举（理论上）。

集群脑裂数据丢失问题：redis集群没有过半机制会有脑裂问题，网络分区导致脑裂后多个主节点对外提供写服务，一旦网络分区恢复，会将其中一个主节点变为从节点，这时会有大量数据丢失。

规避方法可以在redis配置里加上参数 min‐replicas‐to‐write 1 表示写数据成功最少同步的slave的数量，当然这个配置会一定程度上影响集群的可用性，比如slave要是少于1个，这个集群就算leader正常也不能提供服务了，需要根据场景权衡。