Redis 哨兵与集群模式的取舍

发布时间:2025-12-12 15:23

## 两种架构的对比 Redis 的高可用与扩容量是两个独立问题，对应两套架构。哨兵模式主从复制打底，一组哨兵进程负责监控与自动切换：主库失联达到多数派同意，从库被提升为新主，客户端经哨兵拿到新地址，故障恢复自动化。集群模式在复制之上加分片：数据按槽位分散到多个主节点，容量与吞吐随节点数横向扩展，节点间自带故障转移，不再需要独立的哨兵进程。 ## 各自的适用面 数据量单机内存装得下、写入压力单机扛得住的业务，只有高可用需求，选哨兵就够，架构简单，客户端兼容性好，运维心智负担小。数据量持续增长、单机内存顶到上限，或者写入吞吐需要分摊，才轮到集群出场。集群的代价要认清：多键操作受槽位约束，跨槽位的命令要么放弃要么带哈希标签；客户端要支持集群协议；运维面从几台机器扩大到一整组。中小业务常见的选择是哨兵起步，规模到了再迁集群，迁移要提前规划 key 的分布。 ## 部署要点 哨兵至少部署三个实例且分散在不同机器，多数派机制决定了偶数实例没有意义。 ``` sentinel monitor mymaster 10.0.0.11 6379 2 ``` 这一行声明被监控主库的地址与判定故障所需的同意票数。集群模式则用工具脚本按提示分槽建组，注意每个主节点配至少一个从节点，避免单点。 ## 选择建议 务实的选择路径：内存与压力测出来单机余量充足的，用哨兵；预估一年内数据量要翻几倍的，直接上集群免得二次迁移。两种架构都要把持久化配置与最大内存策略想清楚，重启与淘汰策略失当造成的数据丢失，任何高可用架构都救不回来。顺云云服务器上跑 Redis，先按业务峰值估容量选架构，再配合控制台监控曲线盯内存水位，扩容决策就有依据。