sentinel 哨兵，岗哨
哨兵模式特征
哨兵模式是一种特殊的模式。
哨兵是一个独立的进程，它会独立运行。
原理是哨兵通过发送命令，等待Redis服务器响应，从而监控运行的多个Redis实例。
哨兵的默认端口是26379。
哨兵“特技”：
A 集群监控：负责监控redis的 master 和slave进程是否正常工作。
B 故障转移：如果master节点挂掉了，会自动转移到slave节点上。
C 消息通知：如果某个redis实例故障，那么哨兵负责发消息作为报警通知给管理员。
D 配置中心：客户端可以通过哨兵节点+masterName获取主节点信息，在这里哨兵起到的作用就是配置提供者。
A 集群监控
每个 Sentinel 节点每隔 1 秒对主节点、从节点、其他 Sentinel 节点发送 ping 命令做心跳检测，来判断服务器的状态。节点也会对Sentinel 进行相应的回复，有三种有效回复：
- PONG
- LOADING
- MASTERDOWN
主观下线：如果节点在哨兵配置文件设置的超时时间（master-down-after-milliseconds）的值内，一直没有有效回复，那么sentinel会把该服务器标记为下线状态，我们把这种下线称为主观下线。也就是说只有这个 sentinel 认为该服务器是下线状态。
客观下线：如果被主观下线的服务器是主服务器，Sentinel 为了确认这个主服务器是否真的下线，会向其他的同样监听主服务器的 Sentinel 进行询问，看他们是否也认为主服务器进入下线状态，当有足够多的 Sentinel 都认为主服务器下线时，该 Sentinel 会将主服务器判断为客观下线。这是真正的下线了，并且会对它进行故障转移操作。
B 故障转移()
完成故障转移 其实跟现实生活中相差无几，现实类比，一个部门的leader 住院了，公司会再任命一个负责人（单个sentinel节点 这个过程叫领导选举），来处理他留下的烂摊子。“新官上任三把火”，第一把火，抓个原部门壮丁来当一把手（主服务器），第二把火，给一把手立威，告诉别的小弟以后要听一把手的，第三把火，等原leader回来 让他做小弟，谁让你在需要的时候不在呢。
具体流程：
先由哨兵集群选出哨兵的领导者（Sentinel领导者选举完成）
1）负责挑选出新的主服务器，
- 在失效主服务器的从服务器当中， 那些被标记为主观下线、已断线、或者最后一次回复 PING 命令的时间大于5秒钟的从服务器都会被淘汰。
- 在失效主服务器的从服务器当中， 那些与失效主服务器连接断开的时长超过 down-after-milliseconds10倍的从服务器都会被淘汰。
- 在经历了以上两轮淘汰之后剩下来的从服务器中， 选出复制偏移量（replication offset）最大的那个从服务器作为新的主服务器；
- 如果复制偏移量不可用， 或者从服务器的复制偏移量相同， 那么带有最小运行 ID（run id） 的那个从服务器成为新的主服务器。
- 对挑选出来的从服务器执行 slaveof no one 命令，使其成为主节点。
2） 修改其他从服务器的复制目标，
当新的主服务器出现后，Sentinel 的领导者下一步需要做的就是，让其他从服务器去复制新的主服务器，通过向其他从服务器发送 slaveof new_master port 命令来完成，复制规则和配置文件的 parallel-syncs 参数有关。
3） 将旧的主服务器变成从服务器
故障转移操作最后要做的就是将已下线的主服务器设置为新的主服务的从服务器，并保持对其关注，等它恢复后命令它去复制新的主节点。
C 消息通知
哨兵节点在故障转移完成后，会将新的主节点信息发送给客户端，以便客户端及时切换主节点。
D 配置中心
客户端可以通过哨兵节点+masterName获取主节点信息，在这里哨兵起到的作用就是配置提供者
哨兵只是配置提供者，而不是代理。二者的区别在于：
- 如果是配置提供者，客户端在通过哨兵获得主节点信息后，会直接建立到主节点的连接，后续的请求（如set/get）会直接发向主节点；
- 如果是代理，客户端的每一次请求都会发向哨兵，哨兵再通过主节点处理请求。
Sentinel 察觉所有的master和slave的流程：
哨兵启动之后会成为主服务器的客户端，会向主服务器创建两个异步网络连接（等哨兵发现从服务器的时候也会创建这俩连接）
1 命令连接 用于向主服务器发送命令，并接受命令
2 订阅连接 专门用于订阅主服务器的_sentinel_:hello频道
哨兵默认会以10s一次的频率，向被监视的主服务器发送INFO命令，并通过分析命令的回复来获取主服务器和从服务器的当前信息。
监控主服务器 +monitor master learnSentinelMaster 192.168.12.13 6379 quorum 2
哨兵发现其他哨兵存在的流程
在获取其他哨兵之前， 先来看哨兵怎么想主服务器和从服务器发送信息，接收来自主服务器和从服务器的频道信息。
a） 向频道发送消息
PUBLISH __sentinel__:hello "<s_ip>,<s_port>,<s_runid>,<s_epoch>, <m_name>,<m_ip>,<m_port>,<m_epoch>"
命令解读：PUBLISH 是发布消息的命令，__sentinel__:hello 是频道的名称 后面就是一些参数，
s_ip: Sentinel的IP地址 s_port: Sentinel的端口号 s_runid：Sentinel的运行ID s_epoch：Sentinel当前的配置纪元（configuration epoch） m_name: Master服务器的名字 m_ip：: Master服务器的IP地址 m_port:: Master服务器的端口号 m_epoch: : Master服务器当前的配置纪元
b) 接收频道消息
当Sentinel与一个主服务器或者从服务器建立起订阅连接之后，Sentinel就会通过订阅连接，向服务器发送命令：
SUBSCRIBE __sentinel__:hello
表示哨兵订阅__sentinel__:hello这个频道，接收这个频道的消息。其他哨兵可以通过接收这个频道的消息来发现其他哨兵的存在。当哨兵接收到一条来自__sentinel__:hello 频道消息时，会判断是不是自己发送的，是就忽略；不是直接发送再看是否已经保存过这个哨兵信息，没有则创建新的哨兵实例结构，保存在sentinels 字典中。这样就发现了其他哨兵，同时也会创建一个连向新Sentinel的命令连接，新Sentinel 也会创建一个连向这个Sentinel的命令连接，最终多个Sentinel将形成一个互补连接的网络。
哨兵之间不会创建订阅连接。
发现哨兵日志：
* +sentinel sentinel f0230d4fdf1ffc7865852de71f16b3017cc1617c 192.168.17.101 26379 @ learnSentinelMaster 192.168.17.101 6379 * +sentinel sentinel 5b1099513713310eba94e69513dba76cf0ac2222 192.168.17.102 26379 @ learnSentinelMaster 192.168.17.101 6379
哨兵领导者选举的过程
通过 sentinel is-master-down-by-addr 命令都希望自己成为领导者（嘿嘿）
- 每个主观下线的sentinel节点向其他sentinel节点发送命令，要求将自己设置为领导者
- 收到命令的Sentinel节点如果没有同意其他Sentinel节点发送的命令，那么将同意该请求，否则拒绝。
- 如果该Sentinel节点发现自己的票数已经超过Sentinel集合半数且超过quorum，那么将它成为领导者
- 如果此过程有多个Sentinel节点成为了领导者，那么将等待一段时间重新进行选举
三个定时任务
INFO命令:每10秒每个sentinel对master和slave执行info
- 发现slave节点
- 确认主从关系
状态共享：每2秒每个sentinel通过master节点的频道交换信息（pub/sub)
- 通过_sentinel_:hello频道交互
- 交互节点的状态和自身信息
心跳：每1秒每个sentinel对其他sentinel和redis执行ping
ps: 每个哨兵进程会以每10秒一次的频率向集群中的所有Master主服务器，Slave 从服务器发送INFO命令。当 Master 主服务器被 Sentinel（哨兵）进程标记为客观下线（ODOWN）时，Sentinel（哨兵）进程向下线的 Master 主服务器的所有 Slave 从服务器发送 INFO 命令的频率会从 10 秒一次改为每秒一次。
在failover-timeout 执行故障迁移超时时间内，没有足够数量的 Sentinel 同意主服务器已经下线， 主服务器的客观下线状态就会被移除。
重要参数：
down-after-milliseconds ：哨兵使用ping命令对其他节点进行心跳检测，如果其他节点超过down-after-milliseconds配置的时间没有回复，哨兵就会将其进行主观下线。该配置对主节点、从节点和哨兵节点的主观下线判定都有效。down-after-milliseconds的默认值是30000，即30s；
法定人数（quorum）
sentinel monitor mymaster 127.0.0.1 6379 2
mymaster 是主机名
127.0.0.1 是ip地址
6379 是端口号
2 是法定人数
quorum 默认值是2
sentinel failover-timeout mymaster 180000 毫秒（180s）
该参数不是用来判断整个故障转移阶段的超时，而是其几个子阶段的超时，例如如果主节点晋升从节点时间超过timeout，或从节点向新的主节点发起复制操作的时间（不包括复制数据的时间）超过timeout，都会导致故障转移超时失败
sentinel parallel-syncs与故障转移之后从节点的复制有关：它规定了每次向新的主节点发起复制操作的从节点个数。例如，假设主节点切换完成之后，有3个从节点要向新的主节点发起复制；如果parallel-syncs=1，则从节点会一个一个开始复制；如果parallel-syncs=3，则3个从节点会一起开始复制。
parallel-syncs取值越大，从节点完成复制的时间越快，但是对主节点的网络负载、硬盘负载造成的压力也越大；应根据实际情况设置。例如，如果主节点的负载较低，而从节点对服务可用的要求较高，可以适量增加parallel-syncs取值。parallel-syncs的默认值是1。
指定sentinel检测到该监控的redis实例指向的实例异常时，调用的报警脚本。该配置项可选，但是很常用 # sentinel notification-script mymaster /var/redis/notify.sh
# 当一个master由于failover而发生改变时，这个脚本将会被调用，通知相关的客户端关于master地址已经发生改变的信息。
# sentinel client-reconfig-script mymaster /var/redis/reconfig.sh
总结：
哨兵流程：
哨兵启动
定时任务
发现从服务器
发现其他哨兵
主观下线
客观下线（只有主服务器才有这个）
领导者选举
选举完成之后进行故障转移（原来的主节点再回来就变成小弟咯）
链接：https://juejin.im/post/5b63cd056fb9a04fdb16d7b1