Redis核心技术-高可靠-哨兵机制详解（监控、选Master、通知）

前言

  主从复制为了解决主库读压力（包括QPS、网络流量等），如果master宕机了，slave还可以提供读操作，写操作则不行。

  如何保证master宕机后，Redis可以继续提供服务呢？

  当然是Redis的哨兵机制。

哨兵机制

  哨兵其实是Redis运行在特殊模式下的进程（主从库都存在）。哨兵负责监控、选master、通知。

  Redis2.6+ 的版本中包含哨兵， 到了 2.8 版本之后就稳定了下来。

哨兵机制如何运行

哨兵工作主要是监控、选master和通知slave和client。

1. 监控

  监控指的是哨兵周期性向所有master和slave发送ping命令（心跳），master和slave则在规定时间内返回pong命令。

  如果slave没返回pong命令，标记为下线状态（从库下线对集群影响不是很大）；

  如果master没返回pong命令，标记为下线状态，并且启动选master流程。注意此时紧是当前哨兵认为master下线（一般发生在集群网络压力大，网络拥堵，master压力大的情况），master不一定是下线，还需要后面选master流程确认。

哨兵如何知道其他哨兵的ip和端口？

  使用pub/sub机制。哨兵与master连接后发布连接信息（ip和端口号），并且订阅信息，从而实现发现其他哨兵连接信息。

  信息频道为__sentinel__:hello

哨兵如何知道slave的ip和端口？

  前面说到哨兵需要向master和slave发送ping命令，并且sentinel monitor配置只配置了master ip和地址，那么slave如何获取其他slave的ip和端口呢？

  哨兵向master发送INFO命令获取slave列表。哨兵根据slave列表中的连接信息与slave进行连接，持续监控slave运行情况。

2. 选master流程

  选master流程分为2大步：
1.确认master是否下线
2.按照一定的规则选取新的master

2.1.确认master是否下线

  单个哨兵认为master下线是不可靠的，需要经过其他哨兵也认为master下线才能执行后面选master操作。

  Redis中所有的哨兵组成哨兵集群，确认master下线需要N个哨兵（N=哨兵数量/2+1，N也可以由管理员设定，即quorum）投票认为master下线。（认为master下线的哨兵发起投票，其他哨兵判断master是否下线返回Y/N）

2.2.选取新master

由于每个slave内存、复制进度、网络情况可能不一样，不是所有的slave都可以成为master候选者。

1.筛选master候选者，已下线slave、网络不稳定slave不能成为候选者。

网络不稳定：down-after-milliseconds配置是master和slave断连超时毫秒，如果断连次数超过10次，认为网络不稳定。

2.候选者评分，候选者评分有3个规则：

1. slave优先级（slave-priority配置）

2. slave同步进度，和master同步进度越高，数据保存越接近master。master使用master_repl_offset记录写操作在repl_backlog_buffer中的位置，slave使用slave_repl_offset记录同步进度。

3. slave Id号，Id号越小的评分越高。

只要其中一个规则中某个slave评分最高，那么它就成为新master，选master流程结束。

选master由那个哨兵执行呢？

  确认master下线时由主观认为master下线的哨兵发起投票，如果投票结束后由那个哨兵执行选master的操作呢？

  投票选取，任何一个哨兵可以向其他哨兵发起投票成为leader。

  哨兵只有获取到其他哨兵半数以上同意的投票即可成为leader（哨兵会给自己投一票），执行选master、通知等操作。

  如果只有两个哨兵呢？这是需要拿到2票才能成为leader。

3.通知

  通知发送在新master产生后，目的在于哨兵把新master信息连接信息发送给其他slave，让其他slave执行replicaof命令、和新master建立连接、进行数据复制。

  同时哨兵把新master信息发送给client，让client和新master连接、把请求操作发到新master。

哨兵如何通知client？

  从本质上说，哨兵就是一个运行在特定模式下的 Redis 实例，只不过它并不服务请求操作，只是完成监控、选主和通知的任务。所以，每个哨兵实例也提供 pub/sub 机制，客户端可以从哨兵订阅消息。哨兵提供的消息订阅频道有很多，不同频道包含了主从库切换过程中的不同关键事件。

  client通过读取配置获取哨兵ip和端口号，从而与哨兵进行连接。连接后订阅相关的频道获取主从切换、切换进度、新master地址等信息。

  常见的事件如下：

频道	描述	事件
+sdown	当前哨兵认为master下线（主观下线）	master下线
-sdown	当前哨兵取消master下线	master下线
+odown	哨兵集群认为master下线（客观下线）	master下线
-odown	哨兵集群退出master下线	master下线
+slave-reconf-sent	哨兵发送SLAVEOF命令重新配置从库	slave重新配置
+slave-reconf-inprog	slave配置了新master，尚未进行同步	slave重新配置
+slave-reconf-done	slave配置了新master，并且与master同步完成
+switch-master	master地址发送变化	新master切换

