Redis简介三（哨兵sentinel,故障转移）

在上一章节，我们已经简单的聊过了哨兵以及它的功能，这一章我们详细介绍它的运行机制

启动哨兵

跟上一章一样，演示一个小demo，现在是在床上换了个笔记本，屏幕比较小，图片看不清楚的自己放大。

1. 首先我们启动两个Redis实例6379和6380，同时将6379设置为master，6380设置为slave，具体代码以及实例就不再重复演示了，不懂的去看上一章节。
2. 我们需要给master设置三个哨兵，在docker中，我们需要进入master容器的内部来启动哨兵：

docker exec -ti master /bin/bash  // 用于进入master容器内部
cd /        			// 进入当前容器的根目录
touch sentinel1.conf    //创建第一个哨兵的启动配置文件
touch sentinel2.conf    //创建第二个哨兵的启动配置文件
touch sentinel3.conf    //创建第三个哨兵的启动配置文件

ok，我们现在已经成功的在容器内部创建出了3个哨兵的配置文件了
下面我们对配置文件进行配置，主要有两项，一个是哨兵的端口号，一个是设置需要监控哪一个Redis实例。以其中一个文件为例，另外两个配置，只需要将端口号改掉即可：

vim sentinel1.conf    // 用vim打开当前的配置文件

port 26379       //将哨兵端口号设置为26379
sentinel monitor master 172.17.0.02  6379 2  
//设置需要监控的实例别名，对应的ip是172.0.0.2 ，端口号是6379，而将这个主服务器判断为失效至少需要 2 个 Sentinel 同意    

将三个配置文件按照如上配置，依次保存。
ps：我本地的docker是没有vim的需要先进行安装

apt-get update
apt-get install vim -y

3. 启动哨兵

redis--sentinel  /sentinel1.conf     // 启动哨兵1
redis--sentinel  /sentinel2.conf     // 启动哨兵2
redis--sentinel  /sentinel3.conf     // 启动哨兵3

至此，我们就将一个master，一个slave，三个哨兵的环境建立起来了：

自动发现 Sentinel 和从服务器

从上面的启动界面，我们就可以看到，当哨兵服务启动之后，就已经检测到了master（172.17.0.2）以及slave（172.17.0.3）。

结合上一章节，我们可以知道，哨兵在发起灾备救援之前，是需要进行投票的，也就是说，每个哨兵之间是需要进行通信的，可我们从启动的过程可以看到，我们并没有设置任何哨兵之间通信的信息。

其实哨兵之间的通信，是基于Redis的发布订阅功能实现的：

psubscribe *     // 查看当前Redis中所有的订阅消息

通过查看消息，我们可以看到有一个叫”hello“的频道通信非常频繁，是的，你没有猜错，所有启动了的哨兵，都会订阅这个消息频道，具体如下：

• 每个 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 。

定期任务

• 每个 Sentinel 以每秒钟一次的频率向它所知的master、slave以及其他 Sentinel 实例发送一个 PING 命令。
• 如果一个实例距离最后一次有效回复 PING 命令的时间超过 预设值， 那么这个实例会被 Sentinel 标记为主观下线。
• 如果一个主服务器被标记为主观下线， 那么正在监视这个主服务器的所有 Sentinel 要以每秒一次的频率确认主服务器的确进入了主观下线状态。
• 如果一个主服务器被标记为主观下线， 并且有足够数量的 Sentinel （至少要达到配置文件指定的数量）在指定的时间范围内同意这一判断， 那么这个主服务器被标记为客观下线。
• 一般情况下， 每个 Sentinel 会以每 10 秒一次的频率向它已知的所有主服务器和从服务器发送 INFO 命令。 当一个主服务器被 Sentinel 标记为客观下线时， Sentinel 向下线主服务器的所有从服务器发送 INFO 命令的频率会从 10 秒一次改为每秒一次。
• 当没有足够数量的 Sentinel 同意主服务器已经下线， 主服务器的客观下线状态就会被移除。 当主服务器重新向 Sentinel 的 PING 命令返回有效回复时， 主服务器的主观下线状态就会被移除。

名词解释

• 主观下线：
  单个 Sentinel 实例对服务器做出的下线判断。
• 客观下线：
  多个 Sentinel 实例在对同一个服务器做出 SDOWN 判断

故障转移

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

Sentinel leader 选举新的主服务器：

• 在失效主服务器属下的从服务器当中， 那些被标记为主观下线、已断线、或者最后一次回复 PING 命令的时间大于五秒钟的从服务器都会被淘汰。
• 在失效主服务器属下的从服务器当中， 那些与失效主服务器连接断开的时长超过 down-after 选项指定的时长十倍的从服务器都会被淘汰。
• 在经历了以上两轮淘汰之后剩下来的从服务器中， 我们选出复制偏移量（replication offset）最大的那个从服务器作为新的主服务器； 如果复制偏移量不可用， 或者从服务器的复制偏移量相同， 那么带有最小运行 ID 的那个从服务器成为新的主服务器。

Sentinel 使用 Raft 算法来选leader ， 确保在一个给定的纪元（epoch）里， 只有一个leader， 并且每个 Sentinel 在同一个纪元中只会对一个leader进行投票。更高的配置纪元总是优于较低的纪元， 因此每个 Sentinel 都会主动使用更新的纪元来代替自己的配置。

参考文档

http://redis.cn/topics/sentinel.html