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/tmp
4 
5 sentinel monitor mymaster 10.6.144.155 7030 1
6 sentinel down-after-milliseconds mymaster 5000
7 sentinel parallel-syncs mymaster 1
8 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，至于mymaster只是一个名字，可以随便起，但要保证5-8行都使用同一个名字
第6行，表示如果5s内mymaster没响应，就认为SDOWN
第8行，表示如果15秒后,mysater仍没活过来，则启动failover，从剩下的slave中选一个升级为master

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

具体使用步骤：(约定7030是redis-server端口，7031是redis-sentinel端口，且master、slave上的redis-server均已正常启动)
1、先在redis根目录下创建conf子目录，新建配置文件sentinel.conf，内容参考前面的内容(master和slave上都做相同的配置)
2、./redis-sentinel ../conf/sentinel.conf 即可(master和slave上都启用sentinel，即最终有二个哨兵)
3、./redis-cli -p 7031 sentinel masters 可通过该命令查看当前的master节点情况(注，这里一定要带sentinel的端口)
4、在master上，./redis-cli -p 7030 shutdown ，手动把master停掉，观察sentinel的输出

具体使用步骤：(约定7030是redis-server端口，7031是redis-sentinel端口，且master、slave上的redis-server均已正常启动)
1、先在redis根目录下创建conf子目录，新建配置文件sentinel.conf，内容参考前面的内容(master和slave上都做相同的配置)
2、./redis-sentinel ../conf/sentinel.conf 即可(master和slave上都启用sentinel，即最终有二个哨兵)
3、./redis-cli -p 7031 sentinel masters 可通过该命令查看当前的master节点情况(注，这里一定要带sentinel的端口)
4、在master上，./redis-cli -p 7030 shutdown ，手动把master停掉，观察sentinel的输出
[17569] 21 Nov 11:06:56.277 # +odown master mymaster 10.6.144.155 7030 #quorum 1/1
[17569] 21 Nov 11:06:56.277 # Next failover delay: I will not start a failover before Fri Nov 21 11:07:26 2014
[17569] 21 Nov 11:06:57.389 # +config-update-from sentinel 10.6.144.156:7031 10.6.144.156 7031 @ mymaster 10.6.144.155 7030
[17569] 21 Nov 11:06:57.389 # +switch-master mymaster 10.6.144.155 7030 10.6.144.156 7030
[17569] 21 Nov 11:06:57.389 * +slave slave 10.6.53.131:7030 10.6.53.131 7030 @ mymaster 10.6.144.156 7030
从红线部分可以看出，master发生了迁移，等刚才停掉的master再重启后，可以观察到它将被当作slave加入，类似以下输出：
[36444] 21 Nov 11:11:14.540 * +convert-to-slave slave 10.6.144.155:7030 10.6.144.155 7030 @ mymaster 10.6.144.156 7030
注意事项：发生master迁移后，如果遇到运维需要，想重启所有redis，必须最先重启“新的”master节点，否则sentinel会一直找不到master。
最后，如果想停止sentinel，可输入命令./redis-cli -p 7031 shutdown

本文出自 “梦想照进现实” 博客，请务必保留此出处http://lookingdream.blog.51cto.com/5177800/1861850

redis可用性提升（哨兵sentinel）配置示例