Redis学习三：Redis高可用之哨兵模式

申明

本文章首发自本人公众号：壹枝花算不算浪漫，如若转载请标明来源!

感兴趣的小伙伴可关注个人公众号：壹枝花算不算浪漫

22.jpg

前言

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

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

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

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

哨兵模式

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

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

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

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

哨兵配置

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.png

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

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

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

image.png

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

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

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

这里再说两个概念：

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

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

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

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

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

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

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

03_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 示例文件。

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

减少异步复制的数据丢失
有了min-slaves-max-lag这个配置，就可以确保说，一旦slave复制数据和ack延时太长，就认为可能master宕机后损失的数据太多了，那么就拒绝写请求，这样可以把master宕机时由于部分数据未同步到slave导致的数据丢失降低的可控范围内
减少脑裂的数据丢失
如果一个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 终止这次故障迁移操作。

参考自：
http://redisdoc.com/topic/sentinel.html?highlight=master%20down%20after%20milliseconds