哨兵模式配置

  哨兵的配置在sentinel.conf文件。

# 哨兵sentinel实例运行的端口 默认26379
port 26379

# 哨兵sentinel的工作目录
dir /tmp

# 哨兵sentinel监控的redis主节点的 ip port
# master-name 可以自己命名的主节点名字 只能由字母A-z、数字0-9 、这三个字符".-_"组成。
# quorum 当这些quorum个数sentinel哨兵认为master主节点失联 那么这时 客观上认为主节点失联了
# sentinel monitor <master-name> <ip> <redis-port> <quorum>
sentinel monitor mymaster 127.0.0.1 6379 2

# 当在Redis实例中开启了requirepass foobared 授权密码 这样所有连接Redis实例的客户端都要提供密码
# 设置哨兵sentinel 连接主从的密码 注意必须为主从设置一样的验证密码
# sentinel auth-pass <master-name> <password>
sentinel auth-pass mymaster MySUPER--secret-0123passw0rd

# 指定多少毫秒之后 主节点没有应答哨兵sentinel 此时 哨兵主观上认为主节点下线 默认30秒
# sentinel down-after-milliseconds <master-name> <milliseconds>
sentinel down-after-milliseconds mymaster 30000

# 这个配置项指定了在发生failover主备切换时最多可以有多少个slave同时对新的master进行同步，
# 这个数字越小，完成failover所需的时间就越长，
# 但是如果这个数字越大，就意味着越 多的slave因为replication而不可用。
# 可以通过将这个值设为 1 来保证每次只有一个slave 处于不能处理命令请求的状态。
# sentinel parallel-syncs <master-name> <numslaves>
sentinel parallel-syncs mymaster 1

# 故障转移的超时时间 failover-timeout 可以用在以下这些方面：
#1. 同一个sentinel对同一个master两次failover之间的间隔时间。
#2. 当一个slave从一个错误的master那里同步数据开始计算时间。直到slave被纠正为向正确的master那里同步数据时。
#3.当想要取消一个正在进行的failover所需要的时间。
#4.当进行failover时，配置所有slaves指向新的master所需的最大时间。不过，即使过了这个超时，slaves依然会被正确配置为指向master，但是就不按parallel-syncs所配置的规则来了
# 默认三分钟
# sentinel failover-timeout <master-name> <milliseconds>
sentinel failover-timeout mymaster 180000

# SCRIPTS EXECUTION
#配置当某一事件发生时所需要执行的脚本，可以通过脚本来通知管理员，例如当系统运行不正常时发邮件通知相关人员。
#对于脚本的运行结果有以下规则：
#若脚本执行后返回1，那么该脚本稍后将会被再次执行，重复次数目前默认为10
#若脚本执行后返回2，或者比2更高的一个返回值，脚本将不会重复执行。
#如果脚本在执行过程中由于收到系统中断信号被终止了，则同返回值为1时的行为相同。
#一个脚本的最大执行时间为60s，如果超过这个时间，脚本将会被一个SIGKILL信号终止，之后重新执行。

#通知型脚本:当sentinel有任何警告级别的事件发生时（比如说redis实例的主观失效和客观失效等等），将会去调用这个脚本，这时这个脚本应该通过邮件，SMS等方式去通知系统管理员关于系统不正常运行的信息。调用该脚本时，将传给脚本两个参数，一个是事件的类型，一个是事件的描述。
#如果sentinel.conf配置文件中配置了这个脚本路径，那么必须保证这个脚本存在于这个路径，并且是可执行的，否则sentinel无法正常启动成功。
#通知脚本
# sentinel notification-script <master-name> <script-path>
sentinel notification-script mymaster /var/redis/notify.sh

# 客户端重新配置主节点参数脚本
# 当一个master由于failover而发生改变时，这个脚本将会被调用，通知相关的客户端关于master地址已经发生改变的信息。
# 以下参数将会在调用脚本时传给客户端:
# <master-name> <role> <state> <from-ip> <from-port> <to-ip> <to-port>
# 目前<state>总是“failover”,
# <role>是“leader”或者“observer”中的一个。
# 参数 from-ip, from-port, to-ip, to-port是用来和旧的master和新的master(即旧的slave)通信的
# 这个脚本应该是通用的，能被多次调用，不是针对性的。
# sentinel client-reconfig-script <master-name> <script-path>
sentinel client-reconfig-script mymaster /var/redis/reconfig.sh

哨兵启动

./redis-sentinel sentinel.conf

如果哨兵挂了会怎么样？

  多个哨兵组成哨兵集群，如果哨兵挂了，还是能够完成主从切换功能。

参考：
https://blog.csdn.net/qq_36324113/article/details/90481273
https://zhuanlan.zhihu.com/p/387630094