哨兵模式适合主节点故障需自动切换但数据量小、写请求不高的场景，它为单主从架构提供自动运维能力，不改变数据分布逻辑，无法解决单节点存储和高并发瓶颈。
选哨兵还是集群，取决于你最痛的那根刺是“主节点挂了没人救”，还是“单节点存不下、扛不住”。前者哨兵能解决，后者必须上集群。
哨兵模式适合什么场景
当你只需要自动把故障主节点换掉，但数据量不大、写请求不爆炸，就用哨兵。它本质是给主从架构加个“自动运维员”，不改数据分布逻辑。
- 主节点写压力
- 业务能接受秒级故障转移（比如登录态丢失 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 设计、客户端适配、监控指标都要重来一遍。
