分片集群的由来

Redis从单个节点的架构方式演变到主从模式，提高了数据的可靠性以及相对较弱的高可用性；从主从模式到哨兵模式将高可用性提升到了一个新的高地。但是无论是主从还是哨兵模式下的集群，其实都是单个节点在处理客户端的命令，也即是说主节点拥有着所有的数据。那么如果数据量太大就必然会导致内存的暴增。内存较大的情况下，如果对主节点执行RDB全量快照就会使用fork操作，而在fork操作的时候拷贝父线程的内存页就会耗费较长的时间，从而导致父线程被阻塞。此外主节点在并发较高的情况下很容易就会因为网络IO的瓶颈而导致客户端接受较慢【Redis通常不会在CPU上成为性能瓶颈】。

要解决内存和网络IO的问题有两种比较通用的方式：纵向拓展以及横向拓展。纵向拓展意味着提升机器的硬件，如：增加内存条以及配置更高的网卡，但是这通过硬件解决是需要比较高的成本的，而且仍然能是无法解决fork操作导致主线程阻塞的问题。横向拓展指的是将数据量按照一定的分配规则分配到多个主节点中进行处理，一方面每个主节点的内存相对较小，并且可以分担各自的网络IO。这种横向拓展的方式就是Redis-Cluster也叫作分片集群。

基础架构

Redis集群通过分片的方式来保存数据库中的键值对，集群的整个数据库被分为16384个槽(slot),数据库中的每个键都属于这16384个槽的其中一个，集群中的每个节点可以处理0个或最多16384个槽。每一个节点负责维护一部分槽以及槽所映射的键值数据。
下图展示某个包含5个节点的示意图：

当数据库中的16384个槽都有节点在处理时，集群处于上线状态（ok）;相反地，如果数据库中有任何一个槽没有得到处理，那么集群处于下线状态（fail）。

注：集群中每个节点都会传播槽归属信息（传播当前节点处理哪些槽）,让集群中每个节点都持有槽指派的元信息，知道槽位分派在哪个节点

注：为了能快速知道某个槽在哪个节点node上，redis维护了一个槽指派信息在clusterstate.slots数组中

集群的组群过程

集群是由一个个互相独立的节点（readis node）组成的， 所以刚开始的时候，他们都是隔离，毫无联系的。我们需要通过一些操作，把他们聚集在一起，最终才能组成真正的可协调工作的集群。
各个节点的联通是通过 CLUSTER MEET 命令完成的：CLUSTER MEET <ip> <port> 。
具体的做法是其中一个node向另外一个 node（指定 ip 和 port） 发送 CLUSTER MEET 命令，这样就可以让两个节点进行握手（handshake操作） ，握手成功之后，node 节点就会将握手另一侧的节点添加到当前节点所在的集群中。
这样一步步的将需要聚集的节点都圈入同一个集群中，如下图：

集群数据分片原理

现在的Redis集群分片的做法，主要是使用了官方提供的 Redis Cluster 方案。这种方案就是的核心就是集群的实例节点与哈希槽（slots）之间的划分、映射与管理。下面我们来看看他具体的步骤。

哈希槽（slots）的划分

这个前面已经说过了，我们会将整个Redis数据库划分为16384个哈希槽，你的Redis集群可能有n个实例节点，每个节点可以处理0个 到至多 16384 个槽点，这些节点把 16384个槽位瓜分完成。
而你实际存储的Redis键值信息也必然归属于这 16384 个槽的其中一个。slots 与 Redis Key 的映射是通过以下两个步骤完成的：

• 使用 CRC16 算法计算键值对信息的Key，会得出一个 16 bit 的值。
• 将 第1步中得到的 16 bit 的值对 16384 取模，得到的值会在 0 ～ 16383 之间，映射到对应到哈希槽中。

当然，可能在一些特殊的情况下，你想把某些key固定到某个slot上面，也就是同一个实例节点上。这时候可以用hash tag能力，强制 key 所归属的槽位等于 tag 所在的槽位。
其实现方式为在key中加个{}，例如test_key{1}。使用hash tag后客户端在计算key的crc16时，只计算{}中数据。如果没使用hash tag，客户端会对整个key进行crc16计算。下面演示下hash tag使用:

