Redis 集群模式Redis Cluster

原创已于 2026-01-05 13:07:31 修改 · 225 阅读

5 ·

CC 4.0 BY-SA版权

文章标签：

#redis #数据库 #缓存

于 2025-12-24 21:59:33 首次发布

Reids 专栏收录该内容

8 篇文章

订阅专栏

一、前言

Redis 集群模式（Redis Cluster） 是 Redis 提供的一种分布式数据库解决方案，用于实现数据的自动分片（sharding）、高可用性（HA）和 横向扩展能力。它从 Redis 3.0 开始正式支持。

二、Redis Cluster核心特性

数据分片（Sharding）
Redis 集群将整个键空间划分为 16384 个哈希槽（hash slots）。
每个键通过 CRC16(key) % 16384 计算出所属的槽。
每个节点负责一部分槽，从而实现数据分布。
高可用（High Availability）
每个主节点（master）可以有多个从节点（replica/slave）。
主节点故障时，集群会自动进行故障转移（failover），由从节点提升为主节点。
使用 Gossip 协议（如 PING/PONG/MEET）进行节点间通信和状态同步。
去中心化
没有中心协调节点，每个节点都保存集群的拓扑信息。
客户端可连接任意节点，若请求的 key 不在该节点，会收到 MOVED 或 ASK 重定向。

三、Redis 集群有哪些限制或缺点？

❌ 不支持多 key 跨槽操作（除非在同一槽）；
解决办法： 通过 .NET 客户端（如 StackExchange.Redis）模拟实现“伪多 key 操作”，虽然不保证原子性，但在很多业务场景下是可接受的。
❌ 不支持数据库切换，不支持多DB（默认只有 DB 0）；
解决办法： 通过.Net客户端，用 key 前缀（Namespace）模拟逻辑数据库，为不同业务模块的 key 添加统一前缀
如：
session:user:123 → 模拟 “DB 0”（会话）
cache:product:456 → 模拟 “DB 1”（商品缓存）
job:task:789 → 模拟 “DB 2”（任务队列）
❌ 事务/Lua 脚本受槽限制；
❌ 集群模式下不支持 SELECT 命令；
❌ 客户端需支持集群协议（如 JedisCluster、StackExchange.Redis）；
❌ 最小部署需 3 主 3 从（6 节点）才能实现高可用 + 容错。

四、什么是哈希槽

Redis 哈希槽（Hash Slot）是 Redis Cluster 分布式集群的核心概念，用于实现数据分片和负载均衡。

Redis Cluster 将整个键空间划分为 16384 个哈希槽（0-16383），每个键通过 CRC16 算法计算出一个 16 位的哈希值，然后对 16384 取模，确定该键属于哪个哈希槽。每个哈希槽都会被分配到集群中的某个主节点上。

主要作用

数据分片
通过哈希槽将数据均匀分布到多个节点，实现水平扩展，突破单机内存限制。
负载均衡
自动将哈希槽分配到不同节点，避免数据倾斜，确保各节点负载相对均衡。
高可用性
当节点故障时，集群会自动将故障节点的哈希槽重新分配到其他正常节点。
动态伸缩
支持在线添加或删除节点，集群会自动重新分配哈希槽，无需停机。

管理命令

CLUSTER SLOTS： 查看哈希槽分布
CLUSTER ADDSLOTS： 手动分配哈希槽
CLUSTER DELSLOTS： 删除哈希槽

五、为什么是16384个槽

Redis 作者 Salvatore Sanfilippo 解释过这个设计：

通信开销考量： 集群节点间通过 Gossip 协议交换槽信息，使用 bitmap 表示槽分配状态。
16384 个槽 ≈ 2KB 的 bitmap（16384 / 8 = 2048 字节）。
如果槽太多（如 65536），bitmap 会变大，增加网络带宽消耗。
实用性权衡： 实际生产中 Redis 集群节点通常不超过几百个，16384 个槽已足够实现均匀分布。

六、Gossip 消息

1、在 Redis Cluster 的 Gossip 协议（通过 PING/PONG 消息）中：

每个节点在 PING/PONG 消息中不会发送整个 16384 位的槽位 bitmap。
而是采用一种紧凑编码方式，只描述 “自己负责哪些槽” —— 具体来说，是以 槽范围（slot ranges）的形式发送，例如：
```
[start_slot, end_slot]
```
如果一个节点负责多个不连续的槽段，就发送多个这样的区间。
槽总数越多 → 描述“自己负责哪些槽”所需的元数据可能越大 ，这就是为什么说 65536 个槽会导致心跳包过大

举例： 假设设计为65536个槽位，现在你有 100 个节点（100台主机）
场景 1：集群节点数量多，槽分配碎片化
平均每个节点负责约 650 个槽
当槽分配不连续（比如由于频繁扩缩容、迁移失败等），一个节点可能负责几十个甚至上百个不连续的小槽段。
每个槽段需用[start, end]表示（通常 2×2=4 字节），那么 100 个槽段 ≈ 400 字节

而在 16384 槽 + 同样 100 节点下，平均每个节点负责 ~160 个槽，碎片化程度更低，所需槽段描述更少。

场景 2：Gossip 消息中还包含其他节点的“疑似故障”信息（gossip section）
1、PING/PONG 消息除了携带自身状态，还会附带随机选取的 N 个其他节点的状态摘要（用于传播集群视图）
2、这些摘要中也包含目标节点负责的槽信息（同样是槽范围列表）
3、所以，即使 A 节点只发自己的槽，它也会在 gossip section 中捎带 B、C 节点的槽信息
4、当槽总数很大时，每个被捎带的节点的槽描述也可能变长，整体消息膨胀

总槽位数 16384 是一个经过精心权衡的数字，确保了在绝大多数实际场景下，网络效率和扩展性都不会成为问题。

在这里插入图片描述
在 Redis 集群架构中，从节点（Replica）的核心价值在于构建高可用、容灾 resilient 的数据服务体系。它通过异步复制机制，实时同步主节点（Master）的数据状态，形成“主-备”冗余单元。当主节点因故障、网络分区或维护等原因不可用时，集群能够基于多数派共识机制，自动触发故障转移（Failover），将一个健康的从节点无缝晋升为主节点，从而：

保障服务连续性： 客户端请求几乎无感知地切换至新主节点，避免业务中断；
守护数据可靠性： 最大限度减少因单点故障导致的数据丢失风险；
提升系统韧性： 在面对硬件故障、网络抖动等异常场景时，系统具备自愈能力。

因此，从节点不仅是数据的“备份副本”，更是 Redis 集群实现高可用（High Availability）与故障自恢复能力的关键基石。
一般而言，Redis 单节点性能极高（10万+QPS）大部分应用场景不需要从节点分担读压力，主节点能轻松处理所有请求。
因此，在绝大多数业务场景中，主节点自身已足以承载全部访问压力，无需依赖从节点分担读负载。从节点的核心价值应聚焦于高可用保障与故障容灾，而非作为性能扩展的手段，从而确保系统在保持简洁性的同时，兼具稳定性与可靠性。
在这里插入图片描述