哨兵模式适合主节点故障需自动切换但数据量小、写请求不高的场景，它为单主从架构提供自动运维能力，不改变数据分布逻辑，无法解决单节点存储和高并发瓶颈。

选哨兵还是集群，取决于你最痛的那根刺是“主节点挂了没人救”，还是“单节点存不下、扛不住”。前者哨兵能解决，后者必须上集群。

哨兵模式适合什么场景

当你只需要自动把故障主节点换掉，但数据量不大、写请求不爆炸，就用哨兵。它本质是给主从架构加个“自动运维员”，不改数据分布逻辑。

• 主节点写压力
• 业务能接受秒级故障转移（比如登录态丢失 1–2 秒）
• 没跨节点事务需求，所有 key 都能容忍被同一个主节点处理
• 客户端 SDK 支持 sentinel 连接方式（如 Jedis 的 JedisSentinelPool、Lettuce 的 RedisSentinelConfiguration）

常见错误：用哨兵扛 200GB 数据或 10 万写 QPS——结果主节点 OOM 频繁，哨兵忙着切主，反而放大抖动。

集群模式必须满足哪些硬条件

集群不是“更高级的哨兵”，它是另一套协议体系。强行套用，轻则连接失败，重则数据错乱。

Redis Skill - 高性能缓存管理

Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。

下载

• 客户端必须支持 Redis Cluster 协议（比如 Lettuce 默认支持，Jedis 需用 JedisCluster，且不能用 multi/exec 跨 slot）
• key 必须能被 CRC16(key) % 16384 算出唯一 slot；含 {} 的 key（如 user:{123}:profile）才能保证同 group 落同一节点
• 不支持 SELECT、KEYS、SCAN 全局命令；Lua 脚本里所有 key 必须落在同一 slot
• 最小部署是 6 节点（3 主 3 从），端口需开放集群总线通信（默认比服务端口大 10000，如 6379 → 16379）

典型踩坑：redis-cli -c 连集群后执行 KEYS * 直接报错；或者用旧版 Spring Data Redis（MOVED 重定向死循环。

性能和一致性怎么权衡

哨兵写吞吐受限于单主，但强一致性容易保障；集群写吞吐线性增长，但天然存在异步复制窗口和 slot 迁移期间的短暂不可用。

• 哨兵的 min-slaves-to-write 参数可设为 1，表示至少 1 个从节点在线才允许写入，降低脑裂风险
• 集群的 cluster-require-full-coverage no 可让部分 slot 不可用时仍提供服务（慎用，可能读到脏数据）
• 哨兵故障转移平均耗时 2–5 秒；集群 failover 更快（通常

别忽略配置细节：哨兵的 down-after-milliseconds 和集群的 cluster-node-timeout 数值接近时，网络抖动容易触发误判。

真正难的是边界情况——比如数据量刚过 32GB、QPS 在 6 万左右徘徊。这时与其硬选一种，不如先用哨兵稳住，再通过分库（多个哨兵组）横向拆分，等流量和复杂度真正压不住了，再迁移到集群。迁移不是改个连接地址那么简单，key 设计、客户端适配、监控指标都要重来一遍。