Redis中的哨兵
# 130.Redis中的哨兵
Redis提供了哨兵工具来实现自动化的系统监控和故障恢复功能，本文简单介绍下哨兵
# 什么是哨兵
顾名思义，哨兵的作用就是监控Redis系统的运行状况。它的功能包括以下两个。
（1）监控主数据库和从数据库是否正常运行。
（2）主数据库出现故障时自动将从数据库转换为主数据库。
哨兵是一个独立的进程，使用哨兵的一个典型架构如图8-3所示。
图8-3 一个典型的使用哨兵的Redis 架构。虚线表示主从复制关系，实线表示哨兵的监控路径
在一个一主多从的Redis系统中，可以使用多个哨兵进行监控任务以保证系统足够稳健，如图所示。注意，此时不仅哨兵会同时监控主数据库和从数据库，哨兵之间也会互相监控。
# 马上上手
我们首先实际使用一下哨兵，来了解哨兵是如何工作的。为了简单期间，我们搭建一个主数据库和两个从数据库。主数据库的端口为6379，两个从数据库的端口分别为6380和6381。
# 一主二从
我们使用Redis命令行客户端来获取复制状态，以保证复制配置正确。首先是主数据库：
redis 6379> INFO replication
# Replication
role:master
connected_slaves:2
slave0:ip=127.0.0.1,port=6380,state=online,offset=10125,lag=0
slave1:ip=127.0.0.1,port=6381,state=online,offset=10125,lag=1
2
3
4
5
6
可见其连接了两个从数据库，配置正确。然后用同样的方法查看两个从数据库的配置：
redis 6380> INFO replication
# Replication
role:slave
master_host:127.0.0.1
master_port:6379
redis 6381> INFO replication
# Replication
role:slave
master_host:127.0.0.1
master_port:6379
2
3
4
5
6
7
8
9
10
11
当出现的信息如上时，即证明一主二从的复制配置已经成功了。
# 配置哨兵
接下来开始配置哨兵。建立一个配置文件，如sentinel.conf，内容为：
sentinel monitor mymaster 127.0.0.1 6379 1
其中mymaster表示要监控的主数据库的名字，可以自己定义一个。这个名字必须仅由大小写字母、数字和“.-_”这 3 个字符组成。后两个参数表示主数据库的地址和端口号，这里我们要监控的是主数据库6379。最后的1表示最低通过票数，后面会介绍。
接下来执行来启动Sentinel进程，并将上述配置文件的路径传递给哨兵：
$ redis-sentinel /path/to/sentinel.conf
需要注意的是，配置哨兵监控一个系统时，只需要配置其监控主数据库即可，哨兵会自动发现所有复制该主数据库的从数据库。启动哨兵后，哨兵输出如下内容：
[71835] 19 Feb 22:32:28.730 # Sentinel runid is
e3290844c1a404699479771846b716c7fc830e80
[71835] 19 Feb 22:32:28.730 # +monitor master mymaster 127.0.0.1 6379 quorum 1
[71835] 19 Feb 22:33:09.997 *+slave slave 127.0.0.1:6380 127.0.0.1 6380 @ mymaste@127.0.0.1 6379
[71835] 19 Feb 22:33:30.068 *+slave slave 127.0.0.1:6381 127.0.0.1 6381 @ mymaster
127.0.0.1 6379
2
3
4
5
6
其中+slave 表示新发现了从数据库，可见哨兵成功地发现了两个从数据库。现在哨兵已经在监控这3个Redis实例了
# 关闭主数据库
这时我们将主数据库（即运行在6379端口上的Redis实例）关闭（杀死进程或使用 SHUTDOWN 命令），等待指定时间后（默认为 30 秒，可以配置），哨兵会输出如下内容：
[71835] 19 Feb 22:36:03.780 # +sdown master mymaster 127.0.0.1 6379
[71835] 19 Feb 22:36:03.780 # +odown master mymaster 127.0.0.1 6379 #quorum 1/1
2
其中+sdown表示哨兵主观认为主数据库停止服务了，而+odown则表示哨兵客观认为主数据库停止服务了，关于主观和客观的区别后文会详细介绍。
此时哨兵开始执行故障恢复，即挑选一个从数据库，将其升格为主数据库。输出内容如下：
[71835] 19 Feb 22:36:03.780 # +try-failover master mymaster 127.0.0.1 6379
……
[71835] 19 Feb 22:36:05.913 # +failover-end master mymaster 127.0.0.1 6379
[71835] 19 Feb 22:36:05.913 # +switch-master mymaster 127.0.0.1 6379 127.0.0.1 6380
[71835] 19 Feb 22:36:05.914 *+slave slave 127.0.0.1:6381 127.0.0.1 6381 @ mymaster
127.0.0.1 6380
[71835] 19 Feb 22:36:05.914 *+slave slave 127.0.0.1:6379 127.0.0.1 6379 @ mymaster
127.0.0.1 6380
2
3
4
5
6
7
8
+try-failover表示哨兵开始进行故障恢复，+failover-end表示哨兵完成故障恢复，期间涉及的内容比较复杂，包括领头哨兵的选举、备选从数据库的选择等，放到后面介绍，此处只需要关注最后3条输出。+switch-master表示主数据库从6379端口迁移到6380端口，即6380端口的从数据库被升格为主数据库，同时两个+slave则列出了新的主数据库的两个从数据库，端口分别为6381和6379。其中6379就是之前停止服务的主数据库，可见哨兵并没有彻底清除停止服务的实例的信息，这是因为停止服务的实例有可能会在之后的某个时间恢复服务，这时哨兵会让其重新加入进来，所以当实例停止服务后，哨兵会更新该实例的信息，使得当其重新加入后可以按照当前信息继续对外提供服务。
此例中6379端口的主数据库实例停止服务了，而6380端口的从数据库已经升格为主数据库，当6379端口的实例恢复服务后，会转变为6380端口实例的从数据库来运行，所以哨兵将6379端口实例的信息修改成了6380端口实例的从数据库。
故障恢复完成后，可以使用Redis命令行客户端重新检查6380和6381两个端口上的实例的复制信息：
redis 6380> INFO replication
# Replication
role:master
connected_slaves:1
slave0:ip=127.0.0.1,port=6381,state=online,offset=270651,lag=1
redis 6381> INFO replication
# Replication
role:slave
master_host:127.0.0.1
master_port:6380
2
3
4
5
6
7
8
9
10
11
可以看到6380端口上的实例已经确实升格为主数据库了，同时6381端口上的实例是其从数据库。整个故障恢复过程就此完成。
# 启动旧的主数据库
那么此时我们将6379端口上的实例重新启动，会发生什么情况呢？首先哨兵会监控到这一变化，并输出：
[71835] 19 Feb 23:46:14.573 # -sdown slave 127.0.0.1:6379 127.0.0.1 6379 @ mymaster
127.0.0.1 6380
[71835] 19 Feb 23:46:24.504 *+convert-to-slave slave 127.0.0.1:6379 127.0.0.1 6379
@ mymaster 127.0.0.1 6380
2
3
4
-sdown表示实例6379已经恢复服务了（与+sdown相反），同时+convert-to-slave表示将6379端口的实例设置为6380端口实例的从数据库。
这时使用Redis命令行客户端查看6379端口实例的复制信息为：
redis 6379> INFO replication
# Replication
role:slave
master_host:127.0.0.1
master_port:6380
2
3
4
5
同时6380端口实例的复制信息为：
redis 6380> INFO replication
# Replication
role:master
connected_slaves:2
slave0:ip=127.0.0.1,port=6381,state=online,offset=292948,lag=1
slave1:ip=127.0.0.1,port=6379,state=online,offset=292948,lag=1
2
3
4
5
6
正如预期一样，6380端口实例的从数据库变为了两个，6379成功恢复服务。
# 哨兵的原理
一个哨兵进程启动时会读取配置文件的内容，通过如下的配置找出需要监控的主数据库：
sentinel monitor master-name ip redis-port quorum
其中：
- master-name 是一个由大小写字母、数字和“. - _”组成的主数据库的名字，因为考虑到故障恢复后当前监控的系统的主数据库的地址和端口会产生变化，所以哨兵提供了命令可以通过主数据库的名字获取当前系统的主数据库的地址和端口号。
- ip表示当前系统中主数据库的地址，而redis-port则表示端口号。
- quorum用来表示执行故障恢复操作前至少需要几个哨兵节点同意，一般是半数以上。
# 多个哨兵
哨兵以独立进程的方式对一个主从系统进行监控，监控的效果好坏与否取决于哨兵的视角是否有代表性。如果一个主从系统中配置的哨兵较少，哨兵对整个系统的判断的可靠性就会降低。
极端情况下，当只有一个哨兵时，哨兵本身就可能会发生单点故障。整体来讲，相对稳妥的哨兵部署方案是使得哨兵的视角尽可能地与每个节点的视角一致，即：
- 为每个节点（无论是主数据库还是从数据库）部署一个哨兵；
- 使每个哨兵与其对应的节点的网络环境相同或相近。
这样的部署方案可以保证哨兵的视角拥有较高的代表性和可靠性。举例一个例子：当网络分区后，如果哨兵认为某个分区是主要分区，即意味着从每个节点观察，该分区均为主分区。
同时设置 quorum 的值为 N/2 + 1（其中 N 为哨兵节点数量），这样使得只有当大部分哨兵节点同意后才会进行故障恢复。
