1. 为什么要有集群

随着业务规模增长，存储在Redis的业务数据规模和访问QPS也会随着变大，。为了应对业务增长，最直接的方式就是换配置更高的机器(更大的内存更强的计算能力)。但是这种纵向扩容的方法存在诸多不足:

执行卡顿: 在fork 后台子进程时可能会引起卡顿(进程页表复制)。
复制延迟: 主从复制的带宽压力加大,从服务器的复制延迟可能上升。
数据集同步耗时: 当节点故障时,主服务器完成全数据集复制到其它从服务器,时间会更长。
恢复耗时: 发生 crash 后,重启和加载数据集到内存的恢复时间会更久。
机器无法无限升级: 单机内存容量、计算处理能力和存储容量无法无限扩容
资源利用率低 : 机器配置升级(内存变大, cpu核数增加)，核心主线程只使用单核，无法有效使用cpu。
资源预算: 随着内存增大,计算和网络带宽成本会上升,需要考虑整体 IT 资源预算。
运维难度: 运维大内存实例的复杂度和难度增加,需要优化监控方案。

为了应对这一挑战,Redis推出了Cluster集群模式。Redis Cluster实现了数据和请求的水平分片,将大规模数据集分布到多个节点上,并实现高可用的自动failover。这使得Redis能通过简单地添加更多节点来达到存储容量和处理能力的线性扩展。相比单机限制,Redis Cluster实现了在处理能力、存储容量、网络带宽等多个维度的无缝水平扩展。这为Redis处理海量KEY以及提供高并发访问提供了 POSSIBILITY。因此,Cluster集群模式成为应对大数据量和高访问流量场景的必然选择。

2. 集群工作机制

Redis Cluster 的工作机制主要包含以下几个方面:

2.1 数据分片与数据访问

数据分片

Redis Cluster 将整个数据库分散到多个节点上,每个节点负责存储部分key。具体的分片方式是通过哈希槽实现的。

Redis Cluster分为16384个哈希槽管理数据(0~16383)
计算key的crc16值 val, 再通过 val&16383 决定key属于哪个哈希槽管理
每个节点负责存储部分哈希槽数据

请求路由

客户端通过向集群任意一个节点 cluster nodes获取哈希槽分布信息(也称路由信息, 槽在哪些节点上以及节点的ip和端口)
在发起具体数据请求时，计算key属于那个哈希槽; 再根据路由信息可知需要访问的具体节点; 最后访问节点执行命令

请求重定向

假如key(槽) 已经由新节点负责, 客户端路由信息未及时更新，, 即不负责槽的节点返回 MOVED新节点ip新节点端口回复包
客户端收到回复包后链接新节点访问key, 并且拉取更新路由信息

2.2 主从复制与故障转移

主从复制

为保证高可用性,每个主节点都由一个或多个从节点进行复制。如果主节点故障,从节点可以快速进行主从切换。

故障转移

集群节点使用心跳机制互相检测,如果主节点失联,从节点可以快速接替成为新的主节点。

节点ip1故障宕机
节点ip3发送ping消息给节点ip1 超过clusternodetimeout(可配置), 认为ip1 为pfail
节点ip3 收到节点ip5 的ping消息, p5也认为ip1为pfail, 此时符合集群大于1/2的主节点认为ip1节点pfail, 即ip 为fail, 并且消息广播给集群所有节点
ip2收到自己主节点fail 状态，发起failover(主从切换) 投票
ip3 和 ip5 收到投票请求，发送ack消息同意ip2 切换
ip2 收到ack, 发现大部分主节点同意它切换, 变更原来ip1负责的槽为ip(自己)负责; 并且广播upate消息通知所有节点, 切换成功

2.3 在线伸缩

可以动态添加和删除节点,数据集会自动在节点间重新分片,实现存储和计算的弹性扩容。Redis Cluster 动态添加节点的主要流程如下:

新增主节点

新增空节点: 启动新的Redis实例,作为空白节点加入集群。
主节点分配哈希槽: 根据主节点数量,对已有主节点的哈希槽进行再平衡, 计算出分配到新主节点的哈希槽。
数据迁移: 拥有目标槽的主节点会将这些槽对应的数据迁移到新加入的主节点(cluster setslot, migrate, restore-asking命令 )。
客户端感知: 客户端缓存了哈希槽映射信息,需要刷新从集群节点获取最新配置。