两种高可用方案怎么选
哨兵解决「自动切换」：主库故障时从副本中选出新主库，数据仍是单机全量。集群解决「分片加切换」：数据按哈希槽分散到多个主节点，容量可以横向扩展。判断依据很简单：单机内存装得下就用哨兵，装不下或持续增长才上集群。
基本信息
| 哨兵最小规模 | 3 个哨兵节点加主从实例，奇数便于投票 |
|---|---|
| 集群分片 | 16384 个哈希槽分布在多个主节点上 |
| 集群副本 | 每个主节点可挂若干从节点参与故障转移 |
| 客户端要求 | 集群需要支持集群感知的客户端，能随槽迁移重定向 |
| 运维成本 | 集群在扩缩容与槽迁移上明显更高 |
选型判断要点
- 数据量小于单机内存六成且需要自动切换：选哨兵，简单可靠
- 数据持续增长会超过单机上限：选集群，避免后期大规模改造
- 多键操作频繁：哨兵不受槽限制，集群需要哈希标签保证同槽
- 团队运维能力有限：优先哨兵，集群的槽迁移需要专门经验
- 云上部署：优先用托管实例的高可用能力，运维负担最小
判断依据与核对
判断依据与核对
# 估算数据规模与实际内存占用
redis-cli INFO memory | grep -E "used_memory_human|maxmemory_human"
# 集群侧：查看槽分布与节点角色
redis-cli -c -p 6379 CLUSTER INFO | grep -E "cluster_state|cluster_slots_assigned"
redis-cli -c -p 6379 CLUSTER NODES | grep -E "master|slave" | head
# 哨兵侧：查看被监控主库与其余哨兵
redis-cli -p 26379 SENTINEL masters
redis-cli -p 26379 SENTINEL sentinels mymaster方案对比
| 维度 | 哨兵 | 集群 |
|---|---|---|
| 数据分片 | 无，单主全量数据 | 16384 槽分散到多主 |
| 容量上限 | 受单机内存限制 | 可横向扩展 |
| 多键操作 | 不受限制 | 必须同槽，否则跨槽报错 |
| 客户端 | 协议兼容性广 | 需要集群感知客户端 |
| 运维复杂度 | 较低 | 高，涉及槽迁移与扩缩容 |
选型先看数据规模与增长曲线：为了「技术先进」上集群，代价是多键限制与更高的运维门槛。
把几十 GB 的数据放进集群：跨槽限制带来大量改造，而容量问题根本还没到，属于典型的过度设计。