“锵”，上回我们讲到Redis主从模式，可谓是一山还有一山高，我来给大家讲讲Redis哨兵模式。。。
哨兵（Sentinel）
注意：此哨兵非 Alibaba Sentinel，各位看官莫要搞混！
Sentinel（哨兵模式架构图）
哨兵原理
sentinel(哨兵)是用于监控redis集群中Master状态的工具，其本身也是一个独立运行的进程，是Redis的高可用解决方案，sentinel哨兵模式已经被集成在redis2.4之后的版本中。sentinel可以监视一个或者多个redis master服务，以及这些master服务的所有从服务；当某个master服务下线时，自动将该master下的某个从服务升级为master服务替代已下线的master服务继续处理请求，并且其余从节点开始从新的主节点复制数据
哨兵实现
在redis的根目录下，可以看到已经有了一个sentinel.conf配置文件，直接修改之
# 先CD 到Redis跟目录下面，然后编辑sentinel.conf文件
vim sentinel.conf配置参数详解：
- sentinel master
需要监视的主节点IP和端口以及quorum，quorum这个表示多少个sentinel节点认为主节点已经挂掉了，才视为主节点下线，即客观下线； 同时quorum还跟sentinel节点的leader选举有关系，至少要max(quorum,sentinel节点数/2 + 1)个sentinel节点参加选举，才能选举出leader,从而进行故障转移。
- sentinel down-after-milliseconds
每一个sentinel节点都会向主节点，从节点和其他sentinel节点1秒钟ping一次。在down-after-milliseconds毫秒内没有进行回复，sentinel节点就会判定该节点失败，这个行为叫做主观下线。
- sentinel parallel-syncs
当sentinel领导者开始进行故障转移的时候，选出新的主节点，原来的从节点会向新的主节点发起复制操作，parallel-syncs就是用来限制在一次故障转移之后，每次向新的主节点同时发起复制操作节点个数。如果这个值较大， 虽然一般不会阻塞主节点，但是会给网络和磁盘IO带来开销。
- sentinel failover-timeout
故障转移超时时间
- sentinel auth-pass
如果sentinel监控的主节点设置了密码，sentinel auth-pass配置通过添加主节点的密码，防止sentinel节点对主节点无法监控。
- sentinel notification-script
在故障转移期间，当一些警告级别的sentinel事件发生时，会触发对应的脚本，并向脚本发送相对应的事件参数。
Sentinel.conf进行配置
#增加以下内容：注意如有重复内容需要去掉
#-----------------------------------
#绑定外网访问权限DNS路由
bind 0.0.0.0
#mymaster 主节点名,可以任意起名，但必须和后面的配置保持一致
# 2 为需要主服务器断掉时需要2个sentinel同意（sentinel本身也可以集群）
sentinel monitor mymaster 192.168.223.128 6379 2
#设置Sentinel认为服务器已经断线所需的毫秒数
sentinel down-after-milliseconds mymaster 10000
#设置failover（故障转移）的过期时间。当failover开始后，在此时间内仍然没有触发任何failover 操作，当前 sentinel 会认为此次failover失败
sentinel failover-timeout mymaster 60000
#设置在执行故障转移时， 最多可以有多少个从服务器同时对新的主服务器进行同步， 这个数字越小，表示 同时进行同步的从服务器较多，那么完成故障转移所需的时间就越长。
sentinel parallel-syncs mymaster 1启动哨兵
#把三台redis服务跑起来
./bin/redis-server redis.conf
#再启动哨兵进程，哨兵启动需要使用redis-sentinel启动脚本启动
./bin/redis-sentinel sentinel.conf
可以看到，129/130作为从节点已经挂载到了128主节点下了
手动Down掉master节点：
根据Log可以看出sentinel进行在master节点down掉之后进行了一系列的举措
- sentinel检测到主节点挂掉
- vote-for-leader :进行投票选举
- 选举结束之后开始failover进行故障转移
哨兵模式的优缺点
优点：
1、当Master节点挂掉时，会通过vote算法从Slave节点中选举出一个新的节点作为Master节点继续工作
2、任何一个数据的增删改都需要Master节点处理，能保障数据的强一致性，符合CAP定理中的CP原则
缺点
1.主从服务器的数据要经常进行主从复制，这样造成性能下降。
2.当主服务器宕机后，从服务器切换成主服务器的那段时间，服务是不可用的，降低了高可用性
人生苦短，且自娱自乐！
