Redis Cluster模式

Redis集群模式是Redis提供的分布式解决方案，允许数据自动分片到多个节点，并提供一定程度的高可用性和故障转移能力。

集群模式特点

• 数据自动分片：数据自动分布到多个节点
• 去中心化：无中心节点，所有节点地位平等
• 高可用性：部分节点故障时集群仍能继续工作
• 自动故障转移：主节点故障时自动选举从节点接管
• 水平扩展：可以动态添加节点扩展集群容量

集群模式架构

架构图解读

这个架构图展示了Redis集群的基本结构，让我们来详细了解一下：

整体布局：

• 最上面是客户端，它可以连接到集群中的任何一个节点
• 中间是Redis集群，包含了6个节点，分为主节点和从节点两组

主节点的作用：

• 三个主节点（节点1、2、3）是集群的核心，它们负责处理所有的写操作
• 每个主节点负责一部分哈希槽：节点1管理0-5460槽，节点2管理5461-10922槽，节点3管理10923-16383槽
• 这样总共16384个槽就被平均分配给了三个主节点

从节点的职责：

• 三个从节点（节点4、5、6）分别复制对应的主节点数据
• 从节点主要处理读请求，减轻主节点的压力
• 当主节点故障时，从节点可以被提升为新的主节点

通信机制：

• 所有节点之间都通过集群总线进行通信，交换集群状态信息
• 主从节点之间有专门的数据同步连接，保证数据一致性
• 客户端可以连接到任何节点，如果数据不在当前节点，会被重定向到正确的节点

集群数据分片原理

数据分片原理解读

这个时序图展示了Redis集群如何处理客户端请求和数据分片的过程：

分片的基本原理：

• 当客户端发送一个SET命令时，集群需要决定这个键应该存储在哪个节点上
• Redis使用CRC16算法计算键名的哈希值，然后对16384取模，得到一个0-16383之间的槽位号
• 每个主节点负责一定范围的槽位，通过槽位号就能确定数据应该存储在哪个节点

请求处理流程：

1. 直接命中：如果计算出的槽位正好在当前节点负责的范围内，节点直接执行命令并返回结果
2. 重定向：如果槽位不在当前节点，节点会返回一个MOVED错误，告诉客户端应该去哪个节点
3. 客户端重试：客户端收到重定向信息后，会自动连接到正确的节点重新发送命令

这种设计的好处：

• 数据分布均匀：通过哈希算法保证数据在各个节点间均匀分布
• 客户端智能：客户端会学习并缓存槽位映射，减少重定向次数
• 扩展性好：添加或删除节点时，只需要重新分配部分槽位

集群节点通信原理

节点通信原理解读

这个时序图详细展示了Redis集群中节点之间是如何通信和协作的：

Gossip协议通信：

• 集群中的节点通过Gossip协议进行通信，这是一种去中心化的信息传播方式
• 每个节点定期向其他节点发送PING消息，不仅用于检测节点是否存活，还携带部分集群状态信息
• 收到PING的节点会回复PONG消息，同样包含自己知道的集群状态信息
• 通过这种方式，集群状态信息会逐渐在所有节点间传播和同步

主从数据同步：

• 主节点会持续向从节点同步数据变更
• 从节点定期发送REPLCONF ACK确认收到的数据，保证数据同步的可靠性

故障检测机制：

• 当节点A向节点B发送PING但没有收到回复时，A会将B标记为PFAIL（疑似故障）
• A在后续与其他节点的通信中会包含B的PFAIL信息
• 当节点C也检测到B无响应时，C也会将B标记为PFAIL
• 当A收集到足够多的PFAIL报告时，会将B标记为FAIL（确认故障）
• 然后A会向集群中的其他节点广播B的FAIL状态

这种设计的优势：

• 去中心化：没有单点故障，任何节点都可以参与故障检测
• 容错性强：需要多个节点确认才会判定故障，避免网络抖动造成的误判
• 信息传播快：通过Gossip协议，故障信息能快速传播到整个集群

集群故障转移流程

