集群的硬边界
使用集群前必须清楚它的边界：不支持多数据库，只能使用 0 号库；涉及多个键的操作要求这些键位于同一个槽；槽的总数固定为 16384，不多不少；故障转移基于异步复制，切换时可能丢掉尚未同步到新主库的写入；大 key 与热点在单个分片之内无法被分散。这些不是靠调参就能绕过的限制，而是架构决定的，选型阶段就要逐项确认业务是否会踩线。
基本信息
| 多库支持 | 不支持，只有 0 号库 |
|---|---|
| 多键操作 | 要求同槽，可用哈希标签保证 |
| 槽总数 | 固定 16384 |
| 一致性 | 异步复制，切换可能丢少量写入 |
| 热点 | 单分片内的热点无法自动分散 |
典型使用场景
- 选型评估：确认业务是否依赖多库或多键原子操作
- 改造评估：把单机实例迁移到集群前逐项核对用法
- 代码评审：静态扫描是否存在跨槽的多键命令
- 容量规划：接受单分片存在容量与吞吐上限这一前提
- 事故预案：明确切换窗口内允许丢失的数据范围
边界验证
边界验证
redis-cli -p 7000 CLUSTER INFO | grep -E 'cluster_state|cluster_slots_assigned'
redis-cli -p 7000 CLUSTER KEYSLOT user:1001 # 确认键落在哪个槽
redis-cli -p 7000 MGET '{u1}:a' '{u1}:b' # 同槽时可以执行
redis-cli -p 7000 MGET user:1 user:2 # 不同槽会报 CROSSSLOT
redis-cli -p 7000 SELECT 1 # 集群下不支持切库
redis-cli -p 7000 DBSIZE # 集群只有一个库边界与应对
| 边界 | 影响 | 应对 |
|---|---|---|
| 不支持多库 | 按库号隔离的设计无法直接迁移 | 改用键前缀隔离 |
| 多键需同槽 | 跨键操作直接报错 | 用哈希标签绑定相关键 |
| 槽数固定 | 分片粒度受槽分配限制 | 规划分片数量时考虑粒度 |
| 异步复制 | 切换可能丢未同步写入 | 关键数据另有持久化与对账 |
更多分片不等于更好性能。单分片内的热点键、跨分片聚合查询以及需要跨键原子性的业务逻辑，依然要在业务层解决，集群能做的只是把整体压力分散到不同分片上。
单机模式跑得好好的代码，切到集群后大面积报错，绝大多数是「多键操作跨槽」和「使用了非 0 号库」这两类用法。迁移前先做一次静态代码扫描，比上线后逐个功能排查便宜得多。