Redis 哨兵机制

部署建议

a，sentinel节点应部署在多台物理机
b，至少三个且奇数个sentinel节点
c，监听一个主节点

配置

在主从配置的基础上，进行配置。

每个 redis 都有一个自己的 sentinel.conf

配置端口号：

配置 master 信息：
mymaster 对应下面的< master-name >，2 代表必须要有 2 个哨兵发现 master 挂掉才能进行选举
注意：master 这里也要改 ip，不能是 127.0.0.1

配置保护模式：
可以取消注释，方便在别的主机上启动哨兵

其他配置：

• sentinel failover-timeout mymaster180000
  故障转移超时时间180s
  a，如果转移超时失败，下次转移时时间为之前的2倍；
  b，从节点变主节点时，从节点执行slaveof no one命令一直失败的话，当时间超过180s时，则故障转移失败
  c，从节点复制新主节点时间超过180s转移失败
• sentinel down-after-milliseconds mymaster 30000
  sentinel节点定期向主节点ping命令，当超过了30s时间后没有回复，可能就认定为此主节点出现故障了……
• sentinel parallel-syncs mymaster 1
  故障转移后，1代表每个从节点按顺序排队一个一个复制主节点数据，如果为3，指3个从节点同时并发复制主节点数据，不会影响阻塞，但存在网络和IO开销

启动

启动注意先主后从。按顺序启动完服务端了，再按顺序启动哨兵。

启动服务端：
./redis-server redis.conf &

启动哨兵：
./redis-sentinel sentinel.conf &

登陆redis客户端，查看状态：
./redis-cli -a 12345678
info replication

哨兵客户端：
./redis-cli -p 26379
进入哨兵的命令模式
sentinel masters 或sentinel master mymaster
查看redis主节点相关信息
sentinel slaves mymaster
查看从节点状态与相关信息
sentinel sentinels mymaster
查sentinel节点集合信息（不包括当前26379）
sentinel failover mymaster
对主节点强制故障转移，没和其它节点协商

验证

192.168.100.14：

192.168.100.15：

192.168.100.16：

高可用原理

当主节点出现故障时，由redis sentinel自动完成故障发现和转移，并通知应用方，实现高可用性。

转移和通知哨兵的过程只需要一个哨兵节点来完成。

有三个定时监控任务完成对各节点的发现和监控。

三个任务

任务1：每个哨兵节点每10秒会向主节点和从节点发送info命令获取最拓扑结构图（如上图），通过向主节点发送info，获取从节点的信息，并当有新的从节点加入时可以马上感知到。

sentinel1=> master、slave1、slave2
sentinel2=> master、slave1、slave2
sentinel3=> master、slave1、slave2

任务2：每个哨兵节点每隔2秒会向redis数据节点的指定频道上发送该哨兵节点对于主节点的判断以及当前哨兵节点的信息，同时每个哨兵节点也会订阅该频道，来了解其它哨兵节点的信息及对主节点的判断，其实就是通过消息publish和subscribe来完成的。

sentinel1（publish） => 指定频道
sentinel2（publish） => 指定频道
sentinel3（publish） => 指定频道
sentinel1（subscribe） <= 指定频道
sentinel2（subscribe） <= 指定频道
sentinel3（subscribe） <= 指定频道

任务3：每隔1秒每个哨兵会向主节点、从节点及其余哨兵节点发送一次ping命令做一次心跳检测，这个也是哨兵用来判断节点是否正常的重要依据。

sentinel1=> master、slave1、slave2、sentinel2、sentinel3
sentinel2=> master、slave1、slave2、sentinel1、sentinel3
sentinel3=> master、slave1、slave2、sentinel1、sentinel2

主/客观下线

主观下线
刚我知道哨兵节点每隔1秒对主节点和从节点、其它哨兵节点发送ping做心跳检测，当这些心跳检测时间超过
down-after-milliseconds 时，哨兵节点则认为该节点错误或下线，这叫主观下线。这可能会存在错误的判断。

客观下线
当主观下线的节点是主节点时，此时该哨兵3节点会通过指令sentinel is-masterdown-by-addr寻求其它哨兵节点对主节点的判断，当超过quorum（法定人数）个数，此时哨兵节点则认为该主节点确实有问题。

领导者哨兵选举流程

a，每个在线的哨兵节点都可以成为领导者，当它确认主节点下线时，会向其它哨兵发is-master-down-by-addr命令，征求判断并要求将自己设置为领导者，由领导者处理故障转移；
b，当其它哨兵收到此命令时，如果没有同意通过其他Sentinel节点发送命令,那么将同意该请求，否则拒绝；
c，如果该Sentinel节点发现自己的票数已经超过Sentinel集合半数且超过quorum,那么它将成为领导者；
d，如果此过程有多个Sentinel节点成为了领导者,那么将等待一段时间重新进行选举。

故障转移

机制

a）由Sentinel节点定期监控发现主节点是否出现了故障sentinel会向master 发送心跳PING来确认master是否存活，如果master在“一定时间范围”内不回应PONG或者是回复了一个错误消息，那么这个sentinel会主观地（单方面地）认为这个master已经不可用了

b）当主节点出现故障（如果是宕机，那么sentinel-1也没了，但没关系），此时3个Sentinel节点共同选举了Sentinel3节点为领导，负载处理主节点的故障转移

C）由Sentinel3领导者节点执行故障转移，过程和主从复制一样，但是自动执行
D，故障转移后的 redis sentinel 的拓扑结构图

流程

A，过滤掉不健康的（下线或断线），没有回复过哨兵ping响应的从节点
B，选择slave-priority从节点优先级最高（redis.conf）
C，选择复制偏移量最大，指复制最完整的从节点