三分钟带你入门 redis 高可用架构之哨兵

什么是哨兵？

哨兵（Sentinel）是 redis 的高可用性解决方案，前面咱们讲的主从复制它是高可用的基础，须要人工介入才能完成故障转移，哨兵能够解决这个问题，在主从复制状况下，当主节点发生故障时，哨兵能够自动的发现故障而且完成故障转移，实现真正的 redis 高可用。在哨兵集群中，哨兵会监视全部的 redis 服务器和其余 sentinel 节点状态，来保证 redis 的高可用。

哨兵的搭建

哨兵本质也是一个 redis 服务，只是跟普通的 redis 服务提供了不同的功能。哨兵是一个分布式架构，由于你要保证 redis 高可用，首先须要保证本身高可用，因此若是咱们须要搭建哨兵的话，最少须要部署三个实例，最好是奇数个，由于在后续的故障转移中会涉及到投票。

哨兵的配置文件咱们能够在 redis 的 GitHub 项目下下载，在项目下有一个叫作 sentinel.conf 的文件，可使用它做为咱们哨兵的配置模板，固然你也可使用 redis.conf 配置文件，只须要添加哨兵相关配置就行了。

哨兵相关的配置项很少，主要有如下几个配置项：

// 端口号，默认是 redis 实例+20000，因此咱们沿用这个规则就行了
port 26379 
// 是否守护进程运行
daemonize yes 
// 日志存放的位置，这个很是重要，经过日志能够查看故障转移的过程
logfile "26379.log" 
// 监视一个名为 mymaster（自定义） 的 redis 主服务器， 这个主服务器的 IP 地址为 127.0.0.1 ， 端口号为 6379 ， 
// 最后面的 2 表明着至少有两个哨兵认为主服务器出现故障才会进行故障转移，不然认定主服务未失效
sentinel monitor mymaster 127.0.0.1 6379 2 
// 哨兵判断服务器失效的响应时间，超过这个时间未接收到服务器的回应，就认为该服务器失效了
sentinel down-after-milliseconds mymaster 30000 
// 完成故障转移以后，最多多少个从服务器能够同时发起数据复制，数字越小，说明完成所有从服务数据复制的时间越长
// 数字越大，对主服务器的压力就变大了
sentinel parallel-syncs mymaster 1 
// 故障转移超时时间
sentinel failover-timeout mymaster 180000
复制代码

对于每一个 Sentinel 实例配置除了 port 和 logfile 不一样以外，其余配置项都是同样的。修改好配置后，咱们可使用 ./redis-sentinel sentinel.conf 命令来启动哨兵，命令跟 redis 实例启动差很少，由于哨兵也是 redis 实例，因此咱们可使用 ./redis-cli -p 26379 info sentinel 命令查看当前的哨兵信息，以下图所示：

问题：如何在只配置 master 服务器的状况下，发现从服务器和其余 Sentinel ？

从服务器的发现，Sentinel 能够经过询问主服务器来获取从服务器的信息，对于发现其余 Sentinel 节点，则经过发布与订阅功能实现，经过向频道 sentinel:hello 发送信息来实现的，主要有如下两步：

一、每一个 Sentinel 每 2 秒会经过发布与订阅功能向全部的主服务和从服务器的 sentinel:hello 频道发送一条信息， 信息中包含了 Sentinel 的 IP 地址、端口号和运行 ID （runid）

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

哨兵故障转移原理

故障转移是哨兵的主要工做，这背后的实现逻辑也是很是的复杂，具体的实现逻辑还请查看相关书籍，我对哨兵的故障转移总结了如下三点：

一、监听服务器

每一个 Sentinel 节点每隔 1 秒对主节点、从节点、其余 Sentinel 节点发送 ping 命令作心跳检测，来判断服务器的状态。

节点也会对 Sentinel 进行相应的回复，在这些回复中，如下三种回复是有效回复：

• 返回 +PONG
• 返回 -LOADING
• 返回 -MASTERDOWN

若是节点在哨兵配置文件设置的 master-down-after-milliseconds 选项的值内，一直没有哪怕一次有效回复，那么 Sentinel 会把该服务器标记为下线状态，咱们把这种下线称为主观下线，也就是说只有这个 sentinel 认为该服务器是下线状态。

若是被主观下线的服务器是主服务器时，sentinel 为了确认这个主服务器是否真的下线，该 Sentinel 会向其余的一样监听主服务器的 Sentinel 进行询问，看他们是否也认为主服务器进入下线状态，当有足够多的 Sentinel 都认为主服务器下线时，该 Sentinel 会将主服务器判断为客观下线，这是真正的下线了，而且会对它进行故障转移操做。

二、选举 Sentinel 节点完成转移任务

故障转移并非全部的 sentinel 共同完成，而是选举出一台 sentinel 节点做为领导者来完成此次故障转移，因此当主服务器被标记为客观下线时，sentinel 之间就会经过 Raft 算法选举出一个领导者来完成故障转移工做。redis 选举领头的 sentinel 的规则和方法大体以下：

• 全部在线的 sentinel 都有资格被选为领导者，也就是说每一个 sentinel 都有成为领导者的机会
• 当 sentinel 标记主服务器为主观下线时，会向其余 Sentinel 节点发送 sentinel is-master-down-by-addr 命令， 要求将本身设置为领导者
• 收到命令的 Sentinel 节点，采用先到先得的规则，若是没有赞成过其余 Sentinel 节点的 sentinel is-master-down-by-addr 命令，将赞成该请求，不然拒绝
• 若是该 Sentinel 节点发现本身的票数已经超过半数，那么它将成为领导者
• 若是在规定时间内，没有选举出 sentinel 领导者，那么将在一段时间后再次选举，知道选出 sentinel 领导者为止。

三、选举新 master 服务器完成故障转移

选举出来的 sentinel 领导者将完成剩下的故障转移工做，故障转移主要有如下三步：

一、挑选出新的主服务器

在已下线的主服务器的全部从服务器中，挑选出一个从服务器，并将其转换为主服务器，选择新的主服务器的规则以下：

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

对挑选出来的从服务器执行 slaveof no one 命令，使其成为主节点。

二、修改其余从服务器的复制目标

当新的主服务器出现后，sentinel 的领导者下一步须要作的就是，让其余从服务器去复制新的主服务器，经过向其余从服务器发送 slaveof new_master port 命令来完成，复制规则和配置文件的 parallel-syncs 参数有关

三、将旧的主服务器变成从服务器 故障转移操做最后要作的就是将已下线的主服务器设置为新的主服务的从服务器，并保持对其关注，等它恢复后命令它去复制新的主节点。

上面就是 redis 哨兵的一些知识，但愿看完以后你有所收获。

最后

目前互联网上不少大佬都有 Redis 系列教程，若有雷同，请多多包涵了。原创不易，码字不易，还但愿你们多多支持。若文中有所错误之处，还望提出，谢谢。

欢迎扫码关注微信公众号：「平头哥的技术博文」，和平头哥一块儿学习，一块儿进步。