主从复制虽然可以提供高可用，但是也面临着一些问题，在主从复制模式下，如果主节点出现故障不可达，则会造成数据丢失，因为写操作集中在主节点，严重可能导致应用服务不可用；如果人工干预故障转移可能并不及时，即实时性和准确性无法保证，所以为了解决这个痛点，redis从2.8开始正式提供了sentinel模式。
sentinel是对高可用的进一步保证，当主节点出现故障是，sentinel可以自动进行故障的发现以及故障及时转移，并发出通知，更好保证了redis的高可用。
redis sentinel也是一个分布式架构，可以包含多个sentinel节点以及redis数据节点，每个sentinel节点会监控其他的sentinel节点以及redis数据节点，互相监控，确保不误判，一旦监测到有节点不可达，则对节点进行下线标识，当标识的是redis的数据主节点时，也就是主节点出现了故障，则sentinel与其他sentinel节点进行协商，当大部分的sentinel节点都认可主节点不可达时，就会一起推举一个sentinel节点来完成故障转移，并发送实时通知给使用者。
哨兵模式只是在原有的主从复制基础上多了若干sentinel节点，所以sentinel并没有什么很特别的地方，sentinel的作用就是用来监控数据节点并进行故障转移的。
接下来部署一下sentinel
在上一篇博客中介绍了主从复制的部署，所以利用上个博客已经搭建好的主从复制（多台云服务器中Redis的主从复制）；
接下来直接部署两个sentinel节点
首先配置两个redis所在服务器上sentinel的配置文件(即sentinel.conf文件）
配置的主要参数有：
port 26379
daemonize yes
logfile "26379.log"(可选项）
dir 文件路径
sentinel monitor mymaster 127.0.0.1 6379 2
（该参数说明：表示该sentinel节点监控127.0.0.1 6379这个数据主节点（位于阿里云主机上），2表示判断主节点失败至少需要两个sentinel节点同意，mymaster是主节点的别名）
sentinel down-after-milliseconds mymaster 30000（默认就是30秒）
sentinel parallel-syncs mymaster 1
当sentinel节点集合对主节点故障判定达成一致时，sentinel领导者节点会做故障转移操作，选出新的主节点，原来的从节点会向新的主节点发起复制操作，parallel-syncs就是用来限制在一次故障转移之后，每次向新的主节点发起复制操作的从节点个数，如果这个参数配置的比较大，那么多个从节点会向新的主节点发起复制操作，尽管复制操作通常不会阻塞主节点，但是同时向主节点发起复制，必然会对主节点所在的机器造成一定的网络和磁盘IO开销，存在着多个从节点的时候，如果设置为1的时候，则轮询发起复制，如果设置的数量等同于从节点数，则同时发起复制。
sentinel failover-timeout mymaster 180000（三分钟）
sentinel failover-timeout用于指定故障转移超时（毫秒）。它有多种用途：
1）如果sentinel对一个主节点故障转移失败，那么主节点在上次故障转移后重新启动故障转移所需的时间为2倍的failover-timeout超时时间。
2）如果sentinel节点在主节点故障后，选出来的从节点为主节点，在执行slaveof no one一直失败（例如该从节点出现故障），当此过程超过failover-timeout的时间，则故障转移失败。
3）如果选举出来的从节点执行成功，sentinel节点还会执行info信息来确认选举出来的从节点确实晋升为主节点。如果这个过程超过了failover-timeout时间，还是故障转移失败。
4）在命令其余的从节点去复制新的主节点的时间如果超过了failover-timeout时间（不包括复制过程的时间），则故障转移失败，及时超过这个时间，sentinel节点也会最终配置从节点去同步最新的主节点。
还有一个阶段，当原先的主节点恢复后，sentinel命令它去复制新的主节点。
上边的配置都可以保持默认配置,此外sentinel也可以配置验证auth-pass其他的还有很多配置参数（dentinel notification-script指定处理脚本等），具体可以查看sentinel.conf这个文件，里边每个参数都有详细的英文注释；同时将protected-mode no的注释去掉
启动sentinel节点的方式：
使用redis-sentienl sentinel配置文件路径
或者使用 redis-server sentinel配置文件路径 --sentinel
数据主节点启动sentinel
从节点上的sentinel也做好配置（监控主节点），然后启动sentinel
注意从节点上的sentinel要监控另一台机器上的主节点需要配置主节点的ip地址（阿里云主机的ip地址，而主节点上的sentinel可以直接用127.0.0.1是因为sentinel和主节点在同一台服务器上）
配置工作目录
其他保留默认配置，启动从节点上的sentinel（也是监控主节点）
从节点redis-server启动窗口的日志信息
接下来让主节点挂掉试一下
在主节点所在机器上使用kill命令杀掉redis-server
然后在主从节点机器上查看sentinel启动页面可以看到信息，主节点机器上的sentinel启动窗口上
可以看到sdown,down掉了，再看一下从节点上的sentinel启动窗口
然后重新启动原来的主节点，哨兵最好是再配置到另外的服务器上（即用于监测的sentinel节点和数据节点即主从节点部署在不同服务器上，相当于主从占用两台服务器或多台，sentinel再另外占用几台服务器），我的云主机就两台，不太好演示，最终的效果是，原来的主节点down掉，sentinel会切换新的主节点（从原先的从节点中选举，并且会修改主从节点的redis.conf文件中的配置，比如修改slaveof命令，让其他从节点服从于新的主节点）
因为我的有一个sentinel与主节点部署在一台机器，主节点server被关掉了，所以sentinel也挂掉了，sentinel依赖于redis-server,所以只有一台sentinel可以监测主节点故障(配置是需要至少两个sentinel监测选举主节点），所以原主节点启动后还是主节点。
以后如果活动再买一个云服务器吧，方便演示以及练习集群操作（其实可以开多个虚拟机，但是太消耗内存，没有云服务器用的爽）。