为什么Redis需要高可用？
Redis作为内存数据库，一旦服务宕机，缓存数据可能丢失，直接影响业务响应速度甚至导致雪崩。单机Redis虽然性能优异，但缺乏容错能力。为此，Redis社区逐步演进出了三种高可用方案：主从复制（Replication）、哨兵模式（Sentinel）和Cluster集群。这三者并非相互替代，而是针对不同规模与可用性要求的场景设计。
理解它们之间的差异和联系，是构建可靠缓存层和存储层的基础。
一、主从复制：最基础的冗余方案
工作原理
主从复制允许一个主节点（Master）将数据同步到一个或多个从节点（Slave）。从节点默认只提供读服务，写操作全部由主节点处理。同步过程分为两步：
- 全量同步：当从节点首次连接主节点时，主节点执行bgsave生成RDB快照，并发送给从节点，同时将后续写命令记录在缓冲区中。
- 增量同步：全量同步完成后，主节点将缓冲区的写命令以及后续的实时写命令通过复制积压缓冲区（Replication Backlog）持续推送给从节点。
Redis 2.8之后使用PSYNC协议，支持部分重同步（断线重连后只同步缺失数据），节省带宽与时间。
配置方式
在从节点的redis.conf中添加一行即可：
replicaof master_ip master_port
也可以通过命令动态设置：
SLAVEOF master_ip master_port
主从复制的优点
- 实现读写分离，分担主节点读压力
- 数据冗余，防止单节点数据丢失
- 为更高阶的哨兵模式提供基础
核心痛点：无法自动故障转移
当主节点宕机，从节点虽然持有完整数据，但不会自动升级为新的主节点。需要人工使用SLAVEOF NO ONE命令将一个从节点设为主节点，再调整其他从节点的复制目标。这期间服务中断，对生产环境不可接受。
二、哨兵模式：自动故障转移的利器
哨兵是什么
Sentinel（哨兵）是一个独立运行的进程，用于监控Redis主从架构的健康状态。它通常部署3个或更多实例组成哨兵集群，避免单点故障。哨兵的主要职责：
- 监控（Monitoring）：不断检查主节点和从节点是否可达
- 通知（Notification）：当节点出现问题时通过API通知管理员
- 自动故障转移（Automatic Failover）：当主节点不可用时，选举一个从节点升级为新主节点，并更新其他从节点的复制目标
- 配置提供（Configuration Provisioning）：客户端连接哨兵获取当前主节点地址
故障转移流程
当哨兵发现主节点无法响应（主观下线），它会与其他哨兵沟通，若多数哨兵确认主节点不可达，则标记为客观下线。随后哨兵集群通过Raft算法选出一个领导者哨兵，由它执行故障转移：
- 从从节点列表中按优先级、复制偏移量、Run ID等规则选出新主节点
- 发送
SLAVEOF NO ONE命令将其提升为主节点 - 命令其他从节点复制新主节点
- 如果原主节点恢复，将其设置为新主节点的从节点
哨兵配置示例
sentinel monitor mymaster 127.0.0.1 6379 2
sentinel down-after-milliseconds mymaster 5000
sentinel failover-timeout mymaster 60000
sentinel parallel-syncs mymaster 1
其中2表示至少需要2个哨兵同意才能判定主节点客观下线。
哨兵的局限
- 写入能力仍受限于单主节点，无法水平扩展写性能
- 数据容量受限于单机内存
- 写操作存在单点瓶颈，不适合超大流量写入场景
三、Cluster集群：分布式水平扩展与高可用
设计思路
Redis Cluster在3.0版本正式推出，目标是实现数据分片与高可用的统一。它将所有数据划分为16384个哈希槽（Hash Slot），每个节点负责一部分槽。当写入一个key时，通过CRC16(key) % 16384计算其所属槽，然后路由到负责该槽的节点。
节点间通信
集群节点通过Gossip协议互相交换状态信息，包括节点存活、槽分配、配置纪元等。所有节点都维护一份完整的槽映射表（Cluster State）。客户端可以连接任一节点，若请求的key不在该节点上，节点会返回MOVED重定向错误，客户端据此更新本地缓存。
高可用机制
在Cluster中，每个主节点可以配置若干从节点。当主节点不可用时，其从节点会通过内部选举升级为新主节点。选举过程类似哨兵，但完全由集群节点自身完成，无需额外组件。
Cluster要求至少3个主节点才能形成高可用集群，每个主节点至少有一个从节点。当某个主节点及其所有从节点都宕机时，该段槽的数据不可用，集群部分下线。
部署与配置要点
- 每个节点需要开两个端口：一个服务端口（如6379），另一个集群总线端口（服务端口+10000，如16379）
- 配置文件需开启
cluster-enabled yes - 使用
redis-cli --cluster create命令创建集群 - 支持在线扩缩容，通过reshard迁移槽
Cluster的优势
- 写性能可水平扩展：增加主节点即可提升写入吞吐量
- 数据容量不受单机限制：分散到多台服务器
- 无中心化架构，自身提供自动故障转移
Cluster的不足
- 跨节点操作受限：不支持多key操作（除非所有key在同一个slot，可通过hash tag解决）
- 数据迁移（reshard）期间可能影响性能
- 客户端需要支持集群协议（如JedisCluster、Lettuce）
- 运维复杂度较高
四、三者在实际场景中的选择
| 场景 | 推荐方案 | 原因 |
|---|---|---|
| 缓存，读多写少，数据量小 | 主从复制＋哨兵 | 简单可靠，自动故障切换，满足读扩展 |
| 数据库持久化，中等QPS | 哨兵模式 | 自动故障转移，保证高可用，单节点写够用 |
| 超高并发写入，TB级数据 | Cluster集群 | 水平扩展写性能和容量 |
| 多Region部署，异地容灾 | 主从＋哨兵 + 跨机房同步 | 使用Redis作为辅助方案，Cluster跨机房较复杂 |
五、常见误区与注意事项
- 哨兵不是代理：客户端需要自己通过哨兵获取主节点地址，然后直连。有些用户误以为连上哨兵就能操作Redis，这是错误的。
- Cluster不需要哨兵：Cluster自身集成了监控与故障转移，部署哨兵会导致混乱。
- 数据丢失风险：主从异步复制，主节点宕机时尚未同步到从节点的数据会丢失。如果业务要求零丢失，需使用WAIT命令或考虑Redis的强一致性方案（如RedLock，但性能下降）。
- 主观下线与客观下线的区别：理解这两个概念有助于排查网络分区问题。
结语
从主从复制到哨兵再到Cluster，Redis的高可用演进遵循“先解决有无，再解决容量和性能”的路径。主从复制是基石，哨兵实现了自动化，Cluster则提供了无限扩展的可能。在生产环境中，不应盲目选择最复杂的方案，而应根据单机写入压力、数据总量、跨槽操作需求以及运维能力来决定。理解每个模式的原理和局限，是避免踩坑的关键。
延伸阅读