引言

哨兵机制是基于主从模式实现，作用有两点：

  • 监控master和slave是否正常运行
  • master出现故障时，自动将slave升级为master

哨兵的三个定时任务

来源于：哨兵机制的原理

任务1

每个哨兵节点每10秒会向主节点和从节点发送info命令获取最新的拓扑结构图,哨兵配置时只需要配置对主节点的监控即可，通过向主节点发送info，获取从节点的信息，并当有新的从节点加入时可以马上感知。

任务2

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

任务3

每隔1秒每个哨兵会向主节点、从节点、其他哨兵发送ping命令，做心跳检测。

主观下线与客观下线

主观下线

当任务3心跳时间过长时，哨兵节点认为该节点下线。

客观下线

当主观下线的节点时主节点时，该哨兵会联系其他哨兵对此主节点进行判断，大部分哨兵都统一下线时，次主节点为客观下线。

哨兵选举机制

当redis主节点下线后，哨兵会选出领导者哨兵来执行下一步的故障转移，哨兵的选举机制为raft算法。
规则：

  • 所有的哨兵都有被选举权。
  • 每次哨兵选举后，不管成功与失败，都会计数epoch。
  • 在一个epoch内，所有的哨兵都有一次将某哨兵设置为局部领头的机会，并且局部领头一旦设置，在这个epoch内就不能改变。
  • 每个发现主服务器进入客观下线的哨兵都会要求其他哨兵选举自己。
  • 哨兵选举局部领头的原则是先到先得，后来的拒绝。
  • 如果一个哨兵获得的选票大于半数，则成为领头。

故障转移

分为三个步骤：

  • 在已下线master属下的所有slave里面选出一个状态良好，数据完整的slave，并将其转为新master。
  • 让老master属下的所有slave改为复制新的master。
  • 将老master降级为slave,成为新master的从服务器。

新master的选择

将已下线主服务器的所有从服务器保存在一个列表中。

  • 删除列表中所有下线或者处于断线状态的从服务器。
  • 删除列表中所有最近5秒内没有回复过领头哨兵的从服务器。
  • 删除所有与已下线主服务器连接断开时间超过设置时间的从服务器，确保剩余服务器数据比较新。
  • 获取最高优先级中的复制偏移量最大的从服务器。
  • 如果还没有选出来，则按照ID排序，获取运行ID最小的从服务器。

tencent.jpg