简述Redis_Sentinl(哨兵集群)的功能及原理

简述Redis_Sentinl(哨兵集群)的功能及原理

一. 关于Redis哨兵集群的几种基本功能

1.Redis_Sentinl具有监控功能(Monitoring):

​ 哨兵(sentinel)会不断地检查Master和Slave是否运作正常.

2.Redis_Sentinl具有提醒功能(Notification):

​ 当被检控的某个Redis出现问题时,哨兵(sentinel)可以通过API向管理员或其他应用程序发送通知.

3.Redis_Sentinl具有自动故障迁移功能:

​ 当一个Master不能正常工作时,哨兵(sentinel)会开始一次自动故障迁移操作,它会将失效Master的其中一个Slave升级为新的Master.这是我们称之为容灾机制的一个重要的功能点.

二.关于Redis的容灾机制的阐述

​ 当某个master服务下线时,所有的slave将无法同步数据,这对于redis集群来说是灾难性的,此时哨兵自动将该master下的某个slave服务升级为master服务,用来代替已经下线的那个master服务继续处理请求,此时,灾难的局面就被扭转了回来,这就是redis的容灾机制(也是Redis_Sentinl的使用背景).

三.Sentinel原理

SDOWN和ODOWN

在介绍sentinel原理之前，需要了解的两个概念SDOWN和ODOWN：

• SDOWN：全拼Subjectively Down，称为主观下线，指的是单个sentinel对redis实例作出的下线状态判断。
• ODOWN：全拼Objectively Down，称为客户端下线，指多个 Sentinel 实例在对同一个redis做出 SDOWN 判断，并且通过 SENTINEL is-master-down-by-addr 命令互相交流之后，得出的redis实例下线判断。（一个 Sentinel 可以通过向另一个 Sentinel 发送 SENTINEL is-master-down-by-addr 命令来询问对方是否认为给定的redis实例已下线。）

从sentinel的角度来看，如果发送了PING心跳后，在一定时间内没有收到合法的回复，就达到了SDOWN的条件。这个时间在配置中通过master-down-after-milliseconds参数配置。

当sentinel发送PING后，以下回复之一都被认为是合法的：

PING replied with +PONG.
PING replied with -LOADING error.
PING replied with -MASTERDOWN error.

其它任何回复（或者根本没有回复）都是不合法的。

从SDOWN切换到ODOWN不需要任何一致性算法，只需要一个gossip协议：如果一个sentinel收到了足够多的sentinel发来消息告诉它某个master已经down掉了，SDOWN状态就会变成ODOWN状态。如果之后master可用了，这个状态就会相应地被清理掉。

真正进行failover需要一个授权的过程，这个授权的过程即是leader选取过程，但是所有的failover都开始于一个ODOWN状态。ODOWN状态只适用于master，对于不是master的redis节点sentinel之间不需要任何协商，slaves和sentinel不会有ODOWN状态。

实现原理

一个sentinel启动时会读取配置文件，并通过sentinel monitor 配置寻找要监控的主数据库，这个配置在之前已经进行详细说明，其中master-name是由一个大小写字母、数字、和“._-”组成的数据库主库名字，为了考虑到主库的IP地址和端口可能在故障切换后发生变化，所以还需要ip和port来标示这个主库。一个哨兵可监控多个主从系统从而形成网状结构，正如在前面简介的图示一样。

sentinel启动后，会与监控的数据库建立两条连接,如下图（主库10.1.210.69:6379与10.1.210.32的sentinel节点两条链接）：

这两个连接与普通客户端一样，其中一条连接用来订阅master的__sentinel__:hello频道用于获取其他监控该数据库的sentinel节点信息，另外一条用于哨兵定期向主数据库发送INFO等命令获取主库本身信息，原因在于当客户端进入订阅模式以后只能接受消息，不能发送命令，所以还需要建立一条连接。

与监控的主库建立连接完成后，sentinel定时执行以下操作：

1. 每10s会向主数据库和从数据库发送INFO命令；
2. 每1s向master、slave以及其他哨兵节点发送PING命令；
3. 每2s向master和slave的__sentiel__:hello频道发送自己的信息来宣布自己的存在，同时该过程也是实现哨兵之间自动发现的基础；

这三个操作贯穿了哨兵整个生命周期，非常重要，也是其原理的核心，所以以下将详细介绍该操作过程。

首先，sentinel启动后，向主库发送INFO命令使得sentinel可以获取当前主库的相关信息（包括运行的ID，复制信息、以及属于该主库的从库节点信息），这也是为什么在配置监控时候只需要配置监控的主库信息sentinel就自动找到其对应的从库，进而实现从库的监控。而后和每个从库同样建立两个连接，这两个连接和上文介绍的与主库的连个连接完全一致，在此之后，哨兵会每10s定时向已知所有主从发送INFO命令获取信息更新并进行相应操作，比如对新增的从库建立连接并加入监控队列、又或者是主库信息发生变化（由failover引起的）进行信息更新等。

