Redis哨兵模式监控那些事儿，实践中遇到的坑和经验分享

根据多位运维工程师和开发者在技术社区如CSDN、博客园、知乎上的分享文章以及部分公司内部技术文档整理而成）

Redis哨兵模式监控那些事儿，实践中遇到的坑和经验分享

刚开始用Redis哨兵的时候，觉得它真是个好东西，主库挂了，它能自动选个从库顶上去，业务几乎无感知，想想就省心，但真用起来，尤其是在线上环境扛流量的时候，才发现理想和现实差距不小,坑是一个接一个。

第一个大坑，网络抖动引发的“冤假错案”。 这是最经典也是最常见的问题。（来源：某电商平台运维团队复盘报告）我们的业务量不小，Redis集群压力挺大，有一次，机房网络出现轻微波动，其实就丢了一两个包，持续时间可能就一两秒，但就这一两秒，要了亲命了，哨兵之间、哨兵和Redis节点之间心跳检测超时了，哨兵很“负责任”地认为主库宕机了，立马启动切换流程，结果就是，旧主库其实活得好好的，新主库已经被选举出来了，瞬间，我们有了两个“主库”，这就是脑裂，一些客户端还连着旧主库写数据，另一边客户端向新主库写数据，等网络恢复，哨兵把旧主库降为从库，它会清空自己的数据，然后去同步新主库，这下好了，刚才写到旧主库的那部分数据，全丢了！那次造成了小范围的订单数据异常，教训惨痛，后来我们学乖了，调整了哨兵的配置，主要是down-after-milliseconds这个参数，把它从默认的30秒调大到60秒甚至更长，给它足够的容忍度,避免因短暂网络波动就误判主库下线。

第二个坑，配置不对，切换了也白搭。 （来源：一位个人开发者的博客分享）有一次我搭建测试环境，哨兵模式都配好了，模拟故障，主库kill掉，哨兵也确实执行切换了，但业务程序就是报错，连不上Redis，排查了半天，发现是哨兵配置文件里的sentinel announce-ip没设，这个参数是告诉客户端，我哨兵监听的IP是什么，在云服务器或者有公网内网之分的环境里，如果没设这个，哨兵通知给客户端的连接信息可能是个内网IP，而你的业务程序从外网根本访问不了这个内网IP，那切换得再成功，客户端也连不上新主库，服务照样中断，配置哨兵的时候，每个参数都得琢磨清楚,特别是和网络地址相关的。

第三个经验，监控不能只看哨兵说的“是否健康”。 （来源：某社交平台SRE团队经验分享）一开始我们的监控很简单，就是定时用redis-cli去连一下主库，能连上就报绿，连不上就告警，后来发现这太粗糙了，有时候主库虽然没挂，但可能因为持久化（AOF或RDB）操作、内存不足、CPU跑满等原因，已经响应非常慢了，基本处于半死不活的状态，这时候哨兵可能还没触发主观下线和客观下线（因为心跳还能收到回复，只是慢），但业务已经快崩了，所以我们加强了监控，不光监控连通性，还监控Redis的关键指标：内存使用率、连接数、每秒操作数（OPS）、延迟时间（Latency），特别是延迟，我们设了阈值，比如平均操作延迟超过50毫秒就触发预警,这样能更早地发现潜在问题。

第四个坑，客户端不够“聪明”。 （来源：多个技术社区讨论帖的共识）哨兵模式要生效，光服务器端配置好还不够，客户端也得给力，客户端需要支持哨兵协议，能够从哨兵那里获取最新的主库地址，但有些老的客户端库，或者配置不当的客户端，可能会有问题，客户端启动时从哨兵拿到了主库地址，然后就缓存起来一直用，不再更新，一旦发生主从切换，客户端还傻傻地连那个已经降级的老主库，当然就失败了，选择客户端库的时候，一定要选活跃维护的、对哨兵模式支持良好的，并且要确认客户端有重连和自动发现新主库的机制，我们就在这上面栽过跟头,后来统一了团队的客户端库版本和配置规范。

第五个分享，运维操作要格外小心。 （来源：某金融科技公司数据库团队操作手册）有次我们想给主库打个小补丁，计划内重启，心想反正有哨兵，重启主库会自动切换，没事，结果操作的时候，直接在主库服务器上执行了redis-cli shutdown，这一下，主库是正常关闭了，但哨兵监测到这个过程，依然会触发故障转移，虽然最终结果也是切换了，但这个过程被系统记录为一次“故障切换”，触发了报警，把运维同学吓了一跳，正确的做法应该是，先通过哨兵命令手动执行故障转移（SENTINEL failover <master-name>），让哨兵来主导一次安全的主从切换，等旧主库变成从库并完成数据同步后，再重启它，这样整个流程是受控的,不会触发不必要的故障警报。

Redis哨兵模式确实提供了高可用性，但它不是个一劳永逸的“黑盒”，你需要深入了解它的工作原理，根据自己公司的网络环境和业务特点，仔细 tuning 配置，建立完善的监控体系，并确保客户端兼容性，才能真正发挥它的价值，避免在关键时刻掉链子，这些坑和经验，都是我们真金白银换来的,希望对你有所帮助。