127.0.0.1:6380> cluster keyslot user:case{1}
 (integer) 1024
127.0.0.1:6380> cluster keyslot user:favor
(integer) 1023
127.0.0.1:6380> cluster keyslot user:info{1}
(integer) 1024

哈希槽（slots）的映射

一种是初始化的时候均匀分配 ，使用 cluster create 创建，会将 16384 个slots 平均分配在我们的集群实例上，比如你有n个节点，那每个节点的槽位就是 16384 / n 个了 。

另一种是通过 CLUSTER MEET 命令将 node1、node2、ndoe3、node4 4个节点联通成一个集群，刚联通的时候因为还没分配哈希槽，还是处于offline状态。我们使用 cluster addslots 命令来指定。
指定的好处就是性能好的实例节点可以多分担一些压力。

可以通过 addslots 命令指定哈希槽范围，比如下图中，我们哈希槽是这么分配的：实例 1 管理 0 ～ 7120 哈希槽，实例 2 管理 7121~9945 哈希槽，实例 3 管理 9946 ～ 13005 哈希槽，实例 4 管理 13006 ～ 16383 哈希槽。

redis-cli -h 192.168.0.1 –p 6379 cluster addslots 0,7120
redis-cli -h 192.168.0.2 –p 6379 cluster addslots 7121,9945
redis-cli -h 192.168.0.3 –p 6379 cluster addslots 9946,13005
redis-cli -h 192.168.0.4 –p 6379 cluster addslots 13006,16383

slots 和 Redis 实例之间的映射关系如下：

key testkey_1 和 testkey_2 经过 CRC16 计算后再对slots的总个数 16384 取模，结果分别匹配到了 cache1 和 cache3 上。

为什么槽的个数是16384呢？

Redis采用CRC16算法做hash得到的结果是一个16位的结果，理论上来说可以支持最大的槽数应该是2^16[65536]个。但是如果按照最大的取值来进行计算的话，那么当集群每个节点进行通信的时候，由于每个节点需要把自己所负责的槽告诉其他节点。假设最大的槽数是2^16，那么在内存中记录就需要消耗8KB的内存，那么每次PING和PONG消息就仅仅只是传播自己的槽分配信息就需要8KB的内存,那这个代价就比较大了，难以忍受，因为PING/PONG消息还有节点当前的状态节点个数等其他信息需要携带同步给其他节点。另外，从另一个角度看如果Redis的主节点越多，那么PING/PONG的消息体就越大，就会很容易导致网络拥塞，这也是为什么Redis作者不建议redis cluster节点数量超过1000个，对于1000个节点的集群16384个槽本身也是足够使用的。所以在综合考虑的情况下作者将8K(65536)个槽改为了2K(16384)个槽。

基于重定向的客户端

既然 16384个槽位分别在不同的机器上(数据分布在不同的机器上),那我客户端访问的时候应该访问哪一台机器去尝试操作？又怎么知道数据的分布呢？

其实,当客户端向节点发送与数据库有关的命令的时候，接收到命令的节点会计算出命令要处理的数据库键属于哪个槽，并检查这个槽是否指派给了自己（Redis集群中每个机器 都保存了槽位的信息分布,如果槽位信息变化了,都会以消息的形式进行传播）

• 如果键所在的槽位正好在指派给了当前节点，那么节点直接运行这个命令。
• 如果键所在的槽位并没有指派给当前节点，那么节点回想客户端返回一个MOVED错误，指引客户端转向（redirect）到正确的节点上去，并再次发送之前想要执行的命令

如果在重新分片的时候,槽位键信息正在转移,而我们要访问的键刚好就在这部分转移的部分,那应该怎么访问？

• 访问节点会现在自己的数据库里面查找指定的键，如果找到的话，就直接执行客户端命令
• 如果源节点没能找到在自己的数据库里面找到指定的键，那么这个键可能已经被迁移到了目标节点，源节点将向客户端返回一个ASK错误，指引客户端转向正在导入槽的目标节点，并在此发送之前想要执行的命令

