Redis 的 Sentinel 系统用于管理多个 Redis 服务器（instance）， 该系统执行以下三个任务：

  • 监控（Monitoring）： Sentinel 会不断地检查你的主服务器和从服务器是否运作正常。
  • 提醒（Notification）： 当被监控的某个 Redis 服务器出现问题时， Sentinel 可以通过 API 向管理员或者其他应用程序发送通知。
  • 自动故障迁移（Automatic failover）： 当一个主服务器不能正常工作时， Sentinel 会开始一次自动故障迁移操作， 它会将失效主服务器的其中一个从服务器升级为新的主服务器， 并让失效主服务器的其他从服务器改为复制新的主服务器； 当客户端试图连接失效的主服务器时， 集群也会向客户端返回新主服务器的地址， 使得集群可以使用新主服务器代替失效服务器。

Redis Sentinel 是一个分布式系统， 你可以在一个架构中运行多个 Sentinel 进程（progress）， 这些进程使用流言协议（gossip protocols)来接收关于主服务器是否下线的信息， 并使用投票协议（agreement protocols）来决定是否执行自动故障迁移， 以及选择哪个从服务器作为新的主服务器。

什么是高可用？

架构上，我们讲高可用，一般说系统99%、99.9%、99.99% 等更多情形

例如一年365天 * 99.99% = 365.9天是可以对外提供服务的，换算下来是可以宕机
3153.6s，换成52.56min，0.876h

一般系统不可用可以分为以下几种情况：

  1. 机器宕机了
  2. JVM进程OOM了
  3. 机器cpu 100%
  4. 磁盘满了，系统各种IO报错
  5. 其他

例如Redis，我们使用主从架构，是单个master多个slave的，如果master宕机了该如何处理？此时Redis就无法写入了，如果我们使用哨兵模式，是会自动将某个slave提升为master的，继续对外提供服务。

哨兵模式

sentinal：哨兵，它是redis集群中非常重要的一个组件，主要功能如下：

  1. 集群监控，负责监控redis master和slave进程是否正常工作
  2. 消息通知，如果某个redis实例有故障，那么哨兵负责发送消息作为报警通知给管理员
  3. 故障转移：如果master node挂掉了，会自动转移给slave node上
  4. 配置中心，如果故障转移发生了，通知client客户端新的master地址

哨兵本身也是分布式的，作为一个哨兵集群去运行，互相协同工作

  1. 故障转移时，判断一个master node是宕机了，需要大部分哨兵都同意才行，涉及了分布式选举问题
  2. 即使部分哨兵节点挂掉了，哨兵集群还是能正常工作的

哨兵配置

Redis 源码中包含了一个名为 sentinel.conf 的文件， 这个文件是一个带有详细注释的 Sentinel 配置文件示例。
运行一个 Sentinel 所需的最少配置如下所示：

sentinel monitor mymaster 127.0.0.1 6379 2
sentinel down-after-milliseconds mymaster 60000
sentinel failover-timeout mymaster 180000
sentinel parallel-syncs mymaster 1

192.168.1.3 6380 4
sentinel down-after-milliseconds resque 10000
sentinel failover-timeout resque 180000
sentinel parallel-syncs resque 5

第一行配置指示 Sentinel 去监视一个名为 mymaster 的主服务器， 这个主服务器的 IP 地址为 127.0.0.1 ， 端口号为 6379 ， 而将这个主服务器判断为失效至少需要 2(quorum) 个 Sentinel 同意 （只要同意 Sentinel 的数量不达标，自动故障迁移就不会执行）。

不过要注意， 无论你设置要多少个 Sentinel 同意才能判断一个服务器失效， 一个 Sentinel 都需要获得系统中多数（majority） Sentinel 的支持， 才能发起一次自动故障迁移， 并预留一个给定的配置纪元 （configuration Epoch ，一个配置纪元就是一个新主服务器配置的版本号）。

换句话说， 在只有少数（minority） Sentinel 进程正常运作的情况下， Sentinel 是不能执行自动故障迁移的。

哨兵模式运行机制

image.pngimage.png

这个是经典的3节点哨兵集群，我们配置quorum = 2，3个节点的majority也是2，如果M1所在的机器宕机了，那么三个哨兵还剩下2个，S2和S3可以一致认为mater宕机，然后选举一个来执行故障转移

同时majority也是2，这个2个哨兵可以允许执行故障转移的。

这里再说下，如果是两节点哨兵，类似：

image.pngimage.png

配置的quorum = 1，master宕机，s1和s2中只要有一个哨兵认为master宕机就可以进行切换，同时s1和s2中选举一个哨兵来执行故障转移

但是此时majority=2，至少有2个或者的哨兵才能够允许执行故障转移，此时只有R1，故障是不会允许转移的

允许故障转移的条件时：或者的sentinal节点数>=majority

