选主从、哨兵或Cluster取决于数据量、并发压力和扩展需求：10GB/5万QPS内主从足够；20–50GB/10–50万QPS宜用哨兵；超50GB或百万级写QPS需Cluster分片。
选主从还是集群，关键看数据量、并发压力和扩展需求，不是越复杂越好。
数据量小、读多写少，主从足够用
如果缓存数据总量在 10GB 以内，日常 QPS 不超过 5 万，主从复制就能稳住。它结构简单，部署快，运维成本低。比如电商商品详情页缓存（约 10GB），读请求占 90% 以上，写更新频率低，主从加读写分离完全够用。从节点还能做热备，主挂了手动切一下，业务影响可控。
- 配置只需在从节点 redis.conf 中加 slaveof 主IP 主端口 和密码（如有）
- 读请求可分散到多个从节点，缓解主节点压力
- 不依赖额外组件，故障点少，排查容易
需要自动容灾但数据仍在单机容量内，上哨兵模式
当数据量涨到 20–50GB，QPS 达到 10 万～50 万，主从的手动切换就成了瓶颈。这时候加哨兵（Sentinel）是性价比最高的升级：它不改变主从的数据流向，只是在旁边加几个监控进程，自动发现主节点宕机、选举新主、通知客户端重连。整个过程秒级完成，业务几乎无感。
- 哨兵本身轻量，3 个节点即可形成多数派决策
- 仍沿用主从复制机制，学习和迁移成本低
- 写操作依然集中在单主，所以单机内存和 CPU 仍是上限
数据超 50GB 或写压力大，必须用 Cluster 集群
一旦缓存总量突破 50GB，或写 QPS 稳定在百万级，单节点的内存和写吞吐就扛不住了。Cluster 通过哈希槽（16384 个）把数据分片到多个主节点，每个主节点还可配从节点做高可用。写请求天然打散，扩容也只需加主从组，性能基本线性增长。
- 要求客户端支持 Redis Cluster 协议（如 Jedis、Lettuce）
- 不支持多键操作（如 MGET 跨槽）、事务（MULTI/EXEC）受限
- 运维复杂度明显上升，需关注槽迁移、节点健康、网络分区等
别忽略过渡方案的实际价值
很多团队卡在“一步到位”的思维里。其实哨兵可以看作主从的增强版，Cluster 本身也内置主从——三者不是非此即彼，而是能力叠加。比如先跑主从，压测发现切换太慢，再平滑接入哨兵；等业务再翻倍，再把部分热点数据迁到 Cluster 分片中。路径清晰，风险可控。
