redis—学习笔记 第九章 哨兵

第9章 哨兵

9.1 基本概念？解决了什么问题

​ Redis的主从复制模式可以将主节点的数据改变同步给从节点，这样从节点就可以起到两个作用：第一，作为主节点的一个备份，一旦主节点出了故障不可达的情况，从节点可以作为后备“顶”上来，并且保证数据尽量不丢失（主从复制是最终一致性）。第二，从节点可以扩展主节点的读能力，一旦主节点不能支撑住大并发量的读操作，从节点可以在一定程度上帮助主节点分担读压力。
但是主从复制也带来了以下问题：

1. 一旦主节点出现故障，需要手动将一个从节点晋升为主节点，同时需要修改应用方的主节点地址，还需要命令其他从节点去复制新的主节点，整个过程都需要人工干预。
2. ·主节点的写能力受到单机的限制。
3. ·主节点的存储能力受到单机的限制。
   Redis主从复制模式下，一旦主节点出现了故障不可达，需要人工干预进行故障转移

9.1.1 高可用

1. 主节点发生故障后，客户端（client）连接主节点失败，两个从节点与主节点连接失败造成复制中断

2. 如果主节点无法正常启动，需要选出一个从节点（slave-1）对其执行slaveof no one命令使其成为新的主节点
   

3. 原来的从节点（slave-1）成为新的主节点后，更新应用方的主节点信息，重新启动应用方
   

4. 客户端命令另一个从节点（slave-2）去复制新的主节点（new-master）
   

5. 待原来的主节点恢复后，让它去复制新的主节点
   

展示了一个1主2从的Redis主从复制模式下的主节点出现故障后，是如何进行故障转移的但是仍然存在如下问题：第一，判断节点不可达的机制是否健全和标准。第二，如果有多个从节点，怎样保证只有一个被晋升为主节点。第三，通知客户端新的主节点机制是否足够健壮。由于是人工操作，Redis Sentinel正是用于解决这些问题。

9.1.3 Redis Sentinel的高可用性

​ 当主节点出现故障时，Redis Sentinel能自动完成故障发现和故障转移，并通知应用方，从而实现真正的高可用。

​ 下面以1个主节点、2个从节点、3个Sentinel节点组成的Redis Sentinel为例子进行说明，拓扑结构如图

1. 主节点出现故障，此时两个从节点与主节点失去连接，主从复制失败。
   
2. 每个Sentinel节点通过定期监控发现主节点出现了故障。
   
3. 多个Sentinel节点对主节点的故障达成一致，选举出sentinel-3节点作为领导者负责故障转移
   
4. Sentinel领导者节点执行了故障转移

5. 故障转移后整个Redis Sentinel的拓扑结构图

通过上面介绍的Redis Sentinel逻辑架构以及故障转移的处理，可以看出Redis Sentinel具有以下几个功能

1. 监控：Sentinel节点会定期检测Redis数据节点、其余Sentinel节点是否可达。
2. ·通知：Sentinel节点会将故障转移的结果通知给应用方。
3. ·主节点故障转移：实现从节点晋升为主节点并维护后续正确的主从关系。
4. 配置提供者：在RedisSentinel结构中，客户端在初始化的时候连接的是Sentinel节点集合，从中获取主节点信息同时看到，Redis Sentinel包含了若个Sentinel节点，这样做也带来了两个好处：
1. 对于节点的故障判断是由多个Sentinel节点共同完成，这样可以有效地防止误判。
2.Sentinel节点集合是由若干个Sentinel节点组成的，这样即使个别Sentinel节点不可用，整个Sentinel节点集合依然是健壮的。

Sentinel节点本身就是独立的Redis节点，只不过它们有一些特殊，它们不存储数据，只支持部分命令

9.2 安装和部署

9.2.1 部署拓扑结构

9.2.2 部署Redis数据节点

1. 启动主节点

配置:
    redis-6379.conf
    port 6379
    daemonize yes
    logfile "6379.log"
    dbfilename "dump-6379.rdb"
    dir "/opt/soft/redis/data/"
启动主节点：
	redis-server redis-6379.conf
确认是否启动。一般来说只需要ping命令检测一下就可以，确认Redis数据节点是否已经启动。
    $ redis-cli -h 127.0.0.1 -p 6379 ping
    PONG

2. 启动两个从节点

配置：和主节点的配置不一样的是添加了slaveof配置。
    redis-6380.conf
    port 6380
    daemonize yes
    logfile "6380.log"
    dbfilename "dump-6380.rdb"
    dir "/opt/soft/redis/data/"
    slaveof 127.0.0.1 6379
启动两个从节点：
    redis-server redis-6380.conf
    redis-server redis-6381.conf
