选Cluster而非哨兵，当瓶颈是单节点写不过来或数据存不下；哨兵仅实现自动故障转移，不解决容量与写扩展问题。
选哨兵还是Cluster，关键看你的瓶颈是不是“单节点写不过来”或者“数据存不下”——如果是，哨兵救不了你。
哨兵模式只解决自动切主，不解决容量和写扩展
哨兵本质是给主从架构加个“值班员”，它不碰数据分布逻辑，所有读写仍压在单个主节点上。你配置了 3 个哨兵 + 1 主 2 从，数据量涨到 150GB、写 QPS 到 8 万，主节点照样内存爆、CPU 满、复制延迟飙升。这时候哨兵只会更频繁地触发 failover，反而加剧抖动。
常见错误现象包括：
-
redis-cli -h sentinel-host -p 26379 SENTINEL get-master-addr-by-name mymaster能返回地址，但应用连不上新主——多半是客户端没用RedisSentinelConfiguration，还硬写死 host:port - 主从延迟持续 > 100ms，
INFO replication显示master_repl_offset和slave_repl_offset差距越来越大——说明网络或主节点写入压力已超承载能力 - 设置了
min-slaves-to-write 1却仍出现脑裂写入——因为min-slaves-max-lag配得太松（比如设成 10 秒），从节点卡住时主还在收写请求
Cluster 模式强制要求 key 路由和客户端适配
Cluster 不是哨兵的升级版，它是另一套协议体系。一旦启用，客户端必须能处理 MOVED 或 ASK 重定向，且不能依赖全局命令。
典型踩坑点：
- Spring Boot 项目用了旧版
spring-data-redis（如 2.3.x），配置RedisClusterConfiguration后启动报Cannot retrieve initial cluster topology——实际是客户端没拿到槽位映射，需确认所有节点cluster-enabled yes且集群总线端口（port + 10000）互通 - 执行
KEYS *或SCAN 0 MATCH user:* COUNT 100直接失败——Cluster 不支持跨 slot 扫描，必须用redis-cli -c并确保 key 带{}（如user:{123}:token）才能路由到同一节点 - Lua 脚本里操作多个 key，但没保证它们落在同一 slot——运行时报
CROSSSLOT Keys in request don't hash to the same slot
QPS 和数据量是硬分水岭，别信“先哨兵后迁移”
很多团队想“先上哨兵扛着，等业务增长再切 Cluster”，结果发现迁移成本远超预期：要改 key 设计、重写 Lua 脚本、替换所有 multi/exec 事务逻辑、校验全量数据一致性。不如一开始就把路走对。
可参考的生产级判断条件：
- 当前写 QPS ≥ 5 万 或 数据量 ≥ 100GB → 直接上 Cluster，别犹豫
- 业务有明确增长规划（如半年内用户翻倍），即使当前才 2 万 QPS，也建议一步到位 Cluster
- 用 Jedis 客户端 → 小心
JedisCluster不支持 pipeline 中混用多 slot key；Lettuce 更稳妥，默认支持异步重定向和连接池自动恢复 - 运维人力紧张 → 哨兵部署简单，但故障后得人工确认脑裂、查日志、清残留；Cluster 自动分片+failover 更省心，但得盯
cluster-node-timeout和repl-backlog-size
真正容易被忽略的是复制延迟监控和时钟同步。无论哨兵还是 Cluster，只要主从时间差超过 cluster-node-timeout（默认 15 秒），节点就会被误判下线；而哨兵的 down-after-milliseconds 如果设得比网络 P99 延迟还小，会引发频繁误切。这些参数不是配完就完事，得结合真实链路 RT 来调。
