Redis: Sentinel工作原理和故障迁移流程

Sentinel 哨兵几个核心概念

1 ) 定时任务

• Sentinel 它是如何工作的，是如何感知到其他的 Sentinel 节点以及 Master/Slave节点的
• 就是通过它的一系列定时任务来做到的，它内部有三个定时任务
  • 第一个就是每一秒每个 Sentinel 对其他 Sentinel 和 Redis 节点执行 PING 操作(监控)
    • 这是一个心跳检测是失败判定的一个依据
    • 我给你一个 PING, 你必须在有效时间内给我一个 PONG, 否则我认为你出问题了
  • 第二个就是每2秒每个 Sentinel 通过 Master 节点的 channel 交换信息 (Publish/Subscribe)
    • Redis 它实际上也有发布订阅的这种模式
    • Master主节点会开启这个功能, 通过信道拿到我们节点的交换信息
  • 第三个定时任务就是每 10 秒每个 Sentinel 会对 Master 和 Slave 执行 INFO 命令
    • info命令，下边有CPU的使用率，内存使用情况
    • 包括它服务节点的信息，主从信息集群信息等等
    • info replication 只是 info 下面的一个子集
    • 所以说 info 命令是可以拿到一个完整的REDIS当前环境及节点的一个状态信息的
    • 主要的目的就是要确认主从关系，然后就是及时的发现可用的 Slave 节点
    • 比如现在并发很高，一主两从已经支撑不了了，再添加一个从节点又可以分散一部分流量
    • 并发上来了，我们只需要不停的添加从节点就可以了
    • 我添加了从节点 Sentinel 也要感知到这个从节点
    • 相当于把它添加的这个监控环境里边，它通过 info 命令来完成

2 ）主观下线 (Subjectively Down, 简称 SDOWN)

• Sentinel 的作用就是监控主从环境，发生故障的时候，能及时的做故障转移
• 重新选取主节点顶上来继续提供服务，这个时候就会有一个问题，怎么识别你就故障了
• 现在有3个 Sentinel，难道说其中一个认为它故障了就要发起故障转移重新选举吗？
• 当然不是，它是有一个过程的，先经过主观下线，再到客观下线，客观下线是依据仲裁的参数，满足之后才会标记为客观下线
• 主观下线，指的是单个 Sentinel 实例对服务器做出的下线判断，即单个 Sentinel 认为某个服务下线，有可能是接收不到订阅，之间的网络不通等等原因
• 就是说我现在认为你连不上了，我把你标记为主观下线，这个连不上是怎么认定的？
  • 其实就是刚才我们说的那个定时任务，我现在给你 PING, 你给我返回 PONG
  • 之前，我们配置了一个 down-after-milliseconds
  • 如果在这个时间内，你都没有做有效的返回, 我就认为你故障了
  • 我就会把你标记为主观下线
• 当我把你标记为主观下限之后，我会去找其他的 Sentinel 来确认你是是不是主观下线
• 也就是说一个 Sentinel 把一个主节点标记为主观下限了
• 它就会让环境里边其他的 Sentinel 去对它做出判断，确认它是不是真下线
• 其他的 Sentinel 就开始去跟这个 Master 主节点进行通行，仍然基于 PING, PONG 的机制来检测
• 当超过其一半数量都认定下线，则满足仲裁的条件，这样就会被标记为客观下线

3 ) 客观下线 (Objectively Down, 简称 ODOWN)

• 客观下线，是指多个 Sentinel 实例在对同一个服务器做出 SDOWN 判断，互相交流之后，得出的服务器下线判断，然后开启 failover，就是故障迁移

4 ) 仲裁

• 这个仲裁其实非常简单，就是少数服从多数，只要有一半以上都认为Master下线了，则就认定其下线
• 当配置文件中的 quorum 选项的值一般设定为 q = s / 2 + 1，s 是服务器总数的意思
• 只要有一半以上认定主观下线，则就是客观下线，仲裁成功，开启 failover 进行故障迁移

