Redis学习笔记 - 哨兵

现在这篇来学习一下Redis Sentinel即哨兵策略的相关知识。

1.什么是哨兵？

哨兵（Sentinel），Redis2.6版本（正式版本是2.8，现2.6版本已被废弃）开始提供的一种集群策略，核心思想是解决了主从复制（Replication）在Master节点故障，无法自动切换Slave节点为新Master节点的问题。

• 特点

  1. 哨兵策略是分布式部署，节点间相互协调工作。
  2. 哨兵集群至少要3个节点。
  3. 可以把哨兵看作是一种特殊的Redis服务。

• 优点

  1. 哨兵策略拥有主从复制的优点。
  2. 哨兵策略解决了Master节点故障，无法自动切换Slave节点为新Master节点的问题。

• 缺点
  1. Master节点写操作的压力没有得到解决。
  2. 数据存储能力还是受到单节点限制。

2.如何配置（多种方式）

• 启动Redis哨兵，./redis-sentinel redis-sentinel.conf
• 启动Redis服务时并且启动哨兵，./redis-server redis-sentinel.conf –sentinel

redis-sentinel.conf示例

# 哨兵监控的节点。
# MASTER_NAME：自定义的Master节点名称。
# IP：Master节点的地址。
# PORT：Master节点的端口。
# QUORUM：当Master节点故障，确认Master节点odown最少的哨兵数量。
sentinel monitor {MASTER_NAME} {IP} {PORT} {QUORUM}

# 哨兵验证
# PASS：Master节点的auth，需要注意的时哨兵不能同时为Master节点和Slave节点设置密码，所以auth需要保持一致。
sentinel auth-pass {MASTER_NAME} {PASS}

# 哨兵心跳Ping最大时间，如果哨兵向Master节点发送Ping超过这个时间或者回复err，那么哨兵会主观（sdown）认为该Master节点已经处于不可用状态。
# MS：心跳Ping等待响应的最大时间（单位：Millisecond）。
sentinel down-after-milliseconds {MASTER_NAME} {MS}

# 同时同步数据的Slave节点数量
# SLAVE_NUM：当Master节点故障，Slave节点通过竞选当选新Master节点，最多允许几个Slave节点开始同步新Master的数据。
sentinel parallel-syncs {MASTER_NAME} {SLAVE_NUM}

# 主从节点切换所需要的最大时间。
# MS：主从节点切换所需要的最大时间（单位：Millisecond）。
sentinel failover-timeout {MASTER_NAME} {MS}

# Master节点故障调用的脚本
# SCRIPT_PATH：脚本路径
sentinel notification-script {MASTER_NAME} {SCRIPT_PATH}

3.工作机制

1. 哨兵向已知节点和哨兵发送心跳包检测状态。
2. Master节点无效回复，哨兵判断Master节点状态：主观宕机，客观宕机。
3. Master节点被确定客观宕机，进行领头（Leader）哨兵选举。
4. 准备进行主从切换的领头哨兵获取其他哨兵的授权。
5. 授权成功，从Slave节点中选举新Master节点。
6. 领头哨兵把新Master节点信息同步给其他哨兵，其他哨兵把新Master节点信息同步对应Slave节点。

4.心跳包

每个哨兵以每秒钟1次的频率向它已知的Master节点、Slave节点和其他哨兵发送PING命令，希望得到的有效回复如下：

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

其它任何回复或者无回复都是无效回复。

5.哨兵和节点之间的自动发现机制

通过Redis的pub/sub系统实现，每个哨兵都会向自己监控的节点对应的channel：sentinel:hello发送一条消息（消息体包含自己的{IP}、{PORT}和{RUNID}以及Master节点的完整配置），每个订阅该channel的哨兵都可以消费这条消息并且能发现到其他哨兵的存在，如果某个哨兵发现自己维护的节点配置低于新接收的节点配置，则会用新的节点配置进行覆盖。

6.主观/客观宕机

