哨兵
在Reids的复制一文以介绍已经介绍了复制的原理和使用方式，在一个典型的一主多从的Redis系统中，从数据库在整个系统中起到了数据冗余备份和读写分离的作用。当主数据库遇到异常中断服务后，开发者可以通过手动的方式选择一个从数据库来升格为主数据库，以使得系统能够继续提供服务。然而整个过程相对麻烦且需要人工介入，难以实现自动化。
为此，Redis2.8中提供了哨兵工具来实现自动化的系统监控和故障恢复功能。
1、什么是哨兵
顾名思义，哨兵的作用就是监控Redis系统的运行状况。它的功能包括以下两个：
（1）监控主数据库和从数据库是否正常运行；
（2）主数据库出现故障时自动将从数据库转换为主数据库。
哨兵是一个独立的进程使用哨兵的一个典型架构如下图：
虚线表示主从复制关系，实线表示哨兵的监控路径
在一个一主多从的Redis系统中，可以使用多个哨兵进行监控任务以保证系统足够稳健，如下图。注意，此时不仅哨兵会同时监控主数据库和从数据库，哨兵之间也会互相监控。
2、上手实践
在理解哨兵的原理前，我们首先实际使用一下哨兵，来了解哨兵是如何工作的。建立起3个Redis实例，其中包括一个主数据库和两个从数据库。主数据库的端口为6379，两个从数据库的端口分别为6380和6381.我们使用Redis命令行客户端来获取复制状态，以保证复制配置正确。
首先是主数据库：
[root@VM-0-17-centos ~]# redis-cli -p 6379
127.0.0.1:6379> info replication
# Replication
role:master
connected_slaves:2
slave0:ip=127.0.0.1,port=6380,state=online,offset=112,lag=0
slave1:ip=127.0.0.1,port=6381,state=online,offset=112,lag=1
master_failover_state:no-failover
master_replid:3c9434b3a65e5801823b3342a12ae4ba8030e290
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:112
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:112
127.0.0.1:6379>可见其连接了两个从数据库，配置正确。然后查看两个从数据库
127.0.0.1:6380> info replication
# Replication
role:slave
master_host:127.0.0.1
master_port:6379
master_link_status:up
master_last_io_seconds_ago:1
master_sync_in_progress:0
slave_repl_offset:196
slave_priority:100
slave_read_only:1
replica_announced:1
connected_slaves:0
master_failover_state:no-failover
master_replid:3c9434b3a65e5801823b3342a12ae4ba8030e290
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:196
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:196
127.0.0.1:6380>127.0.0.1:6381> info replication
# Replication
role:slave
master_host:127.0.0.1
master_port:6379
master_link_status:up
master_last_io_seconds_ago:4
master_sync_in_progress:0
slave_repl_offset:196
slave_priority:100
slave_read_only:1
replica_announced:1
connected_slaves:0
master_failover_state:no-failover
master_replid:3c9434b3a65e5801823b3342a12ae4ba8030e290
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:196
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:196
127.0.0.1:6381>从信息中查看一主二从的复制配置已经成功了。
接下来开始配置哨兵。
建立一个配置文件，如sentinel.conf，内容为：
sentinel monitor mymaster 127.0.0.1 6379 1其中mymaster 表示要监控的主数据库的名字，可以自己定义一个。这个名字必须仅由大小写字母、数字和“.-_”这3个字符组成。后两个参数表示主数据库的地址和端口号，这里监控的是主数据库6379。最后的1表示最低通过票数，后面会介绍。
接下来启动Sentinel进程，并将上述配置文件的路径传递给哨兵：
[root@VM-0-17-centos to]# redis-sentinel /path/to/sentinel.conf需要注意的是，配置哨兵监控一个系统时，只需要配置其监控主数据库即可，哨兵会自动发现所有复制该主数据库的从数据库。
启动哨兵后，信息如下：
[root@VM-0-17-centos to]# redis-sentinel /path/to/sentinel.conf
25145:X 02 Jul 2021 22:59:43.276 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
25145:X 02 Jul 2021 22:59:43.276 # Redis version=6.2.4, bits=64, commit=00000000, modified=0, pid=25145, just started
25145:X 02 Jul 2021 22:59:43.276 # Configuration loaded
25145:X 02 Jul 2021 22:59:43.276 * monotonic clock: POSIX clock_gettime
_._
_.-``__ ''-._
_.-`` `. `_. ''-._ Redis 6.2.4 (00000000/0) 64 bit
.-`` .-```. ```\/ _.,_ ''-._
( ' , .-` | `, ) Running in sentinel mode
|`-._`-...-` __...-.``-._|'` _.-'| Port: 26379
| `-._ `._ / _.-' | PID: 25145
`-._ `-._ `-./ _.-' _.-'
|`-._`-._ `-.__.-' _.-'_.-'|
| `-._`-._ _.-'_.-' | https://redis.io
`-._ `-._`-.__.-'_.-' _.-'
|`-._`-._ `-.__.-' _.-'_.-'|
| `-._`-._ _.-'_.-' |
`-._ `-._`-.__.-'_.-' _.-'
`-._ `-.__.-' _.-'
`-._ _.-'
`-.__.-'
25145:X 02 Jul 2021 22:59:43.277 # WARNING: The TCP backlog setting of 511 cannot be enforced because /proc/sys/net/core/somaxconn is set to the lower value of 128.
25145:X 02 Jul 2021 22:59:43.320 # Sentinel ID is ef8aa14ebb2b540a03614026ad4ac4fdc5b9ac74
25145:X 02 Jul 2021 22:59:43.320 # +monitor master mymaster 127.0.0.1 6379 quorum 1
25145:X 02 Jul 2021 22:59:43.321 * +slave slave 127.0.0.1:6380 127.0.0.1 6380 @ mymaster 127.0.0.1 6379
25145:X 02 Jul 2021 22:59:43.354 * +slave slave 127.0.0.1:6381 127.0.0.1 6381 @ mymaster 127.0.0.1 6379其中 +slave 表示发现了从数据库，可见哨兵成功地发现了两个从数据库。现在哨兵已经在监控这3个实例了，这是我们将主数据库（即运行在6379端口上的redis实例）关闭，等待指定时间后（可以配置，默认是30秒），哨兵会输出以下内容：
25145:X 02 Jul 2021 23:15:35.052 # +sdown master mymaster 127.0.0.1 6379
25145:X 02 Jul 2021 23:15:35.052 # +odown master mymaster 127.0.0.1 6379 #quorum 1/1其中 +sdown表示哨兵主观认为主数据库停止服务了，而+odown则表示哨兵客观认为主数据库停止服务了，关于主观和客观后面详细介绍。此时哨兵开始执行故障恢复，即挑选一个从数据库，将其升格为主数据库，同时输出以下内容：
25145:X 02 Jul 2021 23:15:35.052 # +try-failover master mymaster 127.0.0.1 6379
25145:X 02 Jul 2021 23:15:35.087 # +vote-for-leader ef8aa14ebb2b540a03614026ad4ac4fdc5b9ac74 1
25145:X 02 Jul 2021 23:15:35.087 # +elected-leader master mymaster 127.0.0.1 6379
25145:X 02 Jul 2021 23:15:35.087 # +failover-state-select-slave master mymaster 127.0.0.1 6379
25145:X 02 Jul 2021 23:15:35.151 # +selected-slave slave 127.0.0.1:6380 127.0.0.1 6380 @ mymaster 127.0.0.1 6379
25145:X 02 Jul 2021 23:15:35.151 * +failover-state-send-slaveof-noone slave 127.0.0.1:6380 127.0.0.1 6380 @ mymaster 127.0.0.1 6379
25145:X 02 Jul 2021 23:15:35.216 * +failover-state-wait-promotion slave 127.0.0.1:6380 127.0.0.1 6380 @ mymaster 127.0.0.1 6379
25145:X 02 Jul 2021 23:15:35.434 # +promoted-slave slave 127.0.0.1:6380 127.0.0.1 6380 @ mymaster 127.0.0.1 6379
25145:X 02 Jul 2021 23:15:35.434 # +failover-state-reconf-slaves master mymaster 127.0.0.1 6379
25145:X 02 Jul 2021 23:15:35.491 * +slave-reconf-sent slave 127.0.0.1:6381 127.0.0.1 6381 @ mymaster 127.0.0.1 6379
25145:X 02 Jul 2021 23:15:36.482 * +slave-reconf-inprog slave 127.0.0.1:6381 127.0.0.1 6381 @ mymaster 127.0.0.1 6379
25145:X 02 Jul 2021 23:15:36.482 * +slave-reconf-done slave 127.0.0.1:6381 127.0.0.1 6381 @ mymaster 127.0.0.1 6379
25145:X 02 Jul 2021 23:15:36.593 # +failover-end master mymaster 127.0.0.1 6379
25145:X 02 Jul 2021 23:15:36.593 # +switch-master mymaster 127.0.0.1 6379 127.0.0.1 6380
25145:X 02 Jul 2021 23:15:36.593 * +slave slave 127.0.0.1:6381 127.0.0.1 6381 @ mymaster 127.0.0.1 6380
25145:X 02 Jul 2021 23:15:36.593 * +slave slave 127.0.0.1:6379 127.0.0.1 6379 @ mymaster 127.0.0.1 6380
25145:X 02 Jul 2021 23:16:06.628 # +sdown slave 127.0.0.1:6379 127.0.0.1 6379 @ mymaster 127.0.0.1 6380+try-failover表示哨兵开始进行故障恢复，+failover-end表示哨兵完成故障恢复，期间涉及的内容比较复杂，包括领头哨兵的选举、备选从数据库的选择等，后面介绍。+switch-master表示主数据库从6379端口迁移到6380端口，即6380端口的从数据库被升格为主数据库，同时两个+slave则列出了新的主数据库的两个从数据库，端口分别为6381和6379.其中6379就是之前停止服务的主数据库，可见哨兵并没有彻底消除停止服务的实例的信息，这是因为停止服务的实例有可能会在之后的某个时间恢复服务，这时哨兵会让其重新加入进来，所以当实例停止服务后，哨兵会更新该实例的信息，使得当其重新加入后可以按照当前信息继续对外提供服务。此例中6379端口的主数据库实例停止服务了，而6380端口的从数据库已经升格为主数据库，当6379端口的实例恢复服务后，会转变为6380端口实例的从数据库来运行，所以哨兵将6379端口实例的信息修改成了6380端口实例的从数据库。
故障恢复完成后，可以使用Redis命令行客户端重新检查6380和6381两个端口上的实例的复制信息：
127.0.0.1:6380> info replication
# Replication
role:master
connected_slaves:1
slave0:ip=127.0.0.1,port=6381,state=online,offset=113726,lag=1
master_failover_state:no-failover
master_replid:c170c67ae55f9d5f2405d0024f46af7952bf8454
master_replid2:3c9434b3a65e5801823b3342a12ae4ba8030e290
master_repl_offset:113859
second_repl_offset:61995
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:113859
127.0.0.1:6380>127.0.0.1:6381> info replication
# Replication
role:slave
master_host:127.0.0.1
master_port:6380
master_link_status:up
master_last_io_seconds_ago:1
master_sync_in_progress:0
slave_repl_offset:114125
slave_priority:100
slave_read_only:1
replica_announced:1
connected_slaves:0
master_failover_state:no-failover
master_replid:c170c67ae55f9d5f2405d0024f46af7952bf8454
master_replid2:3c9434b3a65e5801823b3342a12ae4ba8030e290
master_repl_offset:114125
second_repl_offset:61995
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:114125
127.0.0.1:6381>可以看到6380端口上的实例已经确实升格为主数据库了，同时6381端上的实例是其从数据库。整个故障恢复过程就此完成。
此时将6379端口上的实例重新启动，哨兵会监测到这一变化，并输出：
25145:X 02 Jul 2021 23:31:12.915 # -sdown slave 127.0.0.1:6379 127.0.0.1 6379 @ mymaster 127.0.0.1 6380
25145:X 02 Jul 2021 23:31:22.931 * +convert-to-slave slave 127.0.0.1:6379 127.0.0.1 6379 @ mymaster 127.0.0.1 6380-sdown表示实例6379已经恢复服务了（与 +sdown相反），同时 +convert-to-slave表示将6379端口的实例设置为6380端口实例的从数据库。
这时查看6379端口实例的复制信息为：
[root@VM-0-17-centos ~]# redis-cli -p 6379
127.0.0.1:6379> info replication
# Replication
role:slave
master_host:127.0.0.1
master_port:6380
master_link_status:up
master_last_io_seconds_ago:1
master_sync_in_progress:0
slave_repl_offset:138578
slave_priority:100
slave_read_only:1
replica_announced:1
connected_slaves:0
master_failover_state:no-failover
master_replid:c170c67ae55f9d5f2405d0024f46af7952bf8454
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:138578
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:124990
repl_backlog_histlen:13589
127.0.0.1:6379>同时6380端口实例的复制信息为：
127.0.0.1:6380> info replication
# Replication
role:master
connected_slaves:2
slave0:ip=127.0.0.1,port=6381,state=online,offset=141840,lag=0
slave1:ip=127.0.0.1,port=6379,state=online,offset=141840,lag=0
master_failover_state:no-failover
master_replid:c170c67ae55f9d5f2405d0024f46af7952bf8454
master_replid2:3c9434b3a65e5801823b3342a12ae4ba8030e290
master_repl_offset:141840
second_repl_offset:61995
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:141840
127.0.0.1:6380>正如预期一样，6380端口实例的从数据库变为了两个，6379成功恢复服务。
3、实现原理
一个哨兵进程启动时会读取配置文件的内容，通过如下的配置找出需要监控的主数据库：
sentinel monitor master-name ip redis-port quorum其中master-name是一个由大小写字母、数字和“.-_”组成的主数据库的名字，因为考虑到故障恢复后当前监控的系统的主数据库的地址和端口会产生变化，所以哨兵提供了命令可以通过主数据库的名字获取当前系统的主数据库的地址和端口号。
ip表示当前系统中主数据库的地址，而redis-port则表示端口号。
quorum用来表示执行故障恢复操作前至少需要几个哨兵节点同意，后文详细介绍。
一个哨兵节点可以同时监控多个Redis主从系统，只需要提供多个sentinel monitor配置即可，如：
sentinel monitor mymaster 127.0.0.1 6379 2
sentinel monitor othermaster 192.168.6.1 6380 4同时多个哨兵节点也可以同时监控同一个Redis主从系统，从而形成网状结构。
配置文件中还可以定义其他监控相关的参数，每个配置选项都包含主数据库的名字使得监控不同主数据库时可以使用不同的配置参数，如：
sentinel down-after-milliseconds mymaster 60000
sentinel down-after-milliseconds othermaster 10000上面的两行配置分别配置了mymaster和othermaster的down-after-milliseconds选项分别为60000和10000.
哨兵启动后，会与要监控的主数据库建立两条连接，这两个链接的建立方式与普通的Redis客户端无异。其中一条连接用来订阅该主数据库的 _sentinel _:hello 频道以获取其他同样监控该数据库的哨兵节点信息，另外哨兵也需要定期向主数据库发送 INFO 等命令来获取主数据库本身的信息。
和主数据库的连接建立完成后，哨兵会定时执行下面3个操作：
（1）每10秒哨兵会向主数据库和从数据库发送INFO命令。
（2）每2秒哨兵会向主数据库和从数据库的 _sentinel _:hello频道发送子的信息。
（3）每1秒哨兵会向主数据库、从数据库和其他哨兵节点发送 PING 命令。
这3个操作贯穿哨兵进程的整个生命周期中。
下面详细介绍：
首先，发送 INFO 命令使得哨兵可以获取当先数据库的相关信息（包括运行ID、复制信息等）从而实现新节点的自动发现。前面说配置哨兵监控Redis主从系统时，只需要指定主数据库的信息即可，因为哨兵正是借助INFO命令来获取所有复制该主数据库的从数据库信息的。启动后，哨兵向主数据库发送INFO命令，通过解析返回结果来得知从数据库列表，而后对每个从数据库同样建立两个链接，两个链接的作用和前文介绍的与主数据库建立的两个链接完全一致。在此之后，哨兵会每10秒定时向已知的所有主从数据库发送INFO命令来获取信息更新并进行相应操作，比如对新增的从数据库建立连接并加入监控列表，对主从数据库的角色变化（由故障恢复引起的）进行信息更新等。
接下来，哨兵会向从数据库的 _sentinel _:hello频道发送信息来与同样监控该数据库的哨兵分享自己的信息。发送消息内容为：
<哨兵的地址>，<哨兵的端口>，<哨兵的运行ID>，<哨兵的配置版本>，<主数据库的名字>，<主数据库的地址>，<主数据库的端口>，<主数据库的配置版本>可以看到消息包括哨兵的基本信息，以及其监控的主数据库的信息。前文介绍过，哨兵会订阅每个其监控的数据库的 _sentinel _:hello 频道，所以当其他哨兵收到消息后，会判断发消息的哨兵是不是新发现的哨兵。如果是则将其加入到已发现的哨兵列表中并创建一个到其的连接（与数据库不同，哨兵与哨兵之间只会创建一条连接用来发送 PING 命令，而不需要创建另外一条连接来订阅频道，因为哨兵只需要订阅数据库的频道即可实现自动发现其他哨兵）。同时哨兵会判断信息中主数据库的配置版本，如果该版本比当前记录的主数据库的版本高，则更新主数据库的数据。
实现了自动发现从数据库和其他哨兵节点后，哨兵要做的就是监控这些数据库和节点有没有停止服务。这是通过每隔一定时间向这些节点发送 PING 命令来实现的。时间间隔与 down-after-milliseconds 选项有关，当 down-after-milliseconds 的值小于1秒时，哨兵会每隔 down-after-milliseconds 指定的时间发送一次 PING 命令，当 down-after-milliseconds 的值大于1秒时，哨兵会每隔1秒发送一次 PING 命令。如：
//每隔1秒发送一次PING命令
sentinel down-after-milliseconds mymaster 60000
//每隔600毫秒发送一次PING命令
sentinel down-after-milliseconds othermaster 600当超过 down-after-milliseconds 选项指定的时间后，如果被 PING 的数据库或节点仍然未进行回复，则哨兵认为其主观下线（subjectively down）。主观下线表示从当前的哨兵进程来看，该节点已经下线。如果该节点是主数据库，则哨兵会进一步判断是否需要对其进行故障恢复：哨兵发送 SENTINEL is-master-down-by-addr 命令询问其他哨兵节点以了解它们是否也认为该主数据库主观下线，如果达到指定数量时，哨兵会认为其客观下线（objectively down），并选举领头的哨兵节点对主从系统发起故障恢复，这个指定数量即为前文介绍的 quorum 参数。如下面的配置：
sentinel monitor mymaster 127.0.0.1 6379 2该配置表示只有当至少两个Sentinel节点（包括当前节点）认为该主数据库主观下线时，当前哨兵节点才会认为该主数据库客观下线。进行接下来的选举领头哨兵步骤。
虽然当前哨兵节点发现了主数据库客观下线，需要故障恢复，但是故障恢复需要领头的哨兵节点来完成，这样可以保证同一时间只有一个哨兵节点来执行故障恢复。选举领头哨兵的过程使用了 Raft 算法，具体过程如下：
（1）发现主数据库客观下线的哨兵节点（下面称作A）向每个哨兵节点发送命令，要求对方选自己成为领头哨兵；
（2）如果目标哨兵节点没有选过其他节点，则会同意将A设置为领头哨兵；
（3）如果A发现有超过半数且超过 quorum 参数值的哨兵节点同意选自己成为领头哨兵，则A成为领头哨兵；
（4）当有多个哨兵节点同时参选领头哨兵，则会出现没有任何节点当选的可能。此时每个参选节点将等待一个随机时间重新发起参选请求，进行下一轮选举，直到选举成功。
选出领头哨兵后，领头哨兵将会开始对主数据库进行故障恢复。故障恢复过程如下：
首先领头哨兵将从停止服务的主数据库的从数据库中挑选一个来充当新的主数据库，挑选依据如下：
（1）所有在线的从数据库中，选择优先级最高的从数据库。优先级可以通过 slave-priority 选项来配置；
（2）如果有多个最高优先级的从数据库，则复制的命令偏移量越大（即复制越完整）越优先；
（3）如果以上条件都一样，则选择运行ID较小的从数据库。
选出一个从数据库后，领头哨兵将向从数据库发送 SLAVEOF NO ONE 命令使其升格为主数据库。而后领头哨兵向其他从数据库发送 SLAVEOF命令来使其成为新主数据库的从数据库。最后一步则是更新内部的记录，将已经停止服务的旧的主数据库更新为新的主数据库的从数据库，使得当其恢复服务后自动以从数据库的身份继续服务。
4、哨兵的部署
相对稳妥的哨兵部署方案是使得哨兵的视角尽可能的与每个节点的视角一直，即：
（1）为每个节点（无论是主数据库还是从数据库）部署一个哨兵；
（2）使每个哨兵与其对应节点的网络环境相同或相近。
这样的部署方案可以保证哨兵的视角拥有较高的代表性和可靠性。
同时设置 quorum 的值为 N/2 + 1（其中N为哨兵节点数量），这样使得只有当大部分哨兵节点同意后才进行故障恢复。
author：su1573
鄙人记录生活点滴，学习并分享，请多指教！！！