Sentinel 哨兵工作原理

1 ）每秒 PING

• 每个 Sentinel 以每秒一次的频率会向它所知的 Master / Slave 以及其他的 Sentinel 节点
• 发送一个 PING 命令来判断它是不是可通性的, 还有没有存活

2 ) 有效回复 PING 命令的时间超过配置文件 down-after-milliseconds 选项所指定的值会被定为主观下线

• 当我 PING 过去，你回复 PONG 的时间是超过的这个时间
• 或者说在这个有效时间内没有返回，或者说你给我返回的错误
• 我都认为你是主观下线了

3 ）确认主观下线状态

• 主观下线之后，正在监视这个 Master 的其他 Sentinel
• 就会每秒一次的去确认这个 Master 是不是真的进入主观下线了

4 ) 满足条件，客观下线

• 如果足够数量的 Sentinel，在指定的时间范围内确认了 Master确实是进入了主观下线
• 它会标记为客观下线，被标记为客观下线之后，就会进入投票环节

5 ）投票选举主节点，从节点复制数据

• 这个时候 Master 处于 ODOWN 客观下限状态,就会投票自动选取新的主节点
• 这个地方选举的时候，它还会去做一些过滤，有一个相关的配置是决定
• 从节点晋升为主节点的优先级，那个配置项，如果你把它改为零，这个从节点永远不会变为主节点
• 如果你把它调的很大，它被选为主节点的几率就很大，优先级就很高
• 它就先去看那个配置项，谁的优先级高，先选谁，优先级相同
• 继续看下一个判定，下一个判定是 偏移量，哪个偏移量最大则选举哪一个为主节点
• 如果偏移量相同，再去看 run_id 小的会被晋升为主节点
• 这里边还会有一系列的操作，把它选定主节点之后
• 其他的从节点会指向这个新的主节点继续进行数据的复制同步

6 ）主节点被标为客观下线时， INFO 的命令触发由10s一次改为1s一次

• 原来我们的环境复稳定的，我十秒执行一次 info 目的很简单
• 就是看看有没有新加进来的从节点或者 Sentinel，要把新成员添加到我的监控环境里边
• 而现在都已经故障了, 发起了故障转移，重新选举了
• 我需要在最短的时间内把环境稳定下来最好，所以有这个时间的调整
• 我要快速的把可用的从节点全部都给它收集过来，把这个主从的关系确认下来稳定下来

7 ）冲裁失败后的状态恢复

• 若没有足够数量的 Sentinel 同意 Master进行下线，客观下线的状态会被移除
• 如果 Master 重新向 Sentinel 的PING命令返回有效回复，Master的主观下限也会被移除

故障转移演示

• 首先，启动好3台Redis 和 3个 Sentinel
• 在主节点Master机器上执行 $ SHUTDOWN 命令关机
• 这时候就会触发Sentinel的仲裁和投票，可以通过查看各个服务器 sentinel.log 日志来看到整个过程
• 同时，因为主从被修改了，相关机器上的配置文件也会被同步修改为服务当前主从关系的配置
• 要注意，被修改过的配置文件中，会有ACL安全策略，这个是Redis@6之后的新特性
• 这个是权限管理相关功能，为了安全来设置的，为不同用户授予不同的数据和操作权限
• 这个可以自行进行操作来对日志，配置文件的分析

图解自动故障迁移流程

• 现在的环境是主从的环境，一主两从，然后配了3个 Sentinel 哨兵
• 经过一次故障迁移之后，102 变成主节点，101 和 103 变成从节点
• Sentinel哨兵，它内部会有一些定时任务，这个定时任务分为三种
  • 第一种就是每一秒对我们的主从和其他的 Sentinel，发送 PING 命令
    • 这个心跳检测是失败判定的依据
    • 如果对方没有办法在有效的时间内给我返回，我就认为对方出问题了
  • 第二种就是每两秒，每个 Sentinel 会通过 Master Channel 来交换信息
    • 就发布订阅的那个channel信道交换信息
  • 第三种就是每十秒会对 Master/Slave 执行 info 命令
    • 来确认主从关系和及时发现可用的slave节点
