Sentinel也扛不住了？Redis终极方案Cluster登场

最新推荐文章于 2025-09-12 21:51:43 发布

原创最新推荐文章于 2025-09-12 21:51:43 发布 · 1.1k 阅读

CC 4.0 BY-SA版权

文章标签：

75 篇文章

订阅专栏

Redis Cluster是一个去中心化的、多主多从的架构。它通过数据分片 (Sharding) 的方式，将数据分散在多个节点上，从而实现了性能和容量的横向扩展。

• 16384个哈希槽: Redis Cluster并没有使用传统的一致性哈希，而是引入了“哈希槽”的概念。整个集群共有16384个固定的哈希槽。
• Key与槽的映射: 当你需要存取一个key时，Redis会使用CRC16(key) % 16384算法，计算出这个key应该属于哪个哈希槽。
• 槽与节点的映射: 在集群初始化时，这16384个槽会被平均分配给所有的Master节点。
- • 比如，一个3主3从的集群：
  - • Master A 负责哈希槽 0 - 5500
  - • Master B 负责哈希槽 5501 - 11000
  - • Master C 负责哈希槽 11001 - 16383

这个设计解决了Sentinel模式下单Master的写性能瓶颈，因为写请求被分散到了不同的Master节点上。

• 工作流程:
1. 1. 一个智能的、集群感知的客户端（如JedisCluster）会首先连接到集群中的任意一个节点，并拉取一份“槽位分布图”，缓存在本地。
2. 2. 当客户端要操作一个key时，它会先在本地计算这个key属于哪个槽，然后根据本地的“槽位分布图”，直接向正确的Master节点发送请求。
3. 3. MOVED重定向: 如果集群的“槽位分布图”发生了变化（比如因为节点增减或故障转移），而客户端的缓存尚未更新，它可能会访问一个错误的节点。
4. 4. 这个错误的节点会回复一个MOVED错误，其中包含了正确的节点地址。客户端收到后，会更新自己的“槽位分布图”，并重新向正确的节点发送请求。

• Gossip协议: Redis Cluster没有像Sentinel那样的“中心化”监控节点。集群中的所有节点，都会通过Gossip协议互相发送PING/PONG消息，交换彼此的状态信息。这就像一个“社区聊天群”，大家互相告知谁在线、谁失联了。
• 故障检测: 当一个节点发现另一个节点长时间没有响应时，会将其标记为“疑似下线 (PFAIL)”。然后，它会在Gossip消息中，向其他节点广播这个信息。当集群中超过半数的Master节点都认为某个Master“疑似下线”时，这个Master就会被正式标记为“已下线 (FAIL)”。
• 领导者选举与故障转移:
1. 1. 当一个Master被标记为FAIL后，它的所有Slave节点会进入选举流程。
2. 2. 数据最完整（复制偏移量最大）的那个Slave，会向集群中所有其他Master节点请求投票。
3. 3. 如果它获得了超过半数Master的投票，它就会当选为新的Master。
4. 4. 新的Master会立即接管原来旧Master负责的所有哈希槽，并开始对外提供服务。整个过程是完全自动化的，无需人工干预。

大师的艺术学校（主从+哨兵模式）虽然解决了“大师病倒”的问题，但很快又遇到了新瓶颈：全世界的订单都涌向这位大师，他一个人再厉害，也画不过来（写性能瓶颈）。为了真正做大做强，大师决定联合其他领域的顶级画家，成立一个“艺术联盟”（Redis Cluster）。

• 联盟构成:
联盟由三位齐名的大师组成，他们各自有自己的工作室和学徒（多主多从）。
- • 山水画大师A
- • 花鸟画大师B
- • 人物画大师C
• 任务分配 (哈希槽):
为了高效分流订单，联盟将世界上所有可能的绘画主题，划分成了16384个类别（哈希槽）。
- • 大师A 负责“山、河、湖、海”等5501个类别。
- • 大师B 负责“梅、兰、竹、菊”等5500个类别。
- • 大师C 负责“帝王、仕女、孩童”等5383个类别。
• 效果:
当有客户想画一幅“猛虎下山”时，联盟前台通过一个算法，立刻计算出这个主题属于“山水”类别，于是订单被直接派发给了大师A。这样，三位大师可以并行地处理各自擅长的订单，整个联盟的创作能力（写性能）得到了三倍的提升！

• 问题:
一位不了解联盟分工的新客户，直接跑到了“花鸟画”大师B的工作室，要求画一幅“庐山瀑布”。
• 智能接待员 (MOVED重定向):
大师B的接待员并不会把订单转送过去，而是非常有礼貌地对客户说：“先生，画山水是我们大师A的专长，他的工作室就在街对面的A栋。这是他的地址名片，您直接过去就行。”
这位聪明的客户（集群客户端）接过名片，更新了自己的地址本。从此以后，他所有关于山水画的请求，都会直奔大师A的工作室。

• 问题:
这个联盟没有一个像“董事会”（Sentinel）那样的外部管理机构。如果一位大师突然病倒了，谁来决策？
• “大师聊天群” (Gossip协议):
所有的大师和学徒，都在一个内部聊天群里。大家会定期在群里冒泡报平安（PING/PONG）。
• 危机处理流程:
1. 1. 发现失联: 突然，大家发现“山水画大师A”很久没在群里说话了。
2. 2. 达成共识: 大师B在群里问：“有人能联系上A大师吗？” 大师C回复：“我也联系不上。” 当群里过半的大师都确认A失联后，大家就在群公告里宣布：“A大师工作室暂停接收新订单！”
3. 3. 内部选举: A大师手下最得意的大弟子，看到公告后，立刻在群里发起投票：“各位大师，我是A老师的大弟子，作品完成度最高，我申请接替老师的工作，请大家支持！”
4. 4. 新王诞生: 大师B和大师C看到后，审核了他的资格，并投了赞成票。这位大弟子获得了多数支持，立刻“出师”，成为了新一代的山水画大师，并接管了所有相关的绘画主题类别（哈希槽）。