这里再说两个概念：

  1. quorum：sentinal集群中会配置该参数，例如5台机器，配置的quorum为3，那么如果有3个节点认为master宕机了，sentinal集群就会认为master宕机了，每个节点认为宕机被称为主观宕机sdown，sentinal集群认为master宕机被称为客观宕机odown
  2. majority 代表大多数的意思，例如2的majority=2，3的majority=2，4的majority=2，5的majority=3

哨兵模式下主备切换数据丢失问题

主备切换过程中，有两种情形会导致数据丢失：

  1. 异步复制导致的数据丢失
    master->slave的复制时异步的，所以可能有部分数据还没有复制到slave时，master宕机了，此时这部分数据就丢失了

  2. 脑裂导致的数据丢失
    脑裂就是说某个master所在的机器脱离了正常网络，跟其他slave机器不能连接，但是实际上master还运行着，此时哨兵可能就会认为master宕机了，然后开启选举，将其他slave切换成了master。

    这个时候集群中就会有两个master，也就是所谓的脑裂

    此时虽然某个slave被切换成了master，但是可能client还没来得及切换到新的master，还继续向旧的master写数据，这部分数据可能会丢失

    因此旧的master再次恢复的时候，会被作为一个slave挂到新的master上去，自己的数据会被清空，重新从新的master复制数据

03_Redis哨兵模式下脑裂问题.jpg03_Redis哨兵模式下脑裂问题.jpg

哨兵模式数据丢失问题解决方案

从 Redis 2.8 开始， 为了保证数据的安全性， 可以通过配置， 让主服务器只在有至少 N 个当前已连接从服务器的情况下， 才执行写命令。

不过， 因为 Redis 使用异步复制， 所以主服务器发送的写数据并不一定会被从服务器接收到， 因此， 数据丢失的可能性仍然是存在的。

以下是这个特性的运作原理：

  • 从服务器以每秒一次的频率 PING 主服务器一次， 并报告复制流的处理情况。

  • 主服务器会记录各个从服务器最后一次向它发送 PING 的时间。

  • 用户可以通过配置， 指定网络延迟的最大值 min-slaves-max-lag ， 以及执行写操作所需的至少从服务器数量 min-slaves-to-write。

如果至少有 min-slaves-to-write 个从服务器， 并且这些服务器的延迟值都少于 min-slaves-max-lag 秒， 那么主服务器就会执行客户端请求的写操作。

你可以将这个特性看作 CAP 理论中的 C 的条件放宽版本： 尽管不能保证写操作的持久性， 但起码丢失数据的窗口会被严格限制在指定的秒数中。

另一方面， 如果条件达不到 min-slaves-to-write 和 min-slaves-max-lag 所指定的条件， 那么写操作就不会被执行， 主服务器会向请求执行写操作的客户端返回一个错误。

以下是这个特性的两个选项和它们所需的参数：

-min-slaves-to-write <number of slaves>

  • min-slaves-max-lag

详细的信息可以参考 Redis 源码中附带的 redis.conf 示例文件。

上面两个配置可以减少异步复制和脑裂导致的数据丢失

  1. 减少异步复制的数据丢失
    有了min-slaves-max-lag这个配置，就可以确保说，一旦slave复制数据和ack延时太长，就认为可能master宕机后损失的数据太多了，那么就拒绝写请求，这样可以把master宕机时由于部分数据未同步到slave导致的数据丢失降低的可控范围内

  2. 减少脑裂的数据丢失
    如果一个master出现了脑裂，跟其他slave丢了连接，那么上面两个配置可以确保说，如果不能继续给指定数量的slave发送数据，而且slave超过10秒没有给自己ack消息，那么就直接拒绝客户端的写请求

这样脑裂后的旧master就不会接受client的新数据，也就避免了数据丢失

上面的配置就确保了，如果跟任何一个slave丢了连接，在10秒后发现没有slave给自己ack，那么就拒绝新的写请求

因此在脑裂场景下，最多就丢失10秒的数据。

哨兵模式其他一些机制原理分析

sdown和odown转换机制

sdown(subjectively down)和odown(objectively down)是年终失败状态：

  • sdown是主观宕机，一个哨兵如果觉得master宕机了，那么就是主观宕机
  • odown是客观宕机，如果quorun数量的哨兵都觉得一个master宕机了，那么就是客观宕机

sdown达成的条件很简单，如果一个哨兵ping一个master，超过了is-master-down-after-milliseconds指定的毫秒数之后，就主观认为master宕机了

例如我们可以配置：

sentinel monitor mymaster 127.0.0.1 6379 2
sentinel down-after-milliseconds mymaster 5000
sentinel failover-timeout mymaster 180000
sentinel parallel-syncs mymaster 1

这里就代表如果ping master超过了5s钟就认为master sdown

哨兵集群的自动发现机制

一个 Sentinel 可以与其他多个 Sentinel 进行连接， 各个 Sentinel 之间可以互相检查对方的可用性， 并进行信息交换。

你无须为运行的每个 Sentinel 分别设置其他 Sentinel 的地址， 因为 Sentinel 可以通过发布与订阅功能来自动发现正在监视相同主服务器的其他 Sentinel ， 这一功能是通过向频道__sentinel__:hello 发送信息来实现的。

