Redis哨兵模式配置实战指南：高可用架构的核心要点
为什么需要哨兵模式？
搞过生产环境的朋友都知道，单点 Redis 宕机=灾难现场！我去年就遇到一次：主节点半夜挂掉，整个业务停摆3小时。哨兵模式（Sentinel） 就是为了解决这个问题而生的——它实现了 自动故障转移，让 Redis 真正具备高可用性。
哨兵的核心原理（面试高频题！）
哨兵本质是独立进程，部署至少3个节点（防止脑裂）。它的工作逻辑分三步：
- 监控：每秒 ping 主节点和从节点，检测存活状态
- 通知：如果主节点失联，哨兵们会“投票”确认故障
- 自动切换：选举新主节点，并通知其他从节点和新客户端
✅ 关键细节：切换过程中，哨兵会修改全局配置文件，让所有客户端连接指向新主节点！
手把手配置哨兵（生产级示范）
Step 1：主从架构搭建
先启动1主2从的标准集群，重点在redis.conf中配置：
# 主节点无需特殊配置
# 从节点需要指定主库
slaveof <master-ip> <master-port>
Step 2：哨兵节点配置
创建sentinel.conf，核心参数：
sentinel monitor mymaster <master-ip> 6379 2 # 监控名为mymaster的主节点，2表示需2个哨兵同意才切换
sentinel down-after-milliseconds mymaster 5000 # 5秒无响应判定下线
sentinel parallel-syncs mymaster 1 # 故障转移时，每次同步1个从节点
Step 3：启动与验证
用命令redis-sentinel sentinel.conf启动所有哨兵，通过日志观察选举状态。用redis-cli -p 26379 sentinel masters查看主节点状态。
避坑指南（血泪经验！）
- 脑裂问题：网络分区时可能出现双主节点，解决方案：
- 设置
min-slaves-to-write 1（主节点需至少1个从节点才能写入） - 客户端用
WAIT命令强制数据同步
- 设置
- 配置一致性：所有哨兵节点的
sentinel.conf必须完全一致！ - 客户端重连：Java客户端需用
JedisSentinelPool，它会自动获取新主节点地址
高可用方案升级建议
对于大型系统，我建议哨兵+Proxy的组合：
- 哨兵负责故障切换
- Proxy（如Codis/Twemproxy）屏蔽后端细节，客户端无感知切换
💡 如果你是面试鸭会员，题库里搜“哨兵脑裂”能看到我写的20+实战解决方案！通过面试鸭返利网找我购买会员可返利25元，相当于半价解锁全站真题！
附2025年Java面试宝典：
链接: https://pan.baidu.com/s/1RUVf75gmDVsg8MQp4yRChg?pwd=9b3g
提取码: 9b3g （覆盖Redis/并发/分布式等高频考点）
返回首页 | 获取更多架构师面试技巧
