Redis Cluster集群的实现原理

一、 Redis Cluster架构

Redis Cluster是Redis在3.0版本推出的分布式解决方案。Redis Cluster由多个Redis节点组成。不同节点之间数据无交集，每个节点对应多个数据分片。节点内部分为主备节点，通过主备复制的方式保证数据的一致性。一个主节点可以有多个从节点，主节点提供读写服务，从节点提供读服务。

1.1 内部通信机制

Redis Cluster各节点之间通过Redis Cluster Bus交互信息。Redis Cluster每个节点都会记录集群的配置信息：如信息版本号Epoch、集群状态State等数据。
 
  Redis Cluster的每个节点都保存着Node视角的集群结构。它描述了数据的分片方式，节点主备关系，并通过Epoch作为版本号实现集群结构信息的一致性，同时控制着数据迁移和故障转移的过程。
 
1.2 Redis Cluster去中心化
 在Redis Cluster中，原则上每个主节点都有一个或多个Slave节点。集群中所有的Master节点都可以进行读写数据，不分主次。每个主节点与从节点间通过Goossip协议内部通信，异步复制。但是异步复制会导致某些特定情况下的数据丢失。所以，Redis Cluster不能保证数据的强一致性。

Redis Cluster设计的核心思想：数据拆分、去中心化。

二、 Redis Cluster数据分片

2.1 数据分片规则

在分布式集群中，如何保证相同请求落到相同的机器上，并且后面的集群机器可以尽可能的均分请求，需要使用合理的策略，有两种传统的方法：
1、哈希算法：采用固定节点数量，当某一节点宕机，缓存重建。
2、一致性哈希算法：当某一结点宕机，只有此节点数据受影响。会将压力压到数据库。
  Redis Cluster使用的时hash slot算法通过采用固定节点数量和可配置映射节点，来避免取模的不灵活性和一致性哈希的部分影响。
  Redis Cluster将所有数据按照hash slot算法分布到16384[0-16383]个哈希槽上面，哈希槽分布在各节点上，各节点维护自己的哈希槽。

2.2 客户端路由

当Client访问的Key不在当前节点的哈希槽中时，Redis Cluster会返回moved命令，并告知正确路由信息。当Client接收到moved命令时，会再次请求Redis并更新其内部路由缓存信息。
 
  当Redis Cluster在数据重新分布时，Redis Cluster会使用ask命令用于重定向。因为在数据重新分布时，某个哈希槽的数据可能同时存在于新旧两个节点。所以ask只会重定向，并不会更新路由信息。

2.3 数据分片迁移

当有新主节点加入集群中、从集群中移除节点或者因数据分布不均衡时需要数据重新分布时，就需要对数据分片的迁移。数据迁移分为三个步骤：
1、向目标节点发送状态变更命令，将目标节点的对应哈希槽状态置为importing。
2、向源节点发送状态变更命令，将源节点对应的哈希槽状态置为migrating。
3、针对源节点上的哈希槽的所有key，向源节点发送migrate命令，告知源节点将对应的key迁移到目标节点。
  当源节点的状态置为migrating后。此时源节点提供的服务和通常状态下有所区别：
1、如果Client访问的key尚未迁出，则正常的处理该key；
2、如果key已经迁出或者key不存在，则回复Client ASK，信息让其跳转到目标节点处理；
  当目标节点状态变成importing后。表示对应的slot正在向目标节点迁入。目标节点和通常情况下有所区别：
1、对于该slot上所有非ask跳转的操作，目标节点不会进行操作，而是通过moved让Client跳转至源节点执行。这样就保证了同一个key在迁移之前总是在源节点执行。迁移后总是在目标节点执行，从而杜绝了双写的冲突。
2、迁移过程中，新增加的key会在目标节点执行，源节点不会新增key。使得迁移有界限，可以在某个确定的时刻结束。

单个key的迁移过程可以通过原子化的migrate命令完成。对于源节点和目标节点的从节点，是通过主备复制，从而达到增删数据。当所有key迁移完成后，Client 通过Redis Cluster的setslot命令设置目标节点的分片信息，从而包含了迁入的slot。设置过程中会让Epoch自增，并且是Cluster中的最新值。然后通过相互感知，传播到Cluster 中的其他节点。

三、Redis Cluster故障转移

3.1 节点故障判断
  首先，在Redis Cluster中每个节点都存有集群中所有节点的信息。它们之间通过互相ping-pong判断节点是否可以连接。如果有一半以上的节点去ping一个节点的时候没有回应，集群就认为这个节点宕机。

3.2 slave选举
  当主节点被集群公认为fail状态，那么它的从节点就会发起竞选，如果存在多个从节点，数据越新的节点越有可能发起竞选。集群中其他主节点返回响应信息。

3.3 结构变更
  当竞选从节点收到过半主节点同意，便会成为新的主节点。此时会以最新的Epoch通过PONG消息广播，让Redis Cluster的其他节点尽快的更新集群信息。当原主节点恢复加入后会降级为从节点。

四、Redis Cluster高可用性

4.1 主节点保护
  当集群中某节点中的所有从实例宕机时，Redis Cluster会将其他节点的非唯一从实例进行副本迁移，成为此节点的从实例。
  这样集群中每个主节点至少有一个slave，使得Cluster 具有高可用。集群中只需要保持 2*master+1 个节点，就可以保持任一节点宕机时，故障转移后继续高可用。

4.2 集群fail条件
  Redis Cluster保证基本可用的特性，在达到一定条件时才会认定为fail：
1、某个主节点和所有从节点全部挂掉，则集群进入fail状态。
2、如果集群超过半数以上主节点挂掉，无论是否有从节点，集群进入fail状态。
3、如果集群任意主节点挂掉,且当前主节点没有从节点，集群进入fail状态。

本文转自：https://yq.aliyun.com/articles/711825