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 排版

相关推荐
DavidSoCool1 小时前
RabbitMQ使用topic Exchange实现微服务分组订阅
分布式·微服务·rabbitmq
掘金-我是哪吒3 小时前
分布式微服务系统架构第158集:JavaPlus技术文档平台日更-JVM基础知识
jvm·分布式·微服务·架构·系统架构
东窗西篱梦3 小时前
Redis集群部署指南:高可用与分布式实践
数据库·redis·分布式
Kookoos4 小时前
ABP VNext + Tye:本地微服务编排与调试
微服务·云原生·架构·tye
半新半旧4 小时前
Redis集群和 zookeeper 实现分布式锁的优势和劣势
redis·分布式·zookeeper
@ chen6 小时前
Redis事务机制
数据库·redis
静若繁花_jingjing8 小时前
Redis线程模型
java·数据库·redis
guojl8 小时前
Ribbon原理和源码分析
spring cloud·微服务
在肯德基吃麻辣烫8 小时前
《Redis》缓存与分布式锁
redis·分布式·缓存
掘金-我是哪吒9 小时前
分布式微服务系统架构第157集:JavaPlus技术文档平台日更-Java多线程编程技巧
java·分布式·微服务·云原生·架构