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同样能够满足高可用，且并发并未饱和的前提下，搭建集群反而是画蛇添足了。