文章目录加载中

Redis集群:哨兵

# 什么是哨兵?

Redis 2.8 中提供了哨兵工具来实现自动化的系统监控和故障恢复功能,进一步提高可用性。

它的功能包括以下两个。

  • 监控主数据库和从数据库是否正常运行。
  • 主数据库出现故障时自动将从数据库转换为主数据库。

如下图(哨兵相互也可以监控):

# 哨兵原理

这里的原理是 redis 制定的一些关于哨兵在各个场景下的处理流程和通信协议,包括:

  • 针对主/从数据库的监控
  • 针对其他哨兵节点的发现和监控
  • 选取领头哨兵节点
  • 故障恢复

# 监控主/从数据库

和主数据库的连接建立完成后,哨兵会定时执行下面 3 个操作:

  1. 每 10 秒哨兵会向主数据库和从数据库发送 INFO 命令。
  2. 每 2 秒哨兵会向主数据库和从数据库的__sentinel__:hello 频道发送自己的信息。
  3. 每 1 秒哨兵会向主数据库、从数据库和其他哨兵节点发送 PING 命令。

# 发现和监控哨兵

前面提到,哨兵会订阅每个其监控的数据库的__sentinel__:hello频道,所以当其他哨兵收到消息后,会判断发消息的哨兵是不是新发现的哨兵。如果是则将其加入已发现的哨兵列表中并创建一个到其的连接

发现哨兵之后,哨兵需要定时监控数据库和哨兵节点没有停止服务。这是通过每隔一定时间向这些节点发送 PING 命令实现的。

# 选取领头哨兵

如果当前哨兵节点发现了主数据库客观下线,需要故障恢复,但是故障恢复需要由领头的哨兵来完成,这样可以保证同一时间只有一个哨兵节点来执行故障恢复。选举领头哨兵的过程使用了 Raft 算法

当哨兵节点(节点 A)发现主数据库客观下线,准备竞选领头哨兵时候,向每个哨兵节点发送命令,要求对方选自己成为领头哨兵。会出现以下几种情况:

  • 收到命令的目标哨兵节点没有选过其他人,则会同意将 A 设置成领头哨兵。
  • 如果 A 发现有超过半数且超过 quorum 参数值的哨兵节点同意选自己成为领头哨兵,则 A 成功成为领头哨兵。
  • 当有多个哨兵节点同时参选领头哨兵,则会出现没有任何节点当选的可能。此时每个参选节点将等待一个随机时间重新发起参选请求,进行下一轮选举,直到选举成功。

Raft 算法核心就是:必须有超过半数的哨兵节点支持。所以每次选举最多只会选出一个领头哨兵。

# 故障恢复

当选取领头哨兵之后,会对主数据库进行故障恢复。

首先领头哨兵将从停止服务的主数据库的从数据库中挑选一个来充当新的主数据库。挑选的依据如下:

  1. 所有在线的从数据库中,选择优先级最高的从数据库。优先级可以通过 slave-priority 选项来设置。
  2. 如果有多个最高优先级的从数据库,则复制的命令偏移量越大(即复制越完整)越优先。
  3. 如果以上条件都一样,则选择运行 ID 较小的从数据库。

选出一个从数据库后,领头哨兵将向从数据库发送 SLAVEOF NO ONE 命令使其升格为主数据库。而后领头哨兵向其他从数据库发送 SLAVEOF 命令来使其成为新主数据库的从数据库。

本文来自心谭博客:xin-tan.com,经常更新web和算法的文章笔记,前往github查看目录归纳:github.com/dongyuanxin/blog