初探redis：redis集群的数据分区和故障转移

redis 集群

根据之前的诸多分析，我们知道单机的redis有很多的局限性，所以可以使用多台机器来实现分区存储，构建更大的数据库，满足更高的业务需求。

之前我们实现的主从复制，可以实现一主多从的架构，但是抽象来看，其实也只是一个redis架构，只有一个主库实现读写，并不是多主多从的结构，所以我们需要redis集群来分散单台服务器的访问压力，实现负载均衡，同时减轻单机的存储上限，提高扩展性。

单机架构

在redis3.0时，提供了redis cluster来满足集群搭建的需求，可以进行手动搭建，分配节点和节点握手，然后手动分配槽。

同时官方提供了redis-trib.rb的ruby脚本，推荐使用该脚本来实现快速搭建和管理。值得一提的是，单机redis本身是有0-15个数据库的，而集群中每个redis节点只有db0。

集群架构

数据分区

如果是单机存储的话，直接将数据存放在单机redis就行了。但是如果是集群存储，就需要考虑到数据分区了。

数据分区通常采取顺序分布和hash分布。

分布方式	顺序分布	哈希分布
数据分散度	分布倾斜	分布散列
顺序访问	支持	不支持

顺序分布保障了数据的有序性，但是离散性低，可能导致某个分区的数据热度高，其他分区数据的热度低，分区访问不均衡。

哈希分布也分为多种分布方式，比如取余哈希分区，一致性哈希分区等。而redis cluster采用的是虚拟槽分区的方式。

---

虚拟槽分区

redis cluster设置有0~16383的槽，每个槽映射一个数据子集，通过hash函数，将数据存放在不同的槽位中，每个集群的节点保存一部分的槽。

每个key存储时，先经过哈希函数CRC16(key)得到一个整数，然后整数与16384取余，得到槽的数值，然后找到对应的节点，将数据存放入对应的槽中。

---

集群通信

但是寻找槽的过程并不是一次就命中的，比如上图key将要存放在14396槽中，但是并不是一下就锁定了node3节点，可能先去询问node1，然后才访问node3。

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

1. 节点A对节点B发送一个meet操作，B返回后表示A和B之间能够进行沟通。
2. 节点A对节点C发送meet操作，C返回后，A和C之间也能进行沟通。
3. 然后B根据对A的了解，就能找到C，B和C之间也建立了联系。
4. 直到所有节点都能建立联系。

这样每个节点都能互相直到对方负责哪些槽。

集群伸缩

集群并不是建立之后，节点数就固定不变的，也会有新的节点加入集群或者集群中的节点下线，这就是集群的扩容和缩容。但是由于集群节点和槽息息相关，所以集群的伸缩也对应了槽和数据的迁移

---

集群扩容

当有新的节点准备好加入集群时，这个新的节点还是孤立节点，加入有两种方式。一个是通过集群节点执行命令来和孤立节点握手，另一个则是使用脚本来添加节点。

1. cluster_node_ip:port: cluster meet ip port new_node_ip:port
2. redis-trib.rb add-node new_node_ip:port cluster_node_ip:port

通常这个新的节点有两种身份，要么作为主节点，要么作为从节点：

• 主节点：分摊槽和数据
• 从节点：作故障转移备份

其中槽的迁移有以下步骤：

---

集群缩容

下线节点的流程如下：

1. 判断该节点是否持有槽
   • 未持有槽就跳转到下一步
   • 持有槽则先迁移槽到其他节点
2. 通知其他节点（cluster forget）忘记该下线节点
3. 关闭下线节点的服务

需要注意的是如果先下线主节点，再下线从节点，会进行故障转移，所以要先下线从节点。

故障转移

除了手动下线节点外，也会面对突发故障。

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

只有主节点才需要进行故障转移。在之前学习主从复制时，我们需要使用redis sentinel来实现故障转移。而redis cluster则不需要redis sentinel，其自身就具备了故障转移功能。

根据前面我们了解到，节点之间是会进行通信的，节点之间通过ping/pong交互消息，所以借此就能发现故障。

集群节点发现故障同样是有主观下线和客观下线的

主观下线

对于每个节点有一个故障列表，故障链表维护了当前节点接受到的其他所有节点的信息。

当半数以上的持有槽的主节点都标记某个节点主观下线，就会尝试客观下线。

客观下线

---

故障转移

集群同样具备了自动转移故障的功能，和哨兵有些类似，在进行客观下线之后，就开始准备让故障节点的从节点“上任”了。

首先是进行资格检查，只有具备资格的从节点才能参加选举：

• 故障节点的所有从节点检查和故障主节点之间的断线时间
• 超过cluster-node-timeout * cluster-slave-validati-factor(默认10)则取消选举资格

然后是准备选举顺序，不同偏移量的节点，参与选举的顺位不同。

offset最大的slave节点，选举顺位最高，最优先选举。而offset较低的slave节点，要延迟选举。

当有从节点参加选举后，主节点收到信息就开始投票。偏移量最大的节点，优先参与选举就更大可能获得最多的票数，称为主节点。

当从节点走马上任变成主节点之后，就要开始进行替换主节点：

1. 让该slave节点执行slaveof no one变为master节点
2. 将故障节点负责的槽分配给该节点
3. 向集群中其他节点广播Pong消息，表明已完成故障转移
4. 故障节点重启后，会成为new_master的slave节点

集群的读写分离

在集群模式下的从节点是只读连接的，也就是说集群模式中的从节点是拒绝任何读写请求的。当有命令尝试从slave节点获取数据时，slave节点会重定向命令到负责该数据所在槽的节点。

为什么说是只读连接呢？因为slave可以执行命令：readonly，这样从节点就能读取请求，但是这只是在这次连接中生效。也就是说，当客户端断开连接重启后，再次请求又变成重定向了。

集群模式下的读写分离更加复杂，需要维护不同主节点的从节点和对于槽的关系。

通常是不建议在集群模式下构建读写分离，而是添加节点来解决需求。不过考虑到节点之间信息交流带来的带宽问题，官方建议节点数不超过1000个。

单机？集群？

集群并不是最优选，而是根据不同的业务需求来判断是否搭建集群，当较小的业务利用单机redis和redis sentinel就能满足需求时，不需要强行搭建集群。

集群也有部分限制：

• redis事务操作的key必须在一个节点上
• 批量操作如mset、mget必须在一个槽里
• 只有一个数据库db0
• 有些命令无法跨节点，如scan、flush、keys
• 更难以维护

所以集群搭建还要考虑单机redis是否已经不能满足业务的并发量，在redis sentinel同样能够满足高可用，且并发并未饱和的前提下，搭建集群反而是画蛇添足了。