Redis Cluster集群架构部署实现及节点的扩容和缩容

redis通过主从或者哨兵机制确实解决了单点失败问题，但是写操作都只发生在master节点，而master节点只有一个，写性能没有提升，因此，在大量的高并发场景下主从加上哨兵机制是支撑不了的，所以我们需要redis cluster来解决这个问题，

redis cluster是3.0之后推出的一个技术，也就是相对偏后的一个技术，它可以很好的提升redis集群写操作的性能，也能保证服务的高可用，redis cluster的实现方案是基于所谓分布式的集群解决方案，所谓分布式就是数据不是放在单一的一个主机上，而是把数据分片或者是切割成多个部分，每个部分放在不同的服务器上，总体来讲，每个主机只承担了一部分数据，自然也只是承担了一部分用户的访问，每个主机的负荷自然也就减轻了，从而，对外就可以提供更好的性能

当然分布式还要解决数据访问的位置问题，存在一个寻找数据的问题，早期在redis cluster之前有一些第三方公司开发了一些redis分布式解决方案，比如客户端分区，写数据由客户端来提前约定数据的存放位置，这样的话对客户端的要求比较高，需要提前约定好，这种方式也存在一个问题，如果某个主机故障，会造成数据丢失，为了容错，我们应该增加从节点，哨兵机制加主从可以解决这个问题，但是这是独立的集群，每个集群之间没有联系，毫不相干，还有代理机制，通过第三方软件来解决，客户端通过代理机制作为媒介去访问redis，代理手机客户端的请求，通过代理机制的vip调度到后端redis服务器，不过这个代理机制不是redis官方推出，为第三方软件，例如codis，twemproxy

而redis cluster彻底的解决了这些问题，不需要设代理，无中心架构的redis cluster机制，在无中心的redis集群当中其每个节点保存当前节点数据和整个集群状态每个节点都和其他所有节点连接，类似ping的机制探测每个节点的健康性，如果某个节点失效是由整个集群中超过半数的节点检测都失效（类似于sentinel的投票机制），才能算真正的失效，客户端不需要proxy而是提供了API开发接口即可连接redis，应用程序需要配置所有redis服务器的IP，具体连接哪个由其决定，redis cluster把所有的redis node平均映射到0-16383个槽位上，也就是说把所有数据平均分成了16384份，把16384分数据再平均分配到redis节点上，因此有多少个redis node相当于redis并发扩展了多少倍，节点越多，每个服务器分配的槽位就越少，每个主机的负担就减轻很多，负载均衡，总体的性能就会得到改善，当需要在redis集群中写入一个key-value的时候，会利用CRC16的哈希运算得出一个哈希值对16384取模，决定key写入值应该放在哪个槽位哪个节点上，从而有效的解决单机瓶颈问题。

！注意：集群中的 master节点须是奇数个，偶数容易形成脑裂。

Redis cluster集群架构详解

假设有三个节点来存放槽位，每个节点承担三分之一的槽位数，即A节点覆盖0-5460，B节点覆盖5461-10922，C节点覆盖10923-16383，当用户访问某一个数据时，会根据哈希算法得出的哈希值判断数据所在的槽位位置，实现数据的分布式存放管理，为了避免节点的单点问题，配合主从复制来同步数据，实现redis的高可用。

Redis cluster集群通信

Redis cluster寻找槽位的过程并不是一次命中，如上图，并不是一次就能找到数据，可能先去询问nodeA，然后再访问nodeB，nodeC

而集群中节点之间的通信，保证了最多两次就能命中对应槽位所在的节点，因为在每个节点中，都保存了其他节点的信息，知道哪个槽位由哪个节点负责，这样即使第一次访问没有命中槽位，但是会通知客户端，该槽位在哪个节点，这样访问对应节点就能精准命中。

节点A对节点B发送一个meet操作，B返回后表示A和B之间能够进行沟通

节点A对节点C发送meet操作，C返回后表示A和C之间能够进行沟通

然后B根据对A的了解，就能够找到C，B和C 之间也建立了联系

直到所有节点都能建立联系，这样每个节点就能够互相知道对方都负责哪些槽位

Redis cluster集群的扩容和缩容

集群并不是建立之后节点就固定不变了，将来有必要的情况下可以增加新节点或者更换节点，如果某个节点有故障可以选择使其下线，但是需要把其故障节点负责的槽位平均分配到其他节点上，扩容的话，把节点加入到集群中，同样也存在类似的一个过程，把其他节点的槽位分配给新节点一些，使其与其他节点的槽位平均。

迁移过程如下：

通知目标节点准备接受数据的槽位—>通知源节点准备输出槽位-->获取源节点槽位中的数据—>迁移数据-->循环迁移数据直至全部迁完-->分配槽位并通知目标节点

故障转移

除了主观下线以外，也会面对突发故障，主要是主节点故障，因为从节点故障并不影响主节点工作，对应的主节点只会记住自己哪个节点下线了，并将信息发送给其他节点，故障的从节点重连后，继续官复原职，复制主节点的数据

只有主节点才需要故障转移，之前可以通过sentinel哨兵机制来实现故障转移，而Redis cluster不需要sentinel哨兵机制，自己就具备故障转移的功能

主观下线是一个节点认为down机了，客观下线是所有节点半数以上认为其down机了，那么主节点客观下线之后，其从节点都有资格成为新的主节点，会有一个选举的过程，只有具备资格的从节点才能参加选举，首先检查从节点和故障节点之间的断线时间，超过cluster-node-timeout的值（默认为10）则会取消选举资格，说明连接时间较长，相对其他节点同步数据差异较大，集群则会自动排除其选举资格，offset的值越大说明同步数据越全，则会取得优先选举资格。

Redis cluster架构部署

集群节点

10.0.0.8（redis5.0.3 node1）

10.0.0.18（redis5.0.3 node2）

10.0.0.28（redis5.0.3 node3）

10.0.0.38（redis5.0.3 node4）

10.0.0.48（redis5.0.3 node5）

10.0.0.58（redis5.0.3 node6）