哨兵模式Sentinel：
自动感知Master故障并选择一个Slave切换为Master，实现故障的自动转移能力。
1.监控:持续监控主从是否健康，是否处于预期的工作状态.
2.主从的动态切换：当Master故障后，哨兵启动自动故障恢复：从slave中选一个新的master
3.通知机制：竞选出来新的master后，通知客户端与新master建立连接；slave从新的master中replicaof，保持主从数据一致性
一、监控：
首先是哨兵模式的配置。
哨兵配置文件：
# 指定哨兵进程的端口号 port 26379 # 指定监控的主节点的名称 sentinel monitor mymaster 127.0.0.1 6379 2 # 指定在主节点无响应时，多少毫秒后进行判断主节点是否宕机 sentinel down-after-milliseconds mymaster 5000 # 指定进行故障切换时最少需要多少个哨兵同意 sentinel parallel-syncs mymaster 1 # 指定进行故障切换时，新的主节点和旧的主节点之间数据同步的超时时间 sentinel failover-timeout mymaster 180000 # 指定将新的主节点提升为主节点之后，需要执行的脚本 # （例如，通知其他应用程序更新Redis配置等） sentinel notification-script mymaster /path/to/your/notification/script
# sentinel monitor <master-name> <master-host> <master-port> <quorum>
# 举例如下：
sentinel monitor mymaster 127.0.0.1 6379 2
这条配置项用于告知哨兵需要监听的主节点：
- sentinel monitor：代表监控。
- mymaster：代表主节点的名称，可以自定义。
- 192.168.11.128：代表监控的主节点 ip，6379 代表端口。
- 2：法定数量，代表只有两个或两个以上的哨兵认为主节点不可用的时候，才会把 master 设置为客观下线状态，然后进行 failover 操作。
客观下线 的标准就是，当有 N 个哨兵实例时，要有 N/2 + 1 个实例判断 master 为 主观下线 ，才能最终判定 master 为 客观下线 ，其实就是过半机制。
哨兵模式启用的时候，会启用sentinel进程，sentinel进程会向所有的master和slaves和其他sentinel进程发送心跳包（默认1s），看看返回是否正常。
如果从节点没有响应哨兵的PING，哨兵会认为从节点挂了，将tag为下线。
如果主节点没有响应哨兵的PING，哨兵会认为主节点offline离线，多做一步主节点的切换工作。
但是这里要注意：网络拥塞、master实例假死、请求延迟导致的master实例在某个短时间内不可用，又迅速恢复了。
基于以上的假死情况，我们做了标识区分：主观下线和客观下线。
主观下线：
从节点不回复PING直接下线没有问题，因为多从节点，一个下线误判叶不会影响什么，可以切换到其他从节点。主节点的下线，由于怕误判，所以要通过多个sentinel
投票决定是否下线，超过半数哨兵决定对master下线，才进行下线。当sentinel认为主节点下线，但还没有集群投票的时候，是主观下线，并不是真正的客观下线。
客观下线：
当多个哨兵决定对master下线时，对master标记为客观下线。
二、主从状态的切换：
1.筛选
1) 过滤掉不健康的从节点
2）评估从节点网络状态，如果在一定周期内断连超过一定次数，不予考虑使用。
2.综合评估
筛选掉不健康的从节点，我们从健康的从节点按照一定的顺序进行主节点的选举。
1）根据从节点配置的slave-priority优先级顺序。
2）选择一个和主节点数据偏移差最小的，即和主节点数据最接近的一个。
3）在优先级和复制进度相同的情况下，根据slave RunId选择runid最小的，runid越小说明创建的越早。
3.信息通知
等推选出最新的master之后，后续所有的写操作都会进入这个master中。所以需要尽快通知到所有的slave，让他们重新 replacaof 到 master上，重新建立runID和slave_repl_offset ，来保证数据的正常传输和主从一致性
1）客户端写操作与master建立连接
2）slave重新与master建立连接和数据同步
三、哨兵通信
哨兵直接是如何通信？
通过Redis的pub/sub发布订阅机制。
哨兵与master建立通信之后，可以利用master提供发布订阅机制发布自己的ip、port等信息。
master 有一个 sentinel:hello 的专用通道，用于哨兵之间发布和订阅消息。哨兵们都可以通过该通道发布自己的Name、IP、Port消息，同时订阅其他哨兵发布的Name、IP、Port消息。互相发现之后建立起了连接，后续的消息通信就可以直接进行了。
哨兵如何与slave建立联系？
哨兵给主节点发INFO命令，主节点把关联slave的表给哨兵进行同步。
哨兵如何与客户端进行时间通知？
依旧是通过 pub/sub 机制，发布不同事件，让客户端在这里订阅消息。客户端可以订阅哨兵的消息，哨兵提供的消息订阅频道有很多，不同频道包含了主从库切换过程中的不同关键事件。
Redis中的发布订阅模式：
PUBLISH channel_name message 向指定频道发送消息
SUBSCRIBE channel1 channel2 订阅一个或多个频道
message channel_name message 当订阅的频道中有消息发布时，订阅者会收到消息。
UNSUBSCRIBE channel1 channel2 取消订阅