验证：
主节点的视角，它有两个从节点，分别是127.0.0.1：6380和127.0.0.1：6381：
	$ redis-cli -h 127.0.0.1 -p 6379 info replication
    # Replication
    role:master
	connected_slaves:2
    slave0:ip=127.0.0.1,port=6380,state=online,offset=281,lag=1
    slave1:ip=127.0.0.1,port=6381,state=online,offset=281,lag=0
    .................
从节点的视角，它的主节点是127.0.0.1：6379：
	$ redis-cli -h 127.0.0.1 -p 6380 info replication
    # Replication
    role:slave
    master_host:127.0.0.1
    master_port:6379
    master_link_status:up
    .................

9.2.3 部署Sentinel节点

3个Sentinel节点的部署方法是完全一致的（端口不同），下面以sentinel-1节点的部署为例子进行说明

1. 配置Sentinel节点

redis-sentinel-26379.conf
port 26379
daemonize yes
logfile "26379.log"
dir /opt/soft/redis/data
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

1）Sentinel节点的默认端口是26379。
2）sentinel monitor mymaster127.0.0.163792配置代表sentinel-1节点需要监控127.0.0.1：6379这个主节点，2代表判断主节点失败至少需要2个Sentinel节点同意，mymaster是主节点的别名，其余Sentinel配置将在下一节进行详细说明。

2. 启动Sentinel节点

   Sentinel节点的启动方法有两种：
   方法一，使用redis-sentinel命令
   	redis-sentinel redis-sentinel-26379.conf
   方法二，使用redis-server命令加--sentinel参数：
   	redis-server redis-sentinel-26379.conf --sentinel
   
   

3. 确认

   $ redis-cli -h 127.0.0.1 -p 26379 info Sentinel
   # Sentinel
   sentinel_masters:1
   sentinel_tilt:0
   sentinel_running_scripts:0
   sentinel_scripts_queue_length:0
   master0:name=mymaster,status=ok,address=127.0.0.1:6379,slaves=2,sentinels=3
   

   从下面info的Sentinel片段来看，Sentinel节点找到了主节点127.0.0.1：6379，发现了它的两个从节点，同时发现Redis Sentinel一共有3个Sentinel节点

建议

1. 生产环境中建议Redis Sentinel的所有节点应该分布在不同的物理机上。
2. Redis Sentinel中的数据节点和普通的Redis数据节点在配置上没有任何区别，只不过是添加了一些Sentinel节点对它们进行监控。
   

9.2.4 配置优化

1.配置说明和优化

port 26379  Sentinel节点的端口 
dir /opt/soft/redis/data 工作目录
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 auth-pass <master-name> <password>
#sentinel notification-script <master-name> <script-path>
#sentinel client-reconfig-script <master-name> <script-path>

（1）sentinel monitor

sentinel monitor <master-name> <ip> <port> <quorum>

​ Sentinel节点会定期监控主节点，所以从配置上必然也会有所体现，本配置说明Sentinel节点要监控的是一个名字叫做master-name，ip地址和端口为的主节点。quorum代表要判定主节点最终不可达所需要的票数。但实际上Sentinel节点会对所有节点进行监控,但是在Sentinel节点的配置中没有看到有关从节点和其余Sentinel节点的配置，那是因为Sentinel节点会从主节点中获取有关从节点以及其余Sentinel节点的相关信息

​ quorum参数用于故障发现和判定，例如将quorum配置为2，代表至少有2个Sentinel节点认为主节点不可达，那么这个不可达的判定才是客观的。对于设置的越小，那么达到下线的条件越宽松，反之越严格。一般建议将其设置为Sentinel节点的一半加1

​ 同时还与Sentinel节点的领导者选举有关，至少要有max（quorum，num（sentinels）/2+1）个Sentinel节点参与选举，才能选出领导者Sentinel，从而完成故障转移

（2）sentinel down-after-milliseconds

sentinel down-after-milliseconds <master-name> <times>
每个Sentinel节点都要通过定期发送ping命令来判断Redis数据节点和其余Sentinel节点是否可达，如果超过了down-after-milliseconds配置的时间且没有有效的回复，则判定节点不可达，<times>（单位为毫秒）就是超时时
间。这个配置是对节点失败判定的重要依据
down-after-milliseconds越大，代表Sentinel节点对于节点不可达的条件越宽松，反之越严格

（3）sentinel parallel-syncs

sentinel parallel-syncs <master-name> <nums>

