Redis Cluster 和 Sentinel 不是替代关系，而是解决不同瓶颈的方案：Sentinel 仅提升“一主多从”的高可用性，不解决单点写压力；Redis Cluster 通过 16384 个槽位分片实现写负载分散，适用于 QPS＞3000 或内存＞16GB 场景。
Redis Cluster 和 Sentinel 不是替代关系，而是解决不同瓶颈的方案
直接说结论：如果你的写请求 QPS 超过 3000，或单实例内存常驻 >16GB，Sentinel 模式就撑不住了；这时候必须上 Redis Cluster。Sentinel 只是让「一主多从」更可靠，它不改变「所有写都在一个节点」的本质。而 Redis Cluster 是把写也拆开——16384 个哈希槽（slot）分到多个主节点上，每个主节点只管自己那部分 key。
写压力大、数据量大时，Sentinel 会暴露三个硬伤
这些不是配置问题，是架构决定的：
-
redis-server进程本身在高写入下 forkRDB或AOF rewrite时容易卡顿，Sentinel 不缓解这个； - 主节点同时承担写 + 全量同步 + 增量命令广播，从节点越多，主节点网络和 CPU 压力越线性增长；
- 当主节点因 OOM 或 GC 卡住，Sentinel 虽能切换，但新主节点要重放整个
repl_backlog，期间可能丢掉部分未同步的写命令。
比如某电商秒杀场景，写库存操作峰值达 8000 QPS，用 Sentinel 后发现主节点 INFO replication 中 master_repl_offset 和从节点 slave_repl_offset 差值长期 >50 万，说明增量同步已追不上。
Redis Cluster 的代价：客户端必须支持 ASK / MOVED 重定向
这不是加个配置就能跑通的事。你得确认以下几点：
- 使用的客户端库是否原生支持集群模式（如
redis-py的RedisCluster类，而非普通StrictRedis）； - 应用中有没有跨 key 的操作，比如
MGET key1 key2 key3—— 如果这三个 key 落在不同 slot，Redis Cluster会直接报错CROSSSLOT Keys in request don't hash to the same slot； - Lua 脚本里用了多个 key？必须显式用
{}包裹 key 名让它们落在同一 slot，例如KEYS[1] = "user:{123}:profile"，否则脚本执行失败。
很多团队踩坑是因为本地用单机 Redis 测试没问题，上线集群后突然大量 MOVED 报错，根源其实是客户端没切到集群模式，还在往固定 IP 发请求。
哨兵模式适合「读远多于写」且可接受人工兜底的场景
典型如内容平台的用户会话缓存、APP 配置下发、商品详情页静态数据。这类业务特征明显：
- 写操作集中在后台管理端（每天几百次），但读请求来自百万级终端；
- 允许秒级延迟（从节点同步有 lag，但用户刷一次详情页不会感知）；
- 主节点宕机时，运维能 5 分钟内执行
slaveof no one+ 修改 DNS 或配置中心，业务影响可控。
这种情况下硬上 Redis Cluster 反而增加复杂度：你需要维护至少 6 个节点（3 主 3 从）、处理 slot 迁移、监控每个节点的 cluster_state 和 cluster_slots_assigned，而收益几乎为零。
真正容易被忽略的是：Sentinel 的 quorum 参数不是设得越高越好。设成 3 个哨兵要求全部同意才判定主节点下线，反而可能导致脑裂——比如网络分区时，两个子网各自选出一个主节点。实践中 quorum 设为 ⌊n/2⌋+1（n 是哨兵数）更稳妥。
