主从复制虽然提高了数据的高可用性，但是存在的问题是遇到故障时不能自动恢复，比如一个主从服务中，一个服务器宕机了，那就得手动的将一台从服务器转换成主服务，这段时间内服务就得关闭，造成一段时间内服务不能够使用，影响了用户体验。而哨兵就能解决故障恢复无法自动化的问题。
哨兵通过发送命令给多个节点，等待Redis服务器响应，监控运⾏的多个Redis实例的运⾏情况当哨兵监测到主服务宕机，会⾃动选取其中一台从服务器切换成主服务，通知其它的从服务器并修改配置⽂件。
典型哨兵框架：
简单哨兵框架
哨兵的三个作用：
监控(（Monitoring):监控主从节点是否正常运行及其运行情况
通知：(Notification）: 当哨兵监测到某个节点出现问题时，哨兵会通过API向其他应用程序发送通知
自动转移故障（Automatic failover）：当检测到主节点宕机后，断开与宕机主节点连接的所有从节点，在从节点中选取一个作为主节点，然后将其他的从节点连接到这个最新主节点的上。当客户端试图连接失效的主服务器时，集群也会向客户端返回新主服务器的地址，使得集群可以使⽤新主服务器代替失效服务器
注意：哨兵也是一台Redis 服务器，只是不对外提供任何服务
哨兵相关配置：
sentinel auth-pass masterNamepassword
sentinel auth-pass定义服务的密码
sentinel monitor {masterName} {masterIp} {masterPort} {quorum}
masterName指定了主节点名称，masterIp和masterPort指定了主节点地址，quorum是判断主节点客观下线的哨兵数量阈值：当判定主节点下线的哨兵数量达到quorum时，对主节点进行客观下线。
sentinel down-after-milliseconds {masterName} {time}
sentinel down-after-milliseconds与主观下线的判断有关：哨兵使用ping命令对其他节点进行心跳检测，如果其他节点超过down-after-milliseconds配置的时间没有回复，哨兵就会将其进行主观下线。down-after-milliseconds的默认值是30000，即30s；可以根据不同的网络环境和应用要求来调整：值越大，对主观下线的判定会越宽松，好处是误判的可能性小，坏处是故障发现和故障转移的时间变长，客户端等待的时间也会变长。
sentinel failover-timeout {masterName} {time}
sentinel failover-timeout与故障转移超时的判断有关，但是该参数不是用来判断整个故障转移阶段的超时，而是其几个子阶段的超时，例如如果主节点晋升从节点时间超过timeout，或从节点向新的主节点发起复制操作的时间(不包括复制数据的时间)超过timeout，都会导致故障转移超时失败。failover-timeout的默认值是180000；如果超时，则下一次该值会变为原来的2倍。
sentinel哨兵核心流程：
Sentinel会每秒Ping一下监测节点是否能够正常运行，超过时间不响应，则认为主观下线。Sentinel 在给定的时间范围内，从其他 Sentinel 那 ⾥接收到了⾜够数量的主服务器下线报告，那么 Sentinel 就会将主服务器的状态从主观下线改变 为客观下线。之后投票选择主节点，如果没有⾜够的节点同意master下线，则状态会被移除。
上面有关的相关概念：
主观下线：⼀个服务器没有在down-after-milliseconds 选项所 指定的时间内， 对向它发送 PING 命令的 Sentinel 返回⼀个有效回复（valid reply）哨兵节点就会将其进行主观下线。
客观下线：哨兵节点在对主节点进行主观下线后，会通过sentinel is-master-down-by-addr命令询问其他哨兵节点该主节点的状态；如果判断主节点下线的哨兵数量达到一定数值，则对该主节点进行客观下线。
若有不对之处还希望指正为谢！@~@
引用：《Redis设计与实现》、《Redis实战》
网友评论