上一节中介绍了master-slave模式，在最小配置：master、slave各一个节点的情况下，不管是master还是slave down掉一个，“完整的”读/写功能都将受影响，这在生产环境中显然不能接受。幸好redis提供了sentinel（哨兵）机制，通过sentinel模式启动redis后，可监控master/slave的运行状态，基本原理是：心跳机制+投票裁决

每个sentinel会向其它sentinal、master、slave定时发送消息，以确认对方是否“活”着，如果发现对方在指定时间（可配置）内未回应，则暂时认为对方已挂（所谓的“主观认为宕机” Subjective Down，简称SDOWN）。

若如果“哨兵群”中的多数sentinel，都报告某一master没响应，系统才认为该master彻底死亡(即：客观上的真正down机，Objective Down，简称ODOWN)，通过一定的vote算法，将从剩下的slave节点中，选一台提升为master，然后自动修改相关配置。

最小化的sentinel配置文件为：

1 port 70312 3 dir /opt/app/redis/redis-2.8.17/tmp4 5 sentinel monitor mymaster 10.6.144.155 7030 16 sentinel down-after-milliseconds mymaster 50007 sentinel parallel-syncs mymaster 18 sentinel failover-timeout mymaster 15000

第1行，指定sentinel使用的端口，不能与redis-server运行实例的端口冲突

第3行，指定工作目录

第5行，显示监控master节点10.6.144.155，master节点使用端口7030，最后一个数字表示投票需要的"最少法定人数"，比如有10个sentinal哨兵都在监控某一个master节点，如果需要至少6个哨兵发现master挂掉后，才认为master真正down掉，那么这里就配置为6，最小配置1台master，1台slave，在二个机器上都启动sentinal的情况下，哨兵数只有2个，如果一台机器物理挂掉，只剩一个sentinal能发现该问题，所以这里配置成1

第6行，表示如果5s内mymaster没响应，就认为SDOWN

第8行，表示如果15秒后,mysater仍没活过来，则启动failover，从剩下的slave中选一个升级为master

第7行，表示如果master重新选出来后，其它slave节点能同时并行从新master同步缓存的台数有多少个，显然该值越大，所有slave节点完成同步切换的整体速度越快，但如果此时正好有人在访问这些slave，可能造成读取失败，影响面会更广。最保定的设置为1，只同一时间，只能有一台干这件事，这样其它slave还能继续服务，但是所有slave全部完成缓存更新同步的进程将变慢。

另：一个sentinal可同时监控多个master，只要把5-8行重复多段，加以修改即可。

redis 学习笔记(4)-HA高可用方案Sentinel配置