相信通过前面4篇笔记，大家对redis的基本概念及配置已经有了解，本篇笔记重点说明如何通过官方发布的redis sentinel工具来监控redis的运行状态。另外，对sentinel使用过程中的注意事项做些讨论。 1. Redis Sentinel功能 Redis Sentinel是一套用于管理Redis实
相信通过前面4篇笔记，大家对redis的基本概念及配置已经有了解，本篇笔记重点说明如何通过官方发布的redis sentinel工具来监控redis的运行状态。另外，对sentinel使用过程中的注意事项做些讨论。
1. Redis Sentinel功能
Redis Sentinel是一套用于管理Redis实例的分布式系统，主要完成3项任务：
1) Monitoring：持续监控Redis master或slave实例的运行情况是否符合预期
2) Notification：若被监控的Redis实例运行异常，sentinel会通过API通知外界（人或程序）
3) Automation failover：若master实例故障，sentinel会重新选主并启动自动故障切换：选择slave-priority最小的那个slave实例并将其提升为master，同时修改其它slave的配置，使其master配置项指向新的master，当old master恢复重启后，会自动降级为new master的slave。最后，根据配置，Redis Sentinel还会将新的master地址通知给当前正在访问Redis的应用程序。
2. Redis Sentinel部署
Sentinel作为一个分布式系统工具，建议多机房多机部署。
2.1 sentinel配置文件
每个sentinel实例主要有6个配置项，按Redis集群的实际部署情况进行配置即可，示例如下：
port 26329
sentinel monitor mymaster 127.0.0.1 6379 2
sentinel down-after-milliseconds mymaster 60000
sentinel failover-timeout mymaster 180000
sentinel parallel-syncs mymaster
sentinel notification-script
其中：
port: 指定sentinel的侦听端口（即与redis server或client建立tcp连接的端口）
monitor: 指定sentinel要monitor的redis实例，包括一个redis实例的别名（alias）及redis实例的ip+port，该行最后的数字2表示
至少2个setinel实例同时检测到redis server异常时，才将redis server的状态判决为real fail。也即，若这里配置为2，但实际部署中sentinel只部署了1套，则即使redis实例已经挂掉，sentinel也不会给出任何警告。
这一点需要特别引起注意。
down-after-milliseconds: 指定sentinel监控到redis实例持续异常多长时间后，会判决其状态为down。
若实际业务需要sentinel尽快判决出redis实例异常，则该值可适当配小。
failover-timeout: 若sentinel在该配置值内未能完成failover操作（即故障时master/slave自动切换），则认为本次failover失败。该配置有4个用途，具体可参考sentinel.conf中的说明，限于篇幅，此处不再赘述。
parallel-syncs: 指定failover过程中，同时被sentinel reconfigure的最大slave实例数。由于reconfigure过程中，对应的slave会中断响应客户端请求，故为避免所有的slave同时不可用，该值需适当配小。
notification-script: 指定sentinel检测到master-name指向的实例异常时，调用的报警脚本。该配置项可选，但线上系统建议配置。
2.2 启动监控系统
配置文件修改完成后，启动各监控进程即可，例如：
nohup ./bin/redis-sentinel ./conf/sentinel.conf > ./log/redis-sentinel.log 2>&1 &
2.3 sentinel使用场景实测
为调研并掌握sentinel用法，我搭建了redis测试环境并做了一系列实验，下面对实验情况做详细说明。
特别说明：由于下面的内容可能会涉及到公司内网地址，故为避免不必要的麻烦，文字或截图出现ip地址的地方做了涂抹，但不影响说明问题。
实验环境（one master / two slaves / two sentinels）：
a. 一个master（slave-priority为100）部署在ip为xx.xx.234.67的机器上；
b. 两个slaves（slave-priority分别为90/100）的均部署在ip为xx.xx.234.49的机器上；
c. 启用两个sentinel进程监控redis集群状态
做了6种case的测试，结果说明如下：
Case1: 依次启动master进程及2个slave进程后，再启动2个sentinel进程，sentinel可以正常识别出主从关系
Case2: 用shutdown命令停掉master，则sentinel自动选slave-priority小的那个slave进程为new master，同时，自动将另一个slave进程的master指向该new master
Case3: 在case2基础上，重启old master，sentinel会将其降级为slave，其master指向case2选出的新主
Case4: 将master和2个slave实例的slave-priority配为互不相同的值，在Case1基础上，shutdown当前的master，在sentinel已选出新主且reconfigure其它实例使它们指向新主后（从old master异常到触发sentinel重新选主的时间由用户通过sentinel.conf的down-after-milliseconds配置项指定），重启old master，系统最终状态与Case3一致，即old master已降级为slave，其master指向sentinel选出的新主。
若在sentinel已选出新主但尚未完成其它实例的reconfigure之前，重启old master，则整个系统会出现无法选出new master的异常，详情见下面Case5的描述。
Case5: 将master和2个slave实例的slave-priority均配为相同的值，在Case1基础上，shutdown当前的master，在sentinel已选出新主且reconfigure其它实例使它们指向新主后，重启old master，系统最终状态与Case3一致，即old master已降级为slave，其master指向sentinel选出的新主。在所有slave-priority配置为相同值的情况下，sentinel会将各slave实例中runid最小的slave提升为master（前提是该slave对应的redis.conf中允许其被promote为master）。
与Case4出现的异常情况类似，若在sentinel选出新主但尚未完成其它实例的reconfigure之前，重启old master，会发现sentinel的自动故障切换机制已然凌乱了。
详细的异常情况如下所述。
old master部署在ip为xx.xx.234.67的机器上且port默认为6379，sentinel切换异常后，对该old master执行info命令输出如下：
slave-00实例在ip为xx.xx.234.49的机器上且port配为6378，sentinel切换异常后，info输出如下：
slave-01实例在ip为xx.xx.234.49的机器上（与slave-00同机部署）且port配为6377，info输出如下：
从上面3个redis实例的输出情况看，3个均认为自己是slave，整个系统无主！其中，位于xx.xx.234.67的old master（注意上面第1图的master_host字段）和位于xx.xx.234.49的salve-00（注意上面第2图的master_host字段）均认为slave-01为new master，而位于xx.xx.234.49的slave-01则认为自己仍然为slave，认为old master目前还是master（注意上面第3图的master_host字段）。
从sentinel进程日志看，其无法选出新主，即sentinel无法确认两个master candidates到底哪个是new master，在两个实例间频繁切换：
这种情况务在实际运维时务必要引起注意！
Case 6: 在系统已进入Case5所示的异常状态后，shutdown两个master candidates中的一个实例，sentinel仍然无法正常选主，直至3个实例全部shutdown，整个系统仍然无主。基本可以确定监控系统内部逻辑状态已经混乱了。
2.4 结论
若master实例故障，则最好等sentinel选出new master且稳定后（选新主并完成切换的时间与配置有关，典型值在1分钟之内），再重启old master，避免引发sentinel的误判，导致整个系统无法选出new master。
【参考资料】
1. Redis Sentinel Documentation