ASK错误和MOVED错误都会导致客户端转向，区别在哪？

（1）MOVED错误代表槽的负责权已经从一个节点转移到了另一个节点：客户端收到关于槽i的MOVED错误之后，客户端每次遇到关于槽i的命令请求时，都可以将命令请求发送到MOVED错误所指向的节点，因为该节点就是目前负责槽i的节点
（2）ASK错误只是两个节点在迁移槽的过程中使用的一种临时措施：在客户端收到关于槽i的ASK错误之后，客户端只会在接下来的一次命令请求中将关于槽i的命令请求发送至ASK错误所指向的节点，这种转向不会对客户端关于槽i的命令请求产生任何影响，客户端仍然会将关于槽i的命令请求发送至目前负责处理槽i的节点，除非ASK错误再次出现

节点间的内部通信机制

1、基础通信原理

（1）redis cluster节点间采取gossip协议进行通信

跟集中式不同，不是将集群元数据（节点信息，故障，等等）集中存储在某个节点上，而是互相之间不断通信，保持整个集群所有节点的数据是完整的
集中式：好处在于，元数据的更新和读取，时效性非常好，一旦元数据出现了变更，立即就更新到集中式的存储中，其他节点读取的时候立即就可以感知到; 不好在于，所有的元数据的跟新压力全部集中在一个地方，可能会导致元数据的存储有压力
gossip：好处在于，元数据的更新比较分散，不是集中在一个地方，更新请求会陆陆续续，打到所有节点上去更新，有一定的延时，降低了压力; 缺点，元数据更新有延时，可能导致集群的一些操作会有一些滞后

（2）10000端口

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

（3）交换的信息

故障信息，节点的增加和移除，hash slot信息，等等

2、gossip协议

gossip协议包含多种消息，包括ping，pong，meet，fail，等等
meet: 某个节点发送meet给新加入的节点，让新节点加入集群中，然后新节点就会开始与其他节点进行通信
redis-trib.rb add-node
其实内部就是发送了一个gossip meet消息，给新加入的节点，通知那个节点去加入我们的集群
ping: 每个节点都会频繁给其他节点发送ping，其中包含自己的状态还有自己维护的集群元数据，互相通过ping交换元数据
每个节点每秒都会频繁发送ping给其他的集群，ping，频繁的互相之间交换数据，互相进行元数据的更新
pong: 返回ping和meet，包含自己的状态和其他信息，也可以用于信息广播和更新
fail: 某个节点判断另一个节点fail之后，就发送fail给其他节点，通知其他节点，指定的节点宕机了

3、ping消息深入

ping很频繁，而且要携带一些元数据，所以可能会加重网络负担
每个节点每秒会执行10次ping，每次会选择5个最久没有通信的其他节点
当然如果发现某个节点通信延时达到了cluster_node_timeout / 2，那么立即发送ping，避免数据交换延时过长，落后的时间太长了
比如说，两个节点之间都10分钟没有交换数据了，那么整个集群处于严重的元数据不一致的情况，就会有问题
所以cluster_node_timeout可以调节，如果调节比较大，那么会降低发送的频率
每次ping，一个是带上自己节点的信息，还有就是带上1/10其他节点的信息，发送出去，进行数据交换
至少包含3个其他节点的信息，最多包含总节点-2个其他节点的信息

数据复制

Cluster 是具备Master 和 Slave模式，Redis 集群中的每个实例节点都负责一些槽位，比如上图中的四个节点分管了不同的槽位区间。而每个Master至少需要一个Slave节点，Slave 节点是通过主从方式同步主节点数据。 节点之间保持TCP通信，当Master发生了宕机， Redis Cluster自动会将对应的Slave节点选为Master，来继续提供服务。与纯主从模式不同的是，主从节点之间并没有读写分离， Slave 只用作 Master 宕机的高可用备份，所以更合理来说应该是主备模式。
如果主节点没有从节点，那么一旦发生故障时，集群将完全处于不可用状态。 但也允许配置 cluster-require-full-coverage参数，及时部分节点不可用，其他节点正常提供服务，这是为了避免全盘宕机。
主从切换之后，故障恢复的主节点，会转化成新主节点的从节点。这种自愈模式对提高可用性非常有帮助。