如果一个Master节点在收到PING命令后没有在有效时间内（down-after-milliseconds）进行有效回复，则会被标记为主观宕机（sdown，Subjectively Down）。

哨兵会获取其他哨兵检测该节点的状态，命令：

# IP：主观宕机的Master节点地址
# PORT：主观宕机的Master节点端口
# CURRENT_EPOCH：哨兵的配置纪元，用于领头哨兵选举。
# RUNID：可以是*和哨兵的RunID，当值是 * 代表检测节点是否主观宕机，如果是RunID则用于领头哨兵选举。
SENTINEL is-master-down-byaddr {IP} {PORT} {CURRENT_EPOCH} {RUNID}

当有足够数量（{QUORUM}）的哨兵都认为该Master节点处于主观宕机状态。则该Master节点会被标记为客观宕机（odown，Objectively Down），若没有足够数量的哨兵都认为该Master节点处于主观宕机状态，则不会被标记为客观宕机，同时如果该Master节点重新返回哨兵有效回复，该Master节点主观宕机状态会被移除。

7.领头哨兵选举

因为只需要一个哨兵完成主从切换，所以需要选举一个领头哨兵。

1. 每个哨兵都会发送SENTINEL is-master-down-byaddr命令希望成为领头哨兵。收到该命令的哨兵如果没有同意过其他哨兵的同样命令，那么同意该请求，否则拒绝。
2. 如果某一哨兵发现同意自己请求的哨兵数量并且数量大于等于{QUORUM}，那么它将成为领头哨兵。
3. 如果选举过程中有多个哨兵当选领头哨兵，等待一段时间后选举会重新进行。

该方法基于raft算法领头选举方法实现。

8.主从切换授权

当选举出领头哨兵之后并未马上进行主从切换，领头哨兵还需要获取{MAJORITY}数量的哨兵授权。

# MAJORITY：该值不可配置，Redis自行计算。公式：majority = voters / 2 + 1

• 如果{QUORUM} < {MAJORITY}，领头哨兵需要{MAJORITY}数量的哨兵进行授权。
• 如果{QUORUM} >= {MAJORITY}，那么领头哨兵需要{QUORUM}数量的哨兵授权才可以。

当领头哨兵获得授权之后，正式开始主从切换流程。

9.主从切换

开始主从切换（failover），首先领头哨兵会选举出一个Slave节点出来作为新Master节点，该Slave节点选举参考参数：

• 该节点和Master节点断开的时长，如果一个Slave节点与Master节点断开连接时间已经超过down-after-milliseconds参数的10倍，再加上Master宕机的时长，该Slave节点就会被认为不适合选举为新的Master节点。

  (down-after-milliseconds * 10) + milliseconds_since_master_is_in_SDOWN_state

• Slave节点的优先级（slave-priority），slave-priority越低优先级越高。
• 复制数据偏移量（复制数据最完整）
• RunID（最小的）

10.配置同步

在领头哨兵完成主从切换之后，会在本地生成最新的Master配置然后通过pub/sub消息机制同步给其他哨兵，其他哨兵则更新对应的Master节点配置。

那么其他哨兵怎么知道这份配置是最新的呢？

领头哨兵准备执行主从切换前，会从要切换成新Master节点的Slave节点取得一个configuration epoch，可以理解为配置版本号。如果领头哨兵主从切换失败了，那么其他哨兵会等待failover-timeout时间然后接替继续执行切换，每次接替都会重新获取一个configuration epoch，作为新的配置版本号。如果领头哨兵切换成功，那么其他哨兵会根据自己的配置版本号来更新对应Slave节点的Master节点配置。

最后

为什么说哨兵最少要3个节点，举个例子：

如果是2个节点，{QUORUM}值为1，此时其中一台服务器出现客观宕机。领头哨兵需要进行主从切换，在进行主从切换前需要获取{MAJORITY}数量的哨兵同意，该{MAJORITY}参数最小的值是：2，此时领头哨兵无法进行主从切换。

https://redis.io/topics/sentinel