Redis Sentinel（哨兵）详解

目录

 一：什么是Sentinel（哨兵）

二：Sentinel有什么用 

1.监控

2.故障转移

3通知

4.配置提供

三：Sentinel如何检测master节点宕机 

1.主观下线

2.客观下线

四：Sentinel是如何选举出新的master 

1.slave的优先级

2.复制进度 

3.runid 

 五：如何在sentinel集群中选择出Leader

---

前言：有关Redis的基础知识可以参照我之前写的文章Redis必知必会的知识

在之前的Redis的主从复制模式下，如果一个master宕机，那么需要从slave中选举一个新的master，并且需要修改应用方的master链接地址，还需要从剩余的slave节点复制新master的数据，在此过程中需要人工介入，消耗大量的时间和精力，因此Redis官方提出了一种新的方案就是Sentinel(哨兵)机制，可以实现自动化的故障转移，无需人工介入。

 一：什么是Sentinel（哨兵）

Sentinel是一中运行模式，不提供任何的读写过程，它只负责运行特殊的Redis命令执行自动化的故障转移。默认运行在26379端口上，依赖于Redis工作，可以通过以下命令让Redis以Sentinel的形式运行

redis-sentinel /path/to/sentinel.conf
或者
redis-server /path/to/sentinel.conf --sentinel

Redis的源码中sentinel.conf 就是用来配置Sentinel的

// 指定要监视的 master
// 127.0.0.1 6379 为 master 地址
// 2 表示当有 2 个 sentinel 认为 master 失效时，master 才算真正失效
sentinel monitor mymaster 127.0.0.1 6379 2
// master 节点宕机多长时间才会被 sentinel 认为是失效
sentinel down-after-milliseconds mymaster 60000
sentinel failover-timeout mymaster 180000
sentinel parallel-syncs mymaster 1

sentinel monitor resque 192.168.1.3 6380 4
sentinel down-after-milliseconds resque 10000
sentinel failover-timeout resque 180000
// 在发生主备切换时最多可以有 5 个 slave 同时对新的 master 进行同步
sentinel parallel-syncs resque 5

二：Sentinel有什么用 

根据Redis的官方文档可以知道，sentinel节点主要提供以下几个功能

1.监控

Sentinel会监控redis的每一个节点（master，slave），甚至包括监控自己

2.故障转移

当一个master节点出现故障后，Sentinel会自动帮助我们实现故障转移，自动将某一台的slave节点选举为新的master节点

3通知

通知slave连接线新的master节点，让他们执行replicaof命令成为新的master的slave

4.配置提供

客户端连接 sentinel 请求 master 的地址，如果发生故障转移，sentinel 会通知新的 master 链接信息给客户端。

三：Sentinel如何检测master节点宕机 

1.主观下线

所谓的主观下线是指当某一个Sentinel节点认为一个master节点已经下线了，但是还不是很确定，需要其他的Sentinel进行投票

2.客观下线

客观下线是指过法定票数的sentinel节点认为某一个master已经下线，那么这个master节点就真的下线了

 其实就是当sentinel自己认为master下线那么就是主观下线，而sentinel整体达成一致认为master下线那么就是客观下线。

具体的步骤如下：

每个 sentinel 节点以每秒钟一次的频率向整个集群中的 master、slave 以及其他 sentinel 节点发送一个 PING 命令。

主观下线：

 如果对应的节点超过规定的时间（down-after-millisenconds）没有进行有效回复的话，就会被其认定 为是 主观下线(SDOWN) 。注意！这里的有效回复不一定是 PONG，可以是-LOADING 或者 - MASTERDOWN 。

客观下线：

所有 sentinel 节点要以每秒一次的频率确认 master 的确下线了，当法定数量（通常为过半）的 sentinel 节点认定 master 已经下线， master 才被判定为 客观下线(ODOWN) 。这样做的目的是为了 防止误判，毕竟故障转移的开销还是比较大的，这也是为什么 Redis 官方推荐部署多个 sentinel 节点 （哨兵集群）。

sentinel 中会有一个 Leader 的角色来负责故障转移，也就是自动地从 slave 中选出一个新的 master 并执行完相关的一些工作(比如通知 slave 新的 master 连接信息，让它们执行 replicaof 成为新 的 master 的 slave)。如果没有足够数量的 sentinel 节点认定 master 已经下线的话，当 master 能对 sentinel 的 PING 命令 进行有效回复之后，master 也就不再被认定为主观下线，回归正常。 

四：Sentinel是如何选举出新的master 

slave必须是在线状态才能参加竞选成为新的master，sentinel在选举新的master时是基于以下3个方面来实现的

1.slave的优先级

可以通过slave-priority手动设置slave的优先级，优先级越高成为master的几率也就越高，优先级最高的slave可以直接成为master，如是没有设置slave的优先级sentinel会采用复制进度进一步判断

2.复制进度 

sentinel会选择出数据最完整也就是复制进度最快的slave节点升级为master

3.runid 

通常经过前面两轮筛选已经成果选出来了新的 master，万一真有多个 slave 的优 先级和复制进度一样的话，那就 runid 小的成为新的 master，每个 redis 节点启动时都有一个 40 字节随机字符串作为运行 id。

 五：如何在sentinel集群中选择出Leader

这就需要用到分布式领域的 共识算法 了。简单来说，共识算法就是让分布式系统中的节点就一个问题达成共识。在 sentinel 选举 leader 这个场景下，这些 sentinel 要达成的共识就是谁才是 leader 。 大部分共识算法都是基于 Paxos 算法改进而来，在 sentinel 选举 leader 这个场景下使用的是 Raft 算 法。这是一个比 Paxos 算法更易理解和实现的共识算法—Raft 算法。更具体点来说，Raft 是 MultiPaxos 的一个变种，其简化了 Multi-Paxos 的思想，变得更容易被理解以及工程实现
有关 Raft 算法可以参考以下文章：Raft详解

Raft 协议实战之 Redis Sentinel 的选举 Leader 源码解析