故障检测

一个节点认为某个节点宕机不能说明这个节点真的挂起了，无法提供服务了。只有占据多数的实例节点都认为某个节点挂起了，这时候cluster才进行下线和主从切换的工作。
Redis 集群的节点采用 Gossip 协议来广播信息，每个节点都会定期向其他节点发送ping命令，如果接受ping消息的节点在指定时间内没有回复pong，则会认为该节点失联了（PFail），则发送ping的节点就把接受ping的节点标记为主观下线。
如果集群半数以上的主节点都将主节点 xxx 标记为主观下线，则节点 xxx 将被标记为客观下线，然后向整个集群广播，让其它节点也知道该节点已经下线，并立即对下线的节点进行主从切换。

主从故障转移

当一个从节点发现自己正在复制的主节点进入了已下线，则开始对下线主节点进行故障转移，故障转移的步骤如下：

• 如果只有一个slave节点，则从节点会执行SLAVEOF no one命令，成为新的主节点。
• 如果是多个slave节点，则采用选举模式进行，竞选出新的Master
  • 集群中设立一个自增计数器，初始值为 0 ，每次执行故障转移选举，计数就会+1。
  • 检测到主节点下线的从节点向集群所有master广播一条CLUSTERMSG_TYPE_FAILOVER_AUTH_REQUEST消息，所有收到消息、并具备投票权的主节点都向这个从节点投票。
  • 如果收到消息、并具备投票权的主节点未投票给其他从节点（只能投一票哦，所以投过了不行），则返回一条CLUSTERMSG_TYPE_FAILOVER_AUTH_ACK消息，表示支持。
  • 参与选举的从节点都会接收CLUSTERMSG_TYPE_FAILOVER_AUTH_ACK消息，如果收集到的选票 大于等于 (n/2) + 1 支持，n代表所有具备选举权的master，那么这个从节点就被选举为新主节点。
  • 如果这一轮从节点都没能争取到足够多的票数，则发起再一轮选举（自增计数器+1），直至选出新的master。
• 新的主节点会撤销所有对已下线主节点的slots指派，并将这些slots全部指派给自己。
• 新的主节点向集群广播一条PONG消息，这条PONG消息可以让集群中的其他节点立即知道这个节点已经由从节点变成了主节点，并且这个主节点已经接管了原本由已下线节点负责处理的槽。
• 新的主节点开始接收和自己负责处理的槽有关的命令请求，故障转移完成。

跟哨兵类似，两者都是基于 Raft 算法来实现的，流程如图所示：

总结

• 哨兵模式已经实现了故障自动转移的能力，但业务规模的不断扩展，用户量膨胀，并发量持续提升，会出现了 Redis 响应慢的情况。
• 使用 Redis Cluster 集群，主要解决了大数据量存储导致的各种慢问题，同时也便于横向拓展。在面对千万级甚至亿级别的流量的时候，很多大厂的做法是在千百台的实例节点组成的集群上进行流量调度、服务治理的。
• 整个Redis数据库划分为16384个哈希槽，Redis集群可能有n个实例节点，每个节点可以处理0个 到至多 16384 个槽点，这些节点把 16384个槽位瓜分完成。
• Cluster 是具备Master 和 Slave模式，Redis 集群中的每个实例节点都负责一些槽位，节点之间保持TCP通信，当Master发生了宕机， Redis Cluster自动会将对应的Slave节点选为Master，来继续提供服务。
• 客户端能够快捷的连接到服务端，主要是将slots与实例节点的映射关系存储在本地，当需要访问的时候，对key进行CRC16计算后，再对16384 取模得到对应的 Slot 索引，再定位到相应的实例上。实现高效的连接。