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之间的槽位号
- 每个主节点负责一定范围的槽位,通过槽位号就能确定数据应该存储在哪个节点
请求处理流程:
- 直接命中:如果计算出的槽位正好在当前节点负责的范围内,节点直接执行命令并返回结果
- 重定向:如果槽位不在当前节点,节点会返回一个MOVED错误,告诉客户端应该去哪个节点
- 客户端重试:客户端收到重定向信息后,会自动连接到正确的节点重新发送命令
这种设计的好处:
- 数据分布均匀:通过哈希算法保证数据在各个节点间均匀分布
- 客户端智能:客户端会学习并缓存槽位映射,减少重定向次数
- 扩展性好:添加或删除节点时,只需要重新分配部分槽位
集群节点通信原理

节点通信原理解读
这个时序图详细展示了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自动完成
- 一次性设置:集群创建完成后,后续的扩容和维护相对简单
集群模式的优缺点
优点
- 水平扩展:可以通过添加节点来扩展集群容量
- 高可用性:主节点故障时自动进行故障转移
- 分布式存储:数据自动分片到多个节点
- 去中心化:无中心节点,避免单点故障
缺点
- 事务限制:不支持跨槽的事务操作
- 数据迁移开销:节点加入/删除时需要迁移槽和数据
- 客户端复杂性:客户端需要处理重定向和集群拓扑变化
- 一致性保证有限:在特定场景下可能出现数据不一致
本文使用 mdnice 排版