Redis 高可用：主从模式 + 哨兵模式
· 4 min read
背景：单机 Redis 的问题
- 单机本质：Redis 是一个单机服务。
- 性能瓶颈：读写性能受限于单个服务器的 CPU 和内存上限。
- 可用性问题：一旦挂了，外部服务无法使用，缺乏高可用性。
解决方案一：经典主从模式
核心思想：加副本，分为主从关系。
节点职责
| 节点类型 | 对外提供 | 说明 |
|---|---|---|
| 主节点 | 读写操作 | 将写入的数据同步给从节点 |
| 从节点 | 读操作 | 分担读请求压力 |
优点
- 提升读性能（从节点越多，读请求量越高）
- 提升可用性（主节点挂后，可手动让从节点顶上）
部署方式
主从 Redis 分别部署在不同服务器上。
主从复制细节
问题
新增从节点时，从节点无数据，如何快速同步？
同步过程
- 全量同步：主节点将定期生成的 RDB 文件（内存数据持久化）传给从节点
- 增量同步：同步过程中的新写操作，记录到复制积压缓冲区（固定大小内存数组）
- 偏移量跟踪：数组下标为复制偏移量，用于跟踪主从同步进度
断点续传
从节点重启后，可根据当前偏移量继续未完成的复制。
主从切换的问题与改进
手动切换的问题
- 主节点挂后需要手动切换，存在时间差
- 自动化脚本（如 Keepalived）只能粗糙检测存活（进程、端口），无法感知内部状态（偏移量、数据一致性）
- 在多从节点场景下，被选为新主节点的可能不是最合适的
解决方案
引入哨兵（Sentinel）。
解决方案二：哨兵模式
哨兵是什么
- 一个监控 Redis 内部状态的独立进程
- 本质与 Redis 是同一套代码，通过不同启动参数部署
哨兵工作流程
- 获取主节点的从节点列表
- 每秒发送 ping 检查
- 发现主节点挂后，自动选择一个从节点顶上
选主规则（优先级从高到低）
| 优先级 | 规则 | 说明 |
|---|---|---|
| 1 | 配置优先级最高的从节点 | 如内存越大优先级越高 |
| 2 | 复制偏移量最大的从节点 | 数据最接近原主节点 |
| 3 | 运行 ID 最小的从节点 | 唯一标识，越小越优先 |
哨兵集群与高可用
问题
- 单点问题：只有一个哨兵，哨兵自己挂掉则无法管理
- 误判问题：哨兵与 Redis 节点网络问题可能导致误判
解决方案
组成哨兵集群。
下线判定
- 主观下线：单个哨兵认为某 Redis 节点下线
- 客观下线：大多数哨兵都认为该 Redis 下线，才确认真实下线
最终架构
哨兵集群 + 主从模式 = 哨兵模式
遗留问题
当前模式局限
- 所有节点仍需存储全量数据
- 写操作依然集中在主节点
- 无法突破单机性能瓶颈
下一步
引入集群模式（解决数据容量和写性能问题）。