redis哨兵机制

哨兵机制核心作用

核心操作流程

哨兵的配置

 启动命令： redis-server sentinel.conf --sentinel

# 配置文件在sentinel运行期间是会被动态修改的
# sentinel如果重启时，就可以根据这个配置来恢复其之前所监控的redis集群的状态
# 绑定IP
bind 0.0.0.0
# 默认yes，没指定密码或者指定IP的情况下，外网无法访问
protected-mode no
# 哨兵的端口，客户端通过这个端口来发现redis
port 26380
# 哨兵自己的IP，手动设定也可自动发现，用于与其他哨兵通信
sentinel announce-ip
# 临时文件夹
dir /tmp
# sentinel监控的master的名字叫做mymaster,地址为 60.205.209.106 6380,两个及以上哨兵认定为死亡，才认为是真的死亡
sentinel monitor mymaster 60.205.209.106 6380 2
# 发送心跳PING来确认master是否存活
# 如果master在“一定时间范围”内不回应ping 或者是回复了一个错误消息，那么这个sentinel会主观地(单方面地)认为这个master已经不可用了
sentinel down-after-milliseconds mymaster 1000
# 如果在该时间（ms）内未能完成failover操作，则认为该failover失败
sentinel failover-timeout mymaster 3000
# 指定了在执行故障转移时，最多可以有多少个从Redis实例在同步新的主实例，在从Redis实例较多的情况下这个数字越小，同步的时间越长，完成故障转
移所需的时间就越长
sentinel parallel-syncs mymaster 1

sentinel  通过info replication   发现redis主从信息

主观下线

    单个哨兵自身认为redis实例已经不能提供服务

   检测机制：哨兵向redis发送ping请求，+PONG\-LOADING\MASTERDOWN这三种情况视为正常，其他回复均视为无效。

   对应配置文件的配置项：sentinel down-after-milliseconds mymaster 1000

客观下线

   一定数量值的哨兵认为master已经下线。

 检测机制：当哨兵主管认为master下线后，则会通过SENTINEL is-master-down-by-addr命令，询问其他哨兵是否认为master已经下线，如果达成共识（达到quornum个数），就会认为master节点客观下线，开始故障转移流程。

对应配置文件的配置项：sentinel monitor mymaster 192.168.0.105  6380 2

slave选举方案

节点状态：非 S_DOWN,O_DOWN，DISCONNECTED
 判断规则：(down-after-milliseconds * 10) +milliseconds_since_master_is_in_SDOWN_stateSENTINEL slaves mymaster

优先级: redis.conf中的一个配置项： slave-priority 值越小，优先级越高

数据同步情况：Replication offset processed

最小的run id:run id 比较方案： 字典顺序， ASCII码

主从切换的过程

针对即将成为master的slave节点，将其撤出主从集群
自动执行：slaveof NO ONE
针对其他slave节点，使它们成为新master的从属
自动执行：slaveof new_master_host new_master_port

哨兵如何通信的

1.哨兵之间的自动发现 2.哨兵之间通过命令进行通信 3.哨兵之间通过订阅发布进行通信 

哨兵领导选举机制

基于Raft算法实现的选举机制，流程简述如下：
1. 拉票阶段：每个哨兵节点希望自己成为领导者；
2. sentinel节点收到拉票命令后，如果没有收到或同意过其他sentinel节点的请求，就同意该sentinel
节点的请求（每个sentinel只持有一个同意票数）；
3. 如果sentinel节点发现自己的票数已经超过一半的数值，那么它将成为领导者，去执行故障转移；
4. 投票结束后，如果超过failover-timeout的时间内，没进行实际的故障转移操作，则重新拉票选举。

注： 以了解raft协议为主。https://raft.github.io/、http://thesecretlivesofdata.com/raft/