• 一开始，Sentinel 现在监控主节点是由之前在 Sentinel 的配置文件里边的配置
  • 如：sentinel monitor mymaster 192.168.10.102 6379 2
  • 这些什么意思，大家都应该知道
• 接着往下看，PING 的时候超时，或者返回错误，是哪个配置来决定的呢？

  • 是下面这个 down-after-milliseconds

    # Sentinel认为服务器已经断线所需的毫秒数 默认值是30秒 这里改成10秒 PING PONG 中 返回 PONG 的时间
    sentinel down-after-milliseconds mymaster 10000

  • 就是我这个命令令出去之后，你在这个有效时间内返回才是OK的

  • 超出这个时间，我认为你出问题了，要么故障了，要么宕机异常错误了

  • 反正总而言之，我认为你现在不可用了

  • 这里配的是十秒，它是一万毫秒

  • 如果大于十秒，我都没有接收到这个PONG, 没有拿到一个有效的反馈，我认为你出问题了

• 这个时候只是单个的 Sentinel 认为它出问题了，会把它标记为主观下线
  • 一个Sentinel把它标为主观下线之后，其他的 Sentinel 就要去确定目标是否真的下线
  • 满足 quorum 仲裁值之后，它会被标记为客观下线，之后，目标节点就要开始执行故障迁移
  • 在日志中可以明确看出这个流程，它会发起一个新的选举主节点的流程
• 但是故障迁移选举主节点这一系列的工作，不是说这三个 Sentinel 都去做
• 只需要有其中一个来做成这个事情就行了，它是通过 raft 算法来选取一个leader领导者
  • 就是选一个领导者去做故障迁移这件事儿
  • 于是，他们就开始投票，raft算法可以保证在同一时间只会生成一个领导者
  • 也就是说故障迁移，只会在当前环境下存在一个节点去做这件事情
  • 就保证了我们的一致性，不会出乱子
• 选举出来之后，有一个人他就会去执行故障迁移，执行的过程中
  • 它会先从环境里边找到满足条件的slave
  • 首先看优先级配置，优先级高的会选为主节点
  • 如果出现了多个优先级相同的，再看偏移量
  • 偏移量大的被选为主节点，偏移量相同的，再往下比 run_id 比较小的
  • 最终找到一个合适的slave，然后就要等其他的slave确认完
  • 我们会给他执行一系列的操作
    • 如说 slaveof no one，就是关闭它的复制
    • 修改环境下其他节点的配置，建立新的主存关系
    • 之后，其它的从节点点会把自己的数据都丢掉，然后重新复制它
    • 这个时候，就SYNC发起全量复制新的主节点里边的数据
    • 然后 Sentinel节点 集合在这里做一个更新，又恢复到正常工作，开始监控新的master
• 后续如果再出现了故障迁移，又是这样的一个流程
  • 就是主观，客观，然后再选举leader
  • 然后再找到合适的 slave 把它改成master
  • 然后确认，然后再去全量复制等等
• 这就是自动故障迁移的一个流程，关键几点如下

  • 配置文件里 Sentinel monitor 监控的是谁

  • down-after-milliseconds 决定定这个PING和PONG超时的一个时间间隔

  • quorum 就是 仲裁的那个值

  • 还有 fallover-timeout，整个的迁移流程会有个有效时间

    sentinel failover-timeout mymaster 180000

  • 在这个有效时间内，迁移还没有完成，直接就把这个工作/进程就终止了

  • 就会重新发起一次迁移，防止卡住和阻塞

  • 这个配置默认是18万毫秒，180秒, 三分钟