4. Redis 集群与高可用：主从复制、哨兵模式、Redis Cluster 分片集群、数据分片策略
在生产环境中，单机 Redis 面临单点故障、容量瓶颈和性能上限三大问题。本章围绕“高可用”与“水平扩展”两条主线，系统讲解 Redis 从主从复制到哨兵模式，再到 Redis Cluster 分片集群的演进路径，并深入剖析数据分片策略的核心原理。
4.1 主从复制：高可用的基石
主从复制（Replication）是 Redis 高可用的基础。一个主节点（Master）可以挂载多个从节点（Slave），从节点实时同步主节点的数据，实现读写分离与数据冗余。
4.1.1 复制流程
- 连接建立：从节点向主节点发送
PSYNC命令，请求同步。 - 全量复制：主节点执行
BGSAVE生成 RDB 快照，发送给从节点；同时将新写入的命令缓存到复制缓冲区。 - 增量复制：从节点加载完 RDB 后，主节点将缓冲区中的增量命令发送给从节点，保持数据一致。
- 命令传播：后续主节点每执行一条写命令，都会异步推送给所有从节点。
关键参数：
repl-backlog-size 默认 1MB，决定增量复制的容错窗口。网络中断时间超过 backlog 容量时，将触发全量复制。
4.1.2 主从架构的局限性
| 问题 | 说明 |
|---|---|
| 主节点单点故障 | 主节点宕机后，需要人工切换从节点，期间服务不可用。 |
| 写能力瓶颈 | 所有写操作集中在主节点，无法水平扩展写性能。 |
| 存储容量受限 | 所有节点存储全量数据，单机内存上限即集群上限。 |
4.2 哨兵模式：自动故障转移
哨兵（Sentinel）模式在主从复制基础上增加了自动故障检测与转移能力。哨兵节点监控主从节点的健康状态，当主节点不可用时，自动选举一个从节点升级为新的主节点。
4.2.1 哨兵核心机制
- 心跳检测：哨兵每秒向所有节点发送
PING，判断节点是否存活。 - 主观下线：单个哨兵发现节点无响应，标记为主观下线（SDOWN）。
- 客观下线：多个哨兵（通常配置 quorum=2）都认为主节点下线，标记为客观下线（ODOWN）。
- 领导者选举：哨兵集群通过 Raft 算法选举一个领导者，负责执行故障转移。
- 故障转移：领导者从从节点中选出优先级最高、数据最完整的节点，执行
SLAVEOF NO ONE提升为主节点，并通知其他从节点切换复制目标。
生产建议：至少部署 3 个哨兵节点，quorum 设置为 2，避免哨兵自身单点故障导致误判。
4.2.2 哨兵模式架构图
4.3 Redis Cluster 分片集群
Redis Cluster 是 Redis 官方提供的分布式解决方案，通过数据分片实现水平扩展，同时内置高可用机制，无需额外部署哨兵。
4.3.1 核心特性
- 无中心架构：所有节点通过 Gossip 协议通信，没有中心代理节点。
- 自动分片：将数据划分为 16384 个哈希槽（Hash Slot），每个节点负责一部分槽位。
- 高可用：每个主节点可以挂载从节点，主节点故障时自动提升从节点。
- 线性扩展：增加节点时，槽位自动迁移，无需停机。
4.3.2 数据分片策略
Redis Cluster 采用哈希槽（Hash Slot）分片策略，核心流程如下：
- 客户端计算 key 的 CRC16 校验值。
- 对 16384 取模，得到哈希槽编号：
slot = CRC16(key) % 16384。 - 根据槽位与节点的映射关系，将请求路由到对应节点。
为什么是 16384？ 16384 是 2^14，Gossip 消息中携带槽位信息时，使用 2KB 的位图即可表示所有槽位，兼顾了精度与网络开销。
4.3.3 分片策略对比
| 策略 | 代表实现 | 优点 | 缺点 |
|---|---|---|---|
| 哈希槽 | Redis Cluster | 数据分布均匀，支持动态扩缩容 | 批量操作跨节点时性能下降 |
| 一致性哈希 | Twemproxy、Codis | 节点增减影响范围小 | 存在数据倾斜风险，需要虚拟节点优化 |
| 范围分片 | 自定义实现 | 范围查询友好 | 热点数据集中，扩缩容复杂 |
4.3.4 Redis Cluster 架构图
4.4 数据分片策略深度解析
4.4.1 哈希槽 vs 一致性哈希
| 维度 | 哈希槽（Redis Cluster） | 一致性哈希（Codis/Twemproxy） |
|---|---|---|
| 数据分布 | 固定 16384 个槽，均匀分配 | 依赖哈希环，虚拟节点数量影响均匀度 |
| 扩缩容影响 | 仅迁移涉及槽位的数据 | 仅影响相邻节点数据 |
| 客户端复杂度 | 客户端需缓存槽位映射表 | 客户端需实现一致性哈希算法 |
| 批量操作 | 跨槽位操作需多次请求 | 跨节点操作同样需多次请求 |
| 运维成熟度 | 官方原生支持，工具链完善 | 依赖第三方代理，社区维护 |
4.4.2 分片策略选型建议
- 数据量 < 50GB：单机 + 哨兵模式即可，运维简单。
- 数据量 50GB ~ 500GB：优先选择 Redis Cluster，官方支持，扩缩容方便。
- 需要跨数据中心部署：考虑一致性哈希 + 代理层，便于自定义路由策略。
- 对批量操作要求高：使用哈希标签（Hash Tag）将相关 key 强制分配到同一槽位。
避坑提示：Redis Cluster 不支持多数据库（select 命令），默认仅使用 db0。同时，事务和 Lua 脚本涉及的所有 key 必须在同一节点上，否则会报 CROSSSLOT 错误。
4.5 本章小结
- 主从复制：实现数据冗余与读写分离，但无法自动故障转移。
- 哨兵模式：在主从基础上增加自动故障检测与转移，适合中小规模场景。
- Redis Cluster：通过哈希槽分片实现水平扩展，内置高可用，适合大规模分布式场景。
- 数据分片策略：哈希槽、一致性哈希、范围分片各有优劣，需根据业务场景选择。