当Sentinel节点集合对主节点故障判定达成一致时，Sentinel领导者节点会做故障转移操作，选出新的主节点，原来的从节点会向新的主节点发起复制操作，parallel-syncs就是用来限制在一次故障转移之后，每次向新的主节点发起复制操作的从节点个数。如果这个参数配置的比较大，那么多个从节点会向新的主节点同时发起复制操作，尽管复制操作通常不会阻塞主节点，但是同时向主节点发起复制，必然会对主节点所在的机器造成一定的网络和磁盘IO开销。

（4）sentinel failover-timeout

sentinel failover-timeout <master-name> <times>

failover-timeout通常被解释成故障转移超时时间，但实际上它作用于故障转移的各个阶段

1）如果Redis Sentinel对一个主节点故障转移失败，那么下次再对该主节点做故障转移的起始时间是failover-timeout的2倍。
2）如果Sentinel节点向a阶段选出来的从节点执行slaveof no one一直失败（例如该从节点此时出现故障），当此过程超过failover-timeout时，则故障转移失败。
3）如果执行成功，Sentinel节点还会执行info命令来确认a）阶段选出来的节点确实晋升为主节点，如果此过程执行时间超过failovertimeout时，则故障转移失败。
4）如果执行时间超过了failover-timeout（不包含复制时间），则故障转移失败。注意即使超过了这个时间，Sentinel节点也会最终配置从节点去同步最新的主节点。

（5）sentinel auth-pass

sentinel auth-pass <master-name> <password>
如果Sentinel监控的主节点配置了密码，sentinel auth-pass配置通过添加主节点的密码，防止Sentinel节点对主节点无法监控。

9.2.5 部署技巧

1. Sentinel节点不应该部署在一台物理“机器”上。
2. 部署至少三个且奇数个的Sentinel节点。
3. Sentinel节点集合可以只监控一个主节点，也可以监控多个主节点,如果Sentinel节点集合监控的是同一个业务的多个主节点集合一套Sentinel

9.3 API

1. sentinel masters 展示所有被监控的主节点状态以及相关的统计信息

2. sentinel master<master name> 展示指定<master name>的主节点状态以及相关的统计信息
   

3. sentinel slaves<master name> 展示指定<master name>的从节点状态以及相关的统计信息
   

4. sentinel sentinels <master name> 展示指定<master name>的Sentinel节点集合（不包含当前Sentinel节
   

5. sentinel get-master-addr-by-name<master name> 返回指定<master name>主节点的IP地址和端口，
   

6. sentinel reset<pattern>当前Sentinel节点对符合<pattern>（通配符风格）主节点的配置进行重
   置，包含清除主节点的相关状态（例如故障转移），重新发现从节点和Sentinel节点
   

7. sentinel failover<master name> 对指定<master name>主节点进行强制故障转移（没有和其他Sentinel节点“协商”），当故障转移完成后，其他Sentinel节点按照故障转移的结果更新自身配置
   

8.  sentinel ckquorum<master name> 检测当前可达的Sentinel节点总数是否达到<quorum>的个数。
   

9. sentinel remove<master name> 取消当前Sentinel节点对于指定<master name>主节点的监控。
   

10. sentinel monitor<master name><ip><port><quorum> 通过命令的形式来完成Sentinel节点对主节点的监控
    

11. sentinel is-master-down-by-addr 用来交换对主节点是否下线的判断，根据参数的不同，还可以作为Sentinel领导者选举的通信方式
    

9.4 客户端连接

Redis Sentinel客户端基本实现原理

1. 遍历Sentinel节点集合获取一个可用的Sentinel节点，后面会介绍Sentinel节点之间可以共享数据，所以从任意一个Sentinel节点获取主节点信息都是可以的
   

2. 通过sentinel get-master-addr-by-name master-name这个API来获取对应主节点的相关信息
   
   3）验证当前获取的“主节点”是真正的主节点，这样做的目的是为了防止故障转移期间主节点的变化，

4. 保持和Sentinel节点集合的“联系”，时刻获取关于主节点的相关“信息”，

9.5 实现原理

​ 一套合理的监控机制是Sentinel节点判定节点不可达的重要保证，RedisSentinel通过三个定时监控任务完成对各个节点发现和监控.

9.5.1 三个定时监控任务

1. 每隔10秒，每个Sentinel节点会向主节点和从节点发送info命令获取最新的拓扑结构

2. 每隔2秒，每个Sentinel节点会向Redis数据节点的__sentinel__：hello频道上发送该Sentinel节点对于主节点的判断以及当前Sentinel节点的信息，同时每个Sentinel节点也会订阅该频道，来了解其他Sentinel节点以及它们对主节点的判断,所以这个定时任务可以完成以下两个工作：

   1. 发现新的Sentinel节点：通过订阅主节点的__sentinel__：hello了解其他的Sentinel节点信息，如果是新加入的Sentinel节点，将该Sentinel节点信息保存起来，并与该Sentinel节点创建连接
   2. Sentinel节点之间交换主节点的状态，作为后面客观下线以及领导者选举的依据。
      