与此类似， 你也不必手动列出主服务器属下的所有从服务器， 因为 Sentinel 可以通过询问主服务器来获得所有从服务器的信息。

  • 每个 Sentinel 会以每两秒一次的频率， 通过发布与订阅功能， 向被它监视的所有主服务器和从服务器的__sentinel__:hello频道发送一条信息， 信息中包含了 Sentinel 的 IP 地址、端口号和运行 ID （runid）。

  • 每个 Sentinel 都订阅了被它监视的所有主服务器和从服务器的 __sentinel__:hello 频道， 查找之前未出现过的 sentinel （looking for unknown sentinels）。 当一个 Sentinel 发现一个新的 Sentinel 时， 它会将新的 Sentinel 添加到一个列表中， 这个列表保存了 Sentinel 已知的， 监视同一个主服务器的所有其他 Sentinel 。

  • Sentinel 发送的信息中还包括完整的主服务器当前配置（configuration）。 如果一个 Sentinel 包含的主服务器配置比另一个 Sentinel 发送的配置要旧， 那么这个 Sentinel 会立即升级到新配置上。

  • 在将一个新 Sentinel 添加到监视主服务器的列表上面之前， Sentinel 会先检查列表中是否已经包含了和要添加的 Sentinel 拥有相同运行 ID 或者相同地址（包括 IP 地址和端口号）的 Sentinel ， 如果是的话， Sentinel 会先移除列表中已有的那些拥有相同运行 ID 或者相同地址的 Sentinel ， 然后再添加新 Sentinel 。

slave配置的自动纠正

哨兵会负责自动纠正slave的一些配置，比如slave如果要成为潜在的master候选人，哨兵会确保slave在复制现有master的数据; 如果slave连接到了一个错误的master上，比如故障转移之后，那么哨兵会确保它们连接到正确的master上

slave->master选举算法

如果一个master被认为odown了，而且majority哨兵都允许了主备切换，那么某个哨兵就会执行主备切换操作，此时首先要选举一个slave来

会考虑slave的一些信息：

  • 跟master断开连接的时长
  • slave优先级
  • 复制offset
  • run id

如果一个slave跟master断开连接已经超过了down-after-milliseconds的10倍，外加master宕机的时长，那么slave就被认为不适合选举为master

own-after-milliseconds * 10) + milliseconds_since_master_is_in_SDOWN_state

接下来会对slave进行排序：

  • slave优先级进行排序，slave priority越低，优先级就越高
  • 如果slave priority相同，那么看replica offset，哪个slave复制了越多的数据，offset越靠后，优先级就越高
  • 如果上面两个条件都相同，那么选择一个run id比较小的那个slave

quorum和majority

每次一个哨兵要做主备切换，首先需要quorum数量的哨兵认为odown，然后选举出一个哨兵来做切换，这个哨兵还得得到majority哨兵的授权，才能正式执行切换

如果quorum < majority，比如5个哨兵，majority就是3，quorum设置为2，那么就3个哨兵授权就可以执行切换

但是如果quorum >= majority，那么必须quorum数量的哨兵都授权，比如5个哨兵，quorum是5，那么必须5个哨兵都同意授权，才能执行切换

configuration epoch

哨兵会对一套redis master+slave进行监控，有相应的监控的配置

执行切换的那个哨兵，会从要切换到的新master（salve->master）那里得到一个configuration epoch，这就是一个version号，每次切换的version号都必须是唯一的

如果第一个选举出的哨兵切换失败了，那么其他哨兵，会等待failover-timeout时间，然后接替继续执行切换，此时会重新获取一个新的configuration epoch，作为新的version号

configuraiton传播

哨兵完成切换之后，会在自己本地更新生成最新的master配置，然后同步给其他的哨兵，就是通过之前说的pub/sub消息机制

这里之前的version号就很重要了，因为各种消息都是通过一个channel去发布和监听的，所以一个哨兵完成一次新的切换之后，新的master配置是跟着新的version号的

其他的哨兵都是根据版本号的大小来更新自己的master配置的

故障转移

一次故障转移操作由以下步骤组成：

  • 发现主服务器已经进入客观下线状态。
  • 对我们的当前纪元进行自增（详情请参考 Raft leader election ）， 并尝试在这个纪元中当选。
  • 如果当选失败， 那么在设定的故障迁移超时时间的两倍之后， 重新尝试当选。 如果当选成功， 那么执行以下步骤。
  • 选出一个从服务器，并将它升级为主服务器。
  • 向被选中的从服务器发送 LAVEOF NO ONE命令，让它转变为主服务器。
  • 通过发布与订阅功能， 将更新后的配置传播给所有其他 Sentinel ， 其他 Sentinel 对它们自己的配置进行更新。
  • 向已下线主服务器的从服务器发送SLAVEOF host port命令， 让它们去复制新的主服务器。
  • 当所有从服务器都已经开始复制新的主服务器时， 领头 Sentinel 终止这次故障迁移操作。

本文为转载