接下来哨兵向master和slave的__sentinel__:hello频道发送信息与同样监控该redis示例的其他哨兵分享自己的信息。发送的消息内容为：

<哨兵地址> ,<哨兵端口>,<哨兵运行的ID>,<哨兵配置的版本>,<主库名称>,<主库地址>,<主库端口>,<主库配置版本>，该消息包含了哨兵基本信息以及监控的主库信息，当其他sentinel收到消息后会判断发消息的哨兵是不是新的哨兵，如果是则将其加入已发现的哨兵列表，并创建一个到其的连接（与数据库不同）哨兵与哨兵之间只会创建一条连接用于发送PING命令，同时sentinel会判断主数据库的配置版本，如果该版本比记录数据库版本高，则更新主数据库的数据，其作用在后续介绍。

实现了自动发现从数据库和其他sentinel节点后，sentinel后续要做的任务是定时监控这些已经发现的主从节点和sentinel节点是否在线。这种监控实现方式是在通过一定时间间隔发送PING命令实现，时间间隔配置通过down-after-milliseconds指定，当超过down-after-milliseconds配置的时间后，如果被PING的数据库或者sentinel未回复，则哨兵认为其主观下线（主观下线在上面已经介绍了），如果该节点是主库sentinel会进一步进行判断是否需要对其进行故障恢复(failover)：sentinel会发送SENTINEL is-master-down-by-addr命令询问其他sentinel节点是否也认为该主库主观下线，如果达到指定数量（在示例配置中也进行了说明，示例配置的是2）时，哨兵会认为其**客观下线，**并选取领头的哨兵（leader）进行故障恢复，选举过程后续介绍。

选举完零头哨兵后，领头哨兵会开始对主数据库进行故障恢复，这一过程称为failover，在选取新的master时候，sentinel会考虑以下情况：

• 跟master断开连接的时长
• slave的优先级 （由slave-priority配置指定）
• 复制偏移量offset
• 实例运行的id（run id）

具体的选取顺序如下：

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

(down-after-milliseconds * 10) + milliseconds_since_master_is_in_SDOWN_state

接下来会对slave进行排序

1. 按照slave优先级进行排序，slave-priority越低，优先级就越高；
2. 如果slave priority相同，那么比较复制偏移量，offset越靠后（越大）则表明和旧的主库数据同步越接近，优先级就越高 ；
3. 如果上面两个条件都相同，那么选择一个run id最小的从库；

选出从库后，零头哨兵将向从数据库发送SLAVEOF NO ONE命令升级其为新的主库，然后在向其他从库发送SLAVEOF命令将从的主库升级到最新的主库，最后更新内部记录将已经停止的主库更新为新的主库的从库，使得当该故障的主库再次恢复时候自动以从库角色继续提供服务，从启动到故障恢复完成这一些列过程即是哨兵的工作的完整流程也是其原理所在。

领头哨兵选举

在原理中提及到了，当sentinel发现主库客观下线时候会进行领头哨兵选举进行故障恢复，其选举算法采用Raft算法，这也为什么说其设计思想类似与zookpeer，选举过程大体如下：

1. 发现主库客观下线的哨兵节点（这里称为A）向每个哨兵节点发送命令要求对方选举自己为领头哨兵（leader）；
2. 如果目标哨兵没有选举过其他人，则同意将A选举为领头哨兵；
3. 如果A发现有超过半数且超过quorum参数值的哨兵节点同意选自己成为领头哨兵，则A哨兵成功选举为领头哨兵。
4. 当有多个哨兵节点同时参与领头哨兵选举时，出现没有任何节点当选可能，此时每个参选节点等待一个随机时间进行下一轮选举，直到选出领头哨兵。

配置版本号作用

同样，在原理介绍时候提及到了master的配置版本号，当一个sentinel被授权后，它将会获得宕掉的master的一份最新配置版本号，当failover执行结束以后，这个版本号将会被用于最新的配置。因为大多数sentinel都已经知道该版本号已经被要执行failover的sentinel拿走了，所以其他的sentinel都不能再去使用这个版本号。这意味着，每次failover都会附带有一个独一无二的版本号。我们将会看到这样做的重要性。

而且，sentinel集群都遵守一个规则：如果sentinel A推荐sentinel B去执行failover，A会等待一段时间后，自行再次去对同一个master执行failover，这个等待的时间是通过failover-timeout配置项去配置的。从这个规则可以看出，sentinel集群中的sentinel不会再同一时刻并发去failover同一个master，第一个进行failover的sentinel如果失败了，另外一个将会在一定时间内进行重新进行failover，以此类推。

sentinel保证了活跃性：如果大多数sentinel能够互相通信，最终将会有一个被授权去进行failover.
sentinel也保证了安全性：每个试图去failover同一个master的sentinel都会得到一个独一无二的版本号。

el保证了活跃性：如果大多数sentinel能够互相通信，最终将会有一个被授权去进行failover.
sentinel也保证了安全性：每个试图去failover同一个master的sentinel都会得到一个独一无二的版本号。