文章目录
- 引言
- Redis Cluster 的基本架构
- 为什么是 16384 个槽
- 槽的分配与数据迁移
- 纵向扩展 vs 横向扩展的取舍
- Hash Tag：让相关 key 落在同一个槽
- Cluster 的高可用
- 实践建议
引言
当 Redis 单实例的内存不够用时，有两条路：纵向扩展（加内存）和横向扩展（加实例）。纵向扩展简单直接，但有天花板——单机内存到 TB 级就很贵了，而且实例越大 fork 越慢、RDB 越大、恢复越久。
横向扩展是把数据分散到多个实例上，每个实例只存一部分，这就是切片集群。
Redis Cluster 的基本架构
Redis 3.0 引入了官方的切片集群方案——Redis Cluster。它的核心设计：
- 去中心化：没有代理层，没有中心节点，所有节点地位平等。
- 哈希槽分片：把 key 空间划分为 16384 个槽（slot），每个节点负责一部分槽。
- 客户端直连：客户端通过 Smart Client 直接和数据所在的节点通信。
一条命令的路由过程：
客户端 → CRC16(key) mod 16384 → 得到槽号 → 查本地槽位表 → 找到目标节点 → 发送命令
如果客户端发错了节点，目标节点会返回 MOVED 重定向，告诉客户端正确的节点地址。Smart Client 会缓存槽位映射表，减少重定向次数。
为什么是 16384 个槽
这个数字是精心选择的。节点之间通过 Gossip 协议交换心跳消息，每条消息里都带着发送者负责的槽位图（bitmap）。16384 个槽的位图是 2KB（16384 / 8 = 2048 字节），如果用 65536 个槽就是 8KB，对心跳消息体积影响很大。
同时 16384 对于绝大多数集群规模（几十到几百个节点）来说粒度已经足够细，能保证数据分布均匀。
槽的分配与数据迁移
集群初始化时，需要手动或通过工具把 16384 个槽分配给各节点。比如 3 个节点：
- 节点 A：槽 0-5460
- 节点 B：槽 5461-10922
- 节点 C：槽 10923-16383
扩容时（加入节点 D），需要从现有节点迁移一部分槽到 D。迁移过程：
迁移期间，如果客户端访问正在迁移的 key：
- key 还在源节点：正常返回。
- key 已经迁到目标节点：源节点返回 ASK 重定向。
ASK 和 MOVED 的区别：MOVED 表示槽已经永久转移，客户端要更新本地映射；ASK 表示只是这一次去那边问问，下次还来源节点。
纵向扩展 vs 横向扩展的取舍
| 实施难度 | 低，改配置重启 | 高，需要数据迁移 |
| 成本曲线 | 指数增长（大内存贵） | 线性增长 |
| fork 影响 | 实例越大越严重 | 每个实例小，fork 快 |
| 运维复杂度 | 低 | 高（多节点管理） |
| 容量上限 | 单机物理内存 | 理论无限 |
一般建议：单实例内存控制在 2-6GB（如果有 RDB/AOF 需求）或 10-25GB（纯缓存场景），超过就该考虑切片。
Hash Tag：让相关 key 落在同一个槽
默认情况下，不同 key 大概率落在不同槽（不同节点）。如果业务需要对多个 key 做原子操作（比如 Lua 脚本、事务），它们必须在同一个节点上。
Hash Tag 机制：如果 key 中包含 {}，Redis 只对花括号内的部分做 CRC16。
user:{1000}:name → CRC16("1000") → 同一个槽
user:{1000}:age → CRC16("1000") → 同一个槽
这样就能保证同一用户的所有 key 落在同一节点，支持跨 key 操作。但要注意：如果大量 key 用了相同的 Hash Tag，会导致数据倾斜。
Cluster 的高可用
Redis Cluster 自带主从复制和故障转移，不需要额外部署哨兵。每个主节点可以有一个或多个从节点。主节点挂了，它的从节点会自动选举升级为新主节点。
选举过程和哨兵类似：从节点发起投票，其他主节点投票，拿到多数派的从节点升级。
实践建议
切片集群解决了单机容量和吞吐的瓶颈，但也引入了数据分布、跨节点操作、集群管理等新问题。理解槽的分配和迁移机制，是运维 Redis Cluster 的基本功。
