《Redis开发与运维》---- 哨兵（Redis Sentinel）

一、基本概念

1、主从复制的问题

• 高可用问题：一旦主节点出现故障，需要手动将一个从节点晋升为主节点，同时需要修改应用方的主节点地址，还需要命令其他从节点去复制新的主节点，整个过程都需要人工干预。
• 分布式问题：主节点的写能力受到单机的限制。
• 分布式问题：主节点的存储能力受到单机的限制。

2、传统的高可用

整个故障转移过程需要人工介入。即使有的公司把故障转移过程自动化了，但依然有如下问题：

• 判断节点不可达的机制是否健全
• 如果有多个从节点，怎样保证只有一个被晋升为主节点
• 通知客户端新的主节点机制是否健壮

3、Redis Sentinel 的高可用

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

Redis Sentinel是一个分布式架构，其中包含若干个Sentinel节点和Redis数据节点，每个Sentinel节点会对数据节点和其余Sentinel节点进行监控，当它发现节点不可达时，会对节点做下线标识。如果被标识的是主节点，它还会和其他Sentinel节点进行“协商”，当大多数Sentinel节点都认为主节点不可达时，它们会选举出一个Sentinel节点来完成自动故障转移的工作，同时会将这个变化实时通知给Redis应用方。

整个过程完全是自动的，不需要人工来介入，所以这套方案很有效地解决了Redis的高可用问题。

• 整个故障转移的4个步骤
  （1）主节点出现故障，此时两个从节点与主节点失去连接，主从复制失败。
  

（2）每个Sentinel节点通过定期监控发现主节点出现了故障。

（3）多个Sentinel节点对主节点的故障达成一致，选举出sentinel-3节点作为领导者负责故障转移。

（4）Sentinel领导者节点执行了故障转移

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

• Redis Sentinel的几个功能：
  （1）监控：Sentinel节点会定期检测Redis数据节点、其余Sentinel节点是否可达。
  （2）通知：Sentinel节点会将故障转移的结果通知给应用方。
  （3）主节点故障转移：实现从节点晋升为主节点并维护后续正确的主从关系。
  （4）配置提供者：在Redis Sentinel结构中，客户端在初始化的时候连接的是Sentinel节点集合，从中获取主节点信息。

• Redis Sentinel包含了若个Sentinel节点，这样做的好处:（1）防止节点下线的误判;（2）保证整个Sentinel节点集合的健壮性

二、安装和部署

1、具体配置参考自己的命令文档：https://editor.csdn.net/md/?articleId=108286324

2、以下是本人的sentinel的配置， Redis文件夹下有个默认的sentinel.conf 可以参考。

port 26379

# 是否以后台进程运行 为了测试方便  所以这里是否
daemonize no
# 不配置logfil 日志就会在启动时打印  为了测试方便
# logfile mysentinel.log

dir /usr/local/src/redis-4.0.14

sentinel monitor mymaster 192.168.164.103 6379 2

sentinel auth-pass mymaster 12345

sentinel parallel-syncs mymaster 1

sentinel failover-timeout mymaster 180000

# 默认：保护模式开启  
# PS:如果是自己新建的sentinel.conf文件一定要配置成no  不然client连不上sentinel
protected-mode no

3、启动Sentinel节点

Sentinel节点的启动方法有两种：

方法一，使用redis-sentinel命令：

redis-sentinel my-sentinel.conf

方法二，使用redis-server命令加--sentinel参数

redis-server my-sentinel.conf --sentinel

查看sentinel启动后的信息：info sentinel

$ 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

4、配置优化

• sentinel monitor <master-name> <ip> <port> <quorum>
<master-name> sentinel节点要监控的主节点的别名。
  <quorum>代表要判定主节点最终不可达所需要的票数。一般设置为sentinel节点的一半加1。

• sentinel down-after-milliseconds <master-name> <times>
  每个Sentinel节点都要通过定期发送ping命令来判断Redis数据节点和其余Sentinel节点是否可达，如果超过了down-after-milliseconds配置的时间且没有有效的回复，则判定节点不可达。

• sentinel parallel-syncs <master-name> <nums>
  当Sentinel节点集合对主节点故障判定达成一致时，Sentinel领导者节点会做故障转移操作，选出新的主节点，原来的从节点会向新的主节点发起复制操作，parallel-syncs就是用来限制在一次故障转移之后，每次向新的主节点发起复制操作的从节点个数。过多节点同时复制，会引起主节点的网络和磁盘的开销。

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

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

• sentinel notification-script <master-name> <script-path>
  在故障转移期间，当一些警告级别的Sentinel事件发生（指重要事件，例如-sdown：客观下线、-odown：主观下线）时，会触发对应路径的脚本，并向脚本发送相应的事件参数。可以利用这些参数作为邮件或者短信报警依据。

• sentinel client-reconfig-script <master-name> <script-path>
  在故障转移结束后，会触发对应路径的脚本，并向脚本发送故障转移结果的相关参数。和notification-script类似。

如果需要运维的Redis Sentinel比较多，建议不要使用这种脚本的形式来进行通知，这样会增加部署的成本。