3. 每隔1秒，每个Sentinel节点会向主节点、从节点、其余Sentinel节点发送一条ping命令做一次心跳检测，来确认这些节点当前是否可达.通过上面的定时任务，Sentinel节点对主节点、从节点、其余Sentinel节点都建立起连接，实现了对每个节点的监控，这个定时任务是节点失败判定的重要依据。
   

9.5.2 主观下线和客观下线

1. 主观下线
   每个Sentinel节点会每隔1秒对主节点、从节点、其他Sentinel节点发送ping命令做心跳检测，当这些节点超过down-after-milliseconds没有进行有效回复，Sentinel节点就会对该节点做失败判定，这个行为叫做主观下线

2. 客观下线
   当Sentinel主观下线的节点是主节点时，该Sentinel节点会通过sentinel ismaster-down-by-addr命令向其Sentinel节点询问对主节点的判断，当超过quorum个数，Sentinel节点认为主节点确实有问题，这时该Sentinel节点会做出客观下线的决定，这样客观下线的含义是比较明显了，也就是大部分Sentinel节点都对主节点的下线做了同意的判定，那么这个判定就是客观的

sentinel is-master-down-by-addr <ip> <port> <current_epoch> <runid>
ip：主节点IP。
·port：主节点端口。
·current_epoch：当前配置纪元。
·runid：此参数有两种类型，不同类型决定了此API作用的不同。
当runid等于“*”时，作用是Sentinel节点直接交换对主节点下线的判定。
当runid等于当前Sentinel节点的runid时，作用是当前Sentinel节点希望目标Sentinel节点同意自己成为领导者的请求

9.5.3 领导者Sentinel节点选举

​ 假如Sentinel节点对于主节点已经做了客观下线，那么是不是就可以立即进行故障转移了？当然不是，实际上故障转移的工作只需要一个Sentinel节点来完成即可，所以Sentinel节点之间会做一个领导者选举的工作，选出一个Sentinel节点作为领导者进行故障转移的工作

1. 每个在线的Sentinel节点都有资格成为领导者，当它确认主节点主观下线时候，会向其他Sentinel节点发送sentinel is-master-down-by-addr命令，要求将自己设置为领导者
2. 收到命令的Sentinel节点，如果没有同意过其他Sentinel节点的sentinelis-master-down-by-addr命令，将同意该请求，否则拒绝。
3. 如果该Sentinel节点发现自己的票数已经大于等于max（quorum，num（sentinels）/2+1），那么它将成为领导者
4. 如果此过程没有选举出领导者，将进入下一次选举

9.5.4 故障转移

领导者选举出的Sentinel节点负责故障转移，具体步骤如下:

1. 在从节点列表中选出一个节点作为新的主节点，选择方法如下：

• 过滤：“不健康”（主观下线、断线）、5秒内没有回复过Sentinel节点ping响应、与主节点失联超过down-after-milliseconds*10秒
• 选择slave-priority（从节点优先级）最高的从节点列表，如果存在则返回，不存在则继续
• 选择复制偏移量最大的从节点（复制的最完整），如果存在则返回，不存在则继续
• 选择runid最小的从节点
  

2. Sentinel领导者节点会对第一步选出来的从节点执行slaveof no one命令让其成为主节点。
3. Sentinel领导者节点会向剩余的从节点发送命令，让它们成为新主节点的从节点，复制规则和parallel-syncs参数有关
4. Sentinel节点集合会将原来的主节点更新为从节点，并保持着对其关注，当其恢复后命令它去复制新的主节点

本章重点回顾

1. Redis Sentinel是Redis的高可用实现方案：故障发现、故障自动转移、配置中心、客户端通知。
2. 尽可能在不同物理机上部署Redis Sentinel所有节点。
3. Redis Sentinel中的Sentinel节点个数应该为大于等于3且最好为奇数。
4. Redis Sentinel中的数据节点与普通数据节点没有区别。
5. 客户端初始化时连接的是Sentinel节点集合，不再是具体的Redis节点，但Sentinel只是配置中心不是代理。
6. edis Sentinel通过三个定时任务实现了Sentinel节点对于主节点、从节点、其余Sentinel节点的监控。
7. Redis Sentinel在对节点做失败判定时分为主观下线和客观下线。
8. 看懂Redis Sentinel故障转移日志对于Redis Sentnel以及问题排查非常有帮助。
9. Redis Sentinel实现读写分离高可用可以依赖Sentinel节点的消息通知，获取Redis数据节点的状态变化。