故障转移流程解读

这个时序图展示了Redis集群中主节点故障时的完整故障转移过程：

故障检测阶段：

• 当主节点B发生故障时，其他节点（A和C）会通过PING超时检测到问题
• 各个节点先将B标记为PFAIL（疑似故障），然后通过节点间通信确认故障
• 当收集到足够的PFAIL报告后，节点们会将B标记为FAIL（确认故障）
• 故障信息会广播给所有节点，包括B的从节点

从节点选举阶段：

• B的从节点（B1和B2）检测到主节点已经FAIL后，开始竞选新的主节点
• 每个从节点会延迟一个随机时间，避免同时发起选举
• 先发起选举的从节点（这里是B1）向其他主节点发送FAILOVER_AUTH_REQUEST请求选票
• 其他主节点（A和C）会投票支持，发送FAILOVER_AUTH_ACK
• 获得多数选票的从节点（B1）当选为新的主节点

角色转换阶段：

• 新当选的主节点B1提升自己的角色，接管原主节点B负责的所有哈希槽
• B1向集群中的所有节点发送PONG消息，通知自己的新角色和负责的槽位信息
• 其他节点更新自己的集群状态，认可B1的新角色
• 原来的另一个从节点B2成为B1的从节点，开始从B1同步数据

客户端适应阶段：

• 客户端如果还向原来负责该槽位的节点发送请求，会收到MOVED重定向
• 客户端会更新自己的槽位映射表，后续请求直接发送给新的主节点B1

整个过程的特点：

• 自动化：整个故障转移过程无需人工干预
• 快速：通常在几秒钟内完成
• 一致性：确保数据不丢失，服务快速恢复

集群模式启动流程

集群启动流程解读

这个流程图展示了从零开始搭建Redis集群的完整过程：

准备阶段：

• 首先需要准备多个Redis实例，通常至少需要6个节点（3主3从）来保证高可用性
• 每个节点都需要单独的配置文件，设置不同的端口和数据目录

配置阶段：

• 在每个节点的配置文件中启用集群模式（cluster-enabled yes）
• 设置集群配置文件路径、节点超时时间等集群相关参数
• 这一步很关键，没有正确配置集群模式的节点无法加入集群

启动阶段：

• 启动所有配置好的Redis节点
• 此时各个节点都是独立运行的，还没有形成集群

集群创建阶段：

• 使用redis-cli的--cluster create命令来创建集群
• 命令中需要指定所有节点的地址，以及每个主节点对应的从节点数量
• 例如：redis-cli --cluster create 127.0.0.1:7000 127.0.0.1:7001 ... --cluster-replicas 1

槽位分配阶段：

• 系统会自动将16384个哈希槽平均分配给各个主节点
• 比如3个主节点，每个节点大约分配5461个槽位

主从关系建立：

• 根据--cluster-replicas参数，为每个主节点分配指定数量的从节点
• 从节点会自动开始复制对应主节点的数据

节点握手阶段：

• 各个节点之间交换集群状态信息，建立集群总线连接
• 每个节点都会知道其他节点的角色、负责的槽位等信息

完成初始化：

• 当所有节点都完成握手，集群状态变为正常后，集群就可以开始对外提供服务了

整个过程的要点：

• 顺序很重要：必须先配置再启动，再创建集群
• 自动化程度高：大部分工作由redis-cli自动完成
• 一次性设置：集群创建完成后，后续的扩容和维护相对简单

集群模式的优缺点

优点

1. 水平扩展：可以通过添加节点来扩展集群容量
2. 高可用性：主节点故障时自动进行故障转移
3. 分布式存储：数据自动分片到多个节点
4. 去中心化：无中心节点，避免单点故障

缺点

1. 事务限制：不支持跨槽的事务操作
2. 数据迁移开销：节点加入/删除时需要迁移槽和数据
3. 客户端复杂性：客户端需要处理重定向和集群拓扑变化
4. 一致性保证有限：在特定场景下可能出现数据不一致

本文使用 mdnice 排版