5、如何监控多个主节点

Redis Sentinel可以同时监控多个主节点，只需要指定多个masterName来区分不同的主节点即可。

6、调整配置

Sentinel节点也支持动态地设置参数：sentinel set <param> <value>
注意：
（1）sentinel set命令只对当前Sentinel节点有效。
（2）sentinel set命令如果执行成功会立即刷新配置文件，这点和Redis普通数据节点设置配置需要执行config rewrite刷新到配置文件不同。
（3）Sentinel对外不支持config命令。？？？？

7、部署技巧：方案选择

方案一：一套Sentinel，监控多个master群
方案二：多套Sentinel，监控各自的master群

如果Sentinel节点集合监控的是同一个业务的多个主节点集合，那么使用方案一、否则一般建议采用方案二。

三、API

Sentinel节点是一个特殊的Redis节点，它有自己专属的API。

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

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

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

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

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

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

• sentinel failover <master name>
  对指定主节点进行强制故障转移（没有和其他Sentinel节点“协商”），当故障转移完成后，其他Sentinel节点按照故障转移的结果更新自身配置，这个命令在Redis Sentinel的日常运维中非常有用

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

• sentinel flushconfig
  将Sentinel节点的配置强制刷到磁盘上，这个命令Sentinel节点自身用得比较多，对于开发和运维人员只有当外部原因（例如磁盘损坏）造成配置文件损坏或者丢失时，这个命令是很有用的。

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

• sentinel monitor <master name> <ip> <port> <quorum>
  这个命令和配置文件中的含义是完全一样的，只不过是通过命令的形式来完成Sentinel节点对主节点的监控。

• sentinel set <master name> <param> <value>
  动态修改Sentinel节点配置选项，9.2.4小节已讲。

• sentinel is-master-down-by-addr <ip> <port> <current_epoch> <runid>
  Sentinel节点之间用来交换对主节点是否下线的判断，根据参数的不同，还可以作为Sentinel领导者选举的通信方式。9.5节会介绍。
  current_epoch：当前配置纪元。
  runid：此参数有两种类型，不同类型决定了此API作用的不同。
  当runid等于“*”时，作用是Sentinel节点直接交换对主节点下线的判定。
  当runid等于当前Sentinel节点的runid时，作用是当前Sentinel节点希望目 标Sentinel节点同意自己成为领导者的请求

四、实现原理

1、Redis Sentinel的三个定时任务

1. 每隔10秒，每个Sentinel节点会向主节点和从节点发送info命令获取最新的拓扑结构
2. 每隔2秒，每个Sentinel节点会向Redis数据节点的__sentinel__：hello频道上发送该Sentinel节点对于主节点的判断以及当前Sentinel节点的信息。作用：（1） 发现新的Sentinel节点、（2）Sentinel节点之间交换主节点的状态
3. 每隔1秒，每个Sentinel节点会向主节点、从节点、其余Sentinel节点发送一条ping命令做一次心跳检测，来确认这些节点当前是否可达。

2、主观下线和客观下线

• 主观下线：Sentinel节点发送ping命令做心跳检测，当这些节点超过down-after-milliseconds没有进行有效回复，Sentinel节点就会对该节点做失败判定，这个行为叫做主观下线。

• 客观下线： 当Sentinel主观下线的节点是主节点时，该Sentinel节点会通过sentinel ismaster-down-by-addr命令向其他Sentinel节点询问对主节点的判断，当超过个数，Sentinel节点认为主节点确实有问题。如果大部分Sentinel节点都对主节点的下线做了同意的判定，那么这个判定就是客观的。

3、领导者Sentinel节点选举

实际上故障转移的工作只需要一个Sentinel节点来完成即可（也就是leader），类似zookeeper投票选举。

4、故障转移

领导者选举出的Sentinel节点负责故障转移。

五、开发与运维中的问题

测试故障转移的方法

方法一，强制杀掉对应节点的进程号，这样可以模拟出宕机的效果。
方法二，使用Redis的debug sleep命令，让节点进入睡眠状态，这样可以模拟阻塞的效果。
方法三，使用Redis的shutdown命令，模拟正常的停掉Redis。

高可用读写分离

Redis Sentinel在对各个节点的监控中，如果有对应事件的发生，都会发出相应的事件消息（见表9-6），其中和从节点变动的事件有以下几个：
·+switch-master：切换主节点（原来的从节点晋升为主节点），说明减少了某个从节点。
·+convert-to-slave：切换从节点（原来的主节点降级为从节点），说明添加了某个从节点。
·+sdown：主观下线，说明可能某个从节点可能不可用（因为对从节点不会做客观下线），所以在实现客户端时可以采用自身策略来实现类似主观下线的功能。
·+reboot：重新启动了某个节点，如果它的角色是slave，那么说明添加了某个从节点。

所以在设计Redis Sentinel的从节点高可用时，只要能够实时掌握所有从节点的状态，把所有从节点看做一个资源池如下图所示，无论是上线还是下线从节点，客户端都能及时感知到（将其从资源池中添加或者删除），这样从节点的高可用目标就达到了。