Redis Cluster采用客户端分片，客户端需自行路由至正确节点，通过CRC16(key)&8191计算slot并缓存CLUSTER SLOTS映射，不支持跨slot命令，扩容需手动reshard且运维复杂度远高于哨兵。
集群模式下客户端怎么路由到正确节点？
Redis Cluster 不是靠客户端连一个入口再由服务端转发，而是客户端必须自己知道每个 slot 对应哪个节点——也就是“客户端分片”。这意味着你不能像用哨兵那样只配一个 sentinel.conf 和 master-name 就完事，得用支持 Cluster 协议的客户端（比如 Jedis 的 JedisCluster、Go 的 redis.ClusterClient、Python 的 redis-py-cluster）。
常见错误现象：Moved 12345 10.0.1.5:6379 报错反复出现，说明客户端没走 Cluster 模式，还在当单点连；或者用了老版本驱动，不自动重定向也不缓存 slots 映射。
- 必须初始化时传入至少一个节点地址，客户端会自动
CLUSTER SLOTS拉取全量分片映射并缓存 - key 必须参与 CRC16 计算得到 slot（
slot = CRC16(key) & 8191），不能靠业务层硬编码路由 - 含多个 key 的命令（如
MGET、DEL）要求所有 key 落在同一个 slot，否则报CrossSlot错误 - 不支持多 key 事务（
MULTI/EXEC跨 slot）、KEYS全局扫描、FLUSHALL等命令
横向扩容时，集群比哨兵省事还是更烧脑？
哨兵扩容只能纵向加内存或提升单机性能，本质仍是“一主多从”，写瓶颈卡死在单个 master；而集群扩容是真水平扩展——加节点、迁 slot、重新平衡，但每一步都带副作用。
使用场景：当你数据量超过 20GB 或写 QPS 稳定超 8 万，哨兵已经扛不住了，集群才是出路。但别幻想“加机器就自动均摊”。
- 新增节点后需手动执行
redis-cli --cluster add-node，再用reshard迁移 slot，过程不可逆且期间部分 slot 只读 - 迁移中若网络抖动，可能卡在
importing/migrating状态，导致对应 slot 请求失败 - 从节点扩容不是加 slave 就完事，得先
replicate指定 master，再用set-node-as-replica绑定，顺序错就成孤儿节点 - 哨兵扩容只需加从节点 + 配置文件 reload，集群扩容必须滚动更新所有客户端的 slots 缓存（靠
ASK/MOVED自动刷新，但有延迟）
运维成本差在哪？哪些坑哨兵不会踩、集群却天天见
哨兵是“轻量高可用”：3 个哨兵进程 + 1 主 2 从，配置改几行、日志看几眼就能跑稳两年；集群是“重型分布式系统”：最少 6 节点（3 主 3 从），每个节点要独立管理持久化、内存、连接数，还多了 gossip 协议心跳、failover 投票、slots 同步等隐藏链路。
容易踩的坑：
-
cluster-require-full-coverage yes默认开启，只要任意一个 slot 不可用（比如某主挂了又没从顶上），整个集群拒绝所有请求——哨兵下主挂了还能读从，集群直接全挂 - gossip 端口（
port+10000）被防火墙挡住，节点间无法通信，表现为 “Node is not ready” 或 slots 映射长期不更新 - 客户端没设
max-redirects（如 JedisCluster 默认 5），遇到连续重定向就抛异常，实际可能只需再跳 1～2 次 - 运维查问题时习惯用
INFO replication，但在集群里得切到对应节点再查，且INFO cluster才能看到真实拓扑
什么情况下该坚持用哨兵，别硬上集群？
如果你的数据能塞进单机 32GB 内存、峰值写 QPS 压不垮一台 Redis（实测稳定 ≤ 7 万）、团队没专职 DBA 或 SRE，那集群带来的复杂度远大于收益。
真实信号：
- 监控显示
used_memory_rss长期 > 80%、evicted_keys非零、latest_fork_usec动辄几百毫秒——这是 RDB fork 开始拖慢主线程，该分片了 - 故障演练中，哨兵 failover 时间稳定
- 你正在用 Lua 脚本做原子逻辑，且脚本里 key 分布天然集中（比如都带
user:{id}:前缀），那集群的 hash tag（{user:1001}）能保住脚本可运行，否则就得重构
集群不是银弹，它把一部分运维负担转嫁给了架构设计和客户端代码。上线前最该验证的，不是功能通不通，而是你的业务能否接受 slot 迁移时的短暂只读、跨节点命令的限制、以及出问题时排查路径变长三倍的事实。
