Redis入门指南 --day007-优快云博客

本文链接：https://blog.youkuaiyun.com/he_yanghui/article/details/120130590

集群

**
复制
通过持久化功能，Redis保证了即使在服务器重启的情况下也不会损失（或少量损失)数据。但是由于数据是存储在一台服务器上的，如果这台服务器出现硬盘故障等问题，也会导致数据丢失。为了避免单点故障，通常的做法是将数据库复制多个副本以部署在不同的服务器上，这样即使有一台服务器出现故障,其他服务器依然可以继续提供服务。为此,Redis提供了复制（replication）功能，可以实现当一台数据库中的数据更新后，自动将更新的数据同步到其他数据库上。
配置
在复制的概念中，数据库分为两类，一类是主数据库（master)，另一类是从数据库(slave)。主数据库可以进行读写操作，当写操作导致数据变化时会自动将数据同步给从数据库。而从数据库一般是只读的，并接受主数据库同步过来的数据。一个主数据库可以拥有多个从数据库，而一个从数据库只能拥有一个主数据库，如图8-1所示。
在这里插入图片描述

在 Redis中使用复制功能非常容易，只需要在从数据库的配置文件中加入“slaveof主数据库地址主数据库端口”即可，主数据库无需进行任何配置。
为了能够更直观地展示复制的流程，下面将实现一个最简化的复制系统。我们要在一台服务器上启动两个 Redis实例，监听不同端口，其中一个作为主数据库，另一个作为从数据库。首先我们不加任何参数来启动一个Redis实例作为主数据库:

$redis-server
# 该实例默认监听6379端口。然后加上slaveof参数启动另一个 Redis实例作为从数据库，并让其监听6380端口:
$ redis-server --port 6380 --slaveof 127.0.0.1 6379   
# 此时在主数据库中的任何数据变化都会自动地同步到从数据库中。我们打开redis-cli实例A并连接到主数据库:
$redis-cli -p 6379
再打开redis-cli 实例B并连接到从数据库:
$ redis-cli -p6380

# 首先打开A redis服务端 看日志，从机已经连到主机
[14432] 04 Sep 17:28:50.337 * Background saving terminated with success
[14432] 04 Sep 17:28:50.340 * Synchronization with slave 127.0.0.1:6380 succeeded
# 再打开 B redis 服务端
[19108] 04 Sep 17:28:50.340 * MASTER <-> SLAVE sync: receiving 34000 bytes from master
[19108] 04 Sep 17:28:50.342 * MASTER <-> SLAVE sync: Flushing old data
[19108] 04 Sep 17:28:50.342 * MASTER <-> SLAVE sync: Loading DB in memory

[19108] 04 Sep 17:28:50.345 * MASTER <-> SLAVE sync: Finished with success
 
 # 这时我们使用INFO命令来分别在实例6379和实例6380中获取 Replication节的相关信息:
127.0.0.1:6379> info replication
# Replication
role:master
connected_slaves:1
slave0:ip=127.0.0.1,port=6380,state=online,offset=547,lag=0
master_repl_offset:547
repl_backlog_active:1

repl_backlog_size:1048576
repl_backlog_first_byte_offset:2
repl_backlog_histlen:546
127.0.0.1:6379>    
# 可以看到，实例6379 的角色(上面输出中的role）是master，即主数据库，同时已连接的从数据库
# （上面输出中的connected_ slaves)的个数为1。

F:\redis>redis-cli -p 6380
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:4
master_sync_in_progress:0
slave_repl_offset:715
slave_priority:100
slave_read_only:1
connected_slaves:0
master_repl_offset:0
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0
127.0.0.1:6380>
# 这里可以看到，实例6380 的role是 slave，即从数据库，同时其主数据库的地址为127.0.0.1，端口为6379。
# 6379 输入
127.0.0.1:6379> set foo bababa
OK
127.0.0.1:6379> get foo
"bababa"

# 6380 也能获取到数据
127.0.0.1:6380> get foo
"bababa"
127.0.0.1:6380> set foo lalala  #我们修改数据  发现是只读的
(error) READONLY You can't write against a read only slave.

从数据库默认是只读的，可以通过设置从数据库的配置文件中的 slave-read-only为no以使从数据库可写，但是因为对从数据库的任何更改都不会同步给任何其他数据库，并且一旦主数据库中更新了对应的数据就会覆盖从数据库中的改动，所以通常的场景下不应该设置从数据库可写，以免导致易被忽略的潜在应用逻辑错误。
配置多台从数据库的方法也一样，在所有的从数据库的配置文件中都加上slaveof参数指向同一个主数据库即可。

# 除了通过配置文件或命令行参数设置slaveof参数，还可以在运行时使用SLAVEOF命令修改:
redis> SLAVEOF 127.0.0.16379 
# 如果该数据库已经是其他主数据库的从数据库了，SLAVEOF命令会停止和原来数据库的同步转而和新数据库同步
# 此外对于从数据库来说，还可以使用SLAVEOF NO ONE命令来使当前数据库停止接收其他数据库的同步并
# 转换成为主数据库。

原理
redis 实现复制的过程：
当一个从数据库启动后，会向主数据库发送SYNC命令。同时主数据库接收到SYNC命令后会开始在后台保存快照（即RDB持久化的过程)，并将保存快照期间接收到的命令缓存起来。当快照完成后,Redis 会将快照文件和所有缓存的命令发送给从数据库。从数据库收到后,会载入快照文件并执行收到的缓存的命令。以上过程称为复制初始化。复制初始化结束后，主数据库每当收到写命令时就会将命令同步给从数据库，从而保证主从数据库数据一致。
当主从数据库之间的连接断开重连后，Redis 2.6 以及之前的版本会重新进行复制初始化(即主数据库重新保存快照并传送给从数据库),即使从数据库可以仅有几条命令没有收到，主数据库也必须要将数据库里的所有数据重新传送给从数据库。这使得主从数据库断线重连后的数据恢复过程效率很低下，在网络环境不好的时候这一问题尤其明显。Redis 2.8版的一个重要改进就是断线重连能够支持有条件的增量数据传输，当从数据库重新连接上主数据库后，主数据库只需要将断线期间执行的命令传送给从数据库，从而大大提高Redis复制的实用性。

乐观复制： Redis 采用了乐观复制（ optimistic replication）的复制策略，容忍在一定时间内主从数据库的内容是不同的，但是两者的数据会最终同步。具体来说，Redis在主从数据库之间复制数据的过程本身是异步的，这意味着，主数据库执行完客户端请求的命令后会立即将命令在主数据库的执行结果返回给客户端，并异步地将命令同步给从数据库，而不会等待从数据库接收到该命令后再返回给客户端。这一特性保证了启用复制后主数据库的性能不会受到影响，但另一方面也会产生一个主从数据库数据不一致的时间窗口,当主数据库执行了一条写命令后，主数据库的数据已经发生的变动,
然而在主数据库将该命令传送给从数据库之前，如果两个数据库之间的网络连接断开了，此时二者之间的数据就会是不一致的。从这个角度来看，主数据库是无法得知某个命令最终同步给了多少个从数据库的，不过 Redis提供了两个配置选项来限制只有当数据至少同步给指定数量的从数据库时,主数据库才是可写的:

min-slaves-to-write 3
min-slaves-max-lag 10

上面的配置中, min-slaves-to-write表示只有当3个或3个以上的从数据库连接到主数据库时,主数据库才是可写的,否则会返回错误
min-slaves-max-lag表示允许从数据库最长失去连接的时间，如果从数据库最后与主数据库联系（即发送REPLCONF ACK命令）的时间小于这个值，则认为从数据库还在保持与主数据库的连接。举个例子，按上面的配置，主数据库假设与3个从数据库相连,其中一个从数据库上一次与主数据库联系是9秒前，这时主数据库可以正常接受写入,一旦1秒过后这台从数据库依旧没有活动,则主数据库则认为目前连接的从数据库只有2个，从而拒绝写入。这一特性默认是关闭的，在分布式系统中，打开并合理配置该选项后可以降低主从架构中因为网络分区导致的数据不一致的问题。

图结构

从数据库不仅可以接收主数据库的同步数据，自己也可以同时作为主数据库存在，形成类似图的结构，如图8-2所示，数据库A的数据会同步到B和C中，而B中的数据会同步到D和E中。向B中写入数据不会同步到A或C中，只会同步到D和E中。
在这里插入图片描述

读写分离与一致性：
通过复制可以实现读写分离，以提高服务器的负载能力。在常见的场景中（如电子商务网站)，读的频率大于写，当单机的Redis无法应付大量的读请求时(尤其是较耗资源的请求，如SORT 命令等）可以通过复制功能建立多个从数据库节点，主数据库只进行写操作，而从数据库负责读操作。这种一主多从的结构很适合读多写少的场景，而当单个的主数据库不能够满足需求时，就需要使用Redis 3.0推出的集群功能

从数据库持久化：
另一个相对耗时的操作是持久化，为了提高性能，可以通过复制功能建立一个(或若千个)从数据库，并在从数据库中启用持久化，同时在主数据库禁用持久化。当从数据库崩溃重启后主数据库会自动将数据同步过来，所以无需担心数据丢失。
然而当主数据库崩溃时，情况就稍显复杂了。手工通过从数据库数据恢复主数据库数据时,需要严格按照以下两步进行。
(1）在从数据库中使用 SLAVEOF NO ONE命令将从数据库提升成主数据库继续服务。
(2) 启动之前崩溃的主数据库，然后使用SLAVEOF命令将其设置成新的主数据库的从数据库,即可将数据同步回来。
无论哪种情况，手工维护从数据库或主数据库的重启以及数据恢复都相对麻烦，好在Redis提供了一种自动化方案哨兵来实现这一过程,避免了手工维护的麻烦和容易出错的问题
无硬盘复制：
因此从2.8.18版本开始，Redis 引入了无硬盘复制选项，开启该选项时，Redis在与从数据库进行复制初始化时将不会将快照内容存储到硬盘上，而是直接通过网络发送给从数据库,避免了硬盘的性能瓶颈。
目前无硬盘复制的功能还在试验阶段,可以在配置文件中使用如下配置来开启该功能:
repl-diskless-sync yes
增量复制
增量复制是基于如下3点实现的。
(1）从数据库会存储主数据库的运行ID（run id)。每个 Redis运行实例均会拥有一个唯一的运行ID,每当实例重启后，就会自动生成一个新的运行ID。
(2）在复制同步阶段，主数据库每将一个命令传送给从数据库时，都会同时把该命令存放到一个积压队列（backlog)中，并记录下当前积压队列中存放的命令的偏移量范围。
(3）同时，从数据库接收到主数据库传来的命令时，会记录下该命令的偏移量。
这3点是实现增量复制的基础，当主从连接准备就绪后，从数据库会发送一条SYNC命令来告诉主数据库可以开始把所有数据同步过来了。而2.8版之后，不再发送SYNC命令，取而代之的是发送 PSYNC，格式为“PSYNC主数据库的运行ID 断开前最新的命令偏移量”。主数据库收到PSYNC命令后，会执行以下判断来决定此次重连是否可以执行增量复制。
(1）首先主数据库会判断从数据库传送来的运行ID是否和自己的运行ID相同。这一步骤的意义在于确保从数据库之前确实是和自己同步的,以免从数据库拿到错误的数据(比
如主数据库在断线期间重启过,会造成数据的不一致)。
(2）然后判断从数据库最后同步成功的命令偏移量是否在积压队列中，如果在则可以执行增量复制，并将积压队列中相应的命令发送给从数据库。

大部分情况下，增量复制的过程对开发者来说是完全透明的，开发者不需要关心增量复制的具体细节。2.8版本的主数据库也可以正常地和旧版本的从数据库同步(通过接收sYNC命令)，同样2.8版本的从数据库也可以与旧版本的主数据库同步（通过发送 SYNC命令)。唯一需要开发者设置的就是积压队列的大小了。
积压队列在本质上是一个固定长度的循环队列，默认情况下积压队列的大小为1MB,可以通过配置文件的repl-backlog-size选项来调整。很容易理解的是，积压队列越大，其允许的主从数据库断线的时间就越长。根据主从数据库之间的网络状态，设置一个合理的积压队列很重要。因为积压队列存储的内容是命令本身，如 SET foo bar，所以估算积压队列的大小只需要估计主从数据库断线的时间中主数据库可能执行的命令的大小即可。
与积压队列相关的另一个配置选项是repl-backlog-ttl,即当所有从数据库与主数据库断开连接后，经过多久时间可以释放积压队列的内存空间。默认时间是1小时。

哨兵
顾名思义，哨兵的作用就是监控Redis系统的运行状况。它的功能包括以下两个。
(1)监控主数据库和从数据库是否正常运行。
(2）主数据库出现故障时自动将从数据库转换为主数据库。
在这里插入图片描述

在一个一主多从的Redis 系统中，可以使用多个哨兵进行监控任务以保证系统足够稳健,如图8-4所示。注意,此时不仅哨兵会同时监控主数据库和从数据库，哨兵之间也会互相监控。
在这里插入图片描述

实践一下：

# 1.创建一个 主 6379  两个从 6380  6381
127.0.0.1:6379> info replication
# Replication
role:master
connected_slaves:2
slave0:ip=127.0.0.1,port=6380,state=online,offset=25608,lag=1
slave1:ip=127.0.0.1,port=6381,state=online,offset=25608,lag=1
master_repl_offset:25608
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:2
repl_backlog_histlen:25607
127.0.0.1:6379>
# 2.如上 一主二从已经配置成功 接下来开始配置哨兵。建立一个配置文件，如 sentinel.conf，内容为:
sentinel monitor mymaster 127.0.0.16379 1
# 其中mymaster表示要监控的主数据库的名字，可以自己定义一个。这个名字必须仅由大小写字母、数字和“.-”这3个字符组成。
# 后两个参数表示主数据库的地址和端口号，这里我们要监控的是主数据库6379。最后的1表示最低通过票数
# 通过cmd  启动 redis-server sentinel.conf --sentinel
[9872] 06 Sep 10:58:36.900 # Sentinel ID is 4804869202f3337f2e3e0ee904e9bedec1e58191
[9872] 06 Sep 10:58:36.900 # +monitor master mymaster 127.0.0.1 6379 quorum 2
[9872] 06 Sep 10:58:36.902 * +slave slave 127.0.0.1:6380 127.0.0.1 6380 @ mymaster 127.0.0.1 6379
[9872] 06 Sep 10:58:36.903 * +slave slave 127.0.0.1:6381 127.0.0.1 6381 @ mymaster 127.0.0.1 6379
# 其中+slave表示新发现了从数据库，可见哨兵成功地发现了两个从数据库。现在哨兵已经在监控这3个Redis实例了，
# 这时我们将主数据库(即运行在6379端口上的Redis实例)关闭（杀死进程或使用SHUTDOWN命令)，等待指定时间后（可以配置，默认为30秒),哨兵会输出如下内容:
[2396] 06 Sep 11:07:31.062 # +sdown master mymaster 127.0.0.1 6379
[2396] 06 Sep 11:07:31.062 # +odown master mymaster 127.0.0.1 6379 #quorum 1/1
[2396] 06 Sep 11:07:31.062 # +new-epoch 1
[2396] 06 Sep 11:07:31.062 # +try-failover master mymaster 127.0.0.1 6379
[2396] 06 Sep 11:07:31.063 # +vote-for-leader 4804869202f3337f2e3e0ee904e9bedec1e58191 1
[2396] 06 Sep 11:07:31.063 # +elected-leader master mymaster 127.0.0.1 6379
[2396] 06 Sep 11:07:31.063 # +failover-state-select-slave master mymaster 127.0.0.1 6379
[2396] 06 Sep 11:07:31.126 # +selected-slave slave 127.0.0.1:6381 127.0.0.1 6381 @ mymaster 127.0.0.1 6379
[2396] 06 Sep 11:07:31.126 * +failover-state-send-slaveof-noone slave 127.0.0.1:6381 127.0.0.1 6381 @ mymaster 127.0.0.1 6379
[2396] 06 Sep 11:07:31.216 * +failover-state-wait-promotion slave 127.0.0.1:6381 127.0.0.1 6381 @ mymaster 127.0.0.1 6379
[2396] 06 Sep 11:07:32.076 # +promoted-slave slave 127.0.0.1:6381 127.0.0.1 6381 @ mymaster 127.0.0.1 6379
[2396] 06 Sep 11:07:32.076 # +failover-state-reconf-slaves master mymaster 127.0.0.1 6379
[2396] 06 Sep 11:07:32.158 * +slave-reconf-sent slave 127.0.0.1:6380 127.0.0.1 6380 @ mymaster 127.0.0.1 6379
[2396] 06 Sep 11:07:33.101 * +slave-reconf-inprog slave 127.0.0.1:6380 127.0.0.1 6380 @ mymaster 127.0.0.1 6379
[2396] 06 Sep 11:07:33.101 * +slave-reconf-done slave 127.0.0.1:6380 127.0.0.1 6380 @ mymaster 127.0.0.1 6379
[2396] 06 Sep 11:07:33.177 # +failover-end master mymaster 127.0.0.1 6379
[2396] 06 Sep 11:07:33.177 # +switch-master mymaster 127.0.0.1 6379 127.0.0.1 6381
[2396] 06 Sep 11:07:33.178 * +slave slave 127.0.0.1:6380 127.0.0.1 6380 @ mymaster 127.0.0.1 6381
[2396] 06 Sep 11:07:33.178 * +slave slave 127.0.0.1:6379 127.0.0.1 6379 @ mymaster 127.0.0.1 6381
# 其中+sdown表示哨兵主观认为主数据库停止服务了，而+odown则表示哨兵客观认为主数据库停止服务了，关于主观和客观的区别后文会详细介绍。
# 此时哨兵开始执行故障恢复，即挑选一个从数据库，将其升格为主数据库。
# +try-failover表示哨兵开始进行故障恢复，+failover-end表示哨兵完成故障恢复，期间涉及的内容比较复杂，包括领头哨兵的选举、备选从数据库的选择等，
# 放到后面介绍，此处只需要关注最后3条输出。+switch-master表示主数据库从6379端口迁移到6380端口，即6380端口的从数据库被升格为主数据库，
# 同时两个+slave则列出了新的主数据库的两个从数据库，端口分别为6381和6379。其中6379就是之前停止服务的主数据库，可见哨兵并没有彻底清除停止服务的实例的信息，
# 这是因为停止服务的实例有可能会在之后的某个时间恢复服务,这时哨兵会让其重新加入进来,所以当实例停止服务后,哨兵会更新该实例的信息，
# 使得当其重新加入后可以按照当前信息继续对外提供服务。此例中6379端口的主数据库实例停止服务了,而6380端口的从数据库已经升格为主数据库，
# 当6379端口的实例恢复服务后，会转变为6380端口实例的从数据库来运行，所以哨兵将6379端口实例的信息修改成了6380端口实例的从数据库。

# 此时我们启动恢复 6379
[2396] 06 Sep 11:15:46.126 # -sdown slave 127.0.0.1:6379 127.0.0.1 6379 @ mymaster 127.0.0.1 6381
[2396] 06 Sep 11:15:56.187 * +convert-to-slave slave 127.0.0.1:6379 127.0.0.1 6379 @ mymaster 127.0.0.1 6381
# -sdown表示实例6379已经恢复服务了(与+sdown相反)同时+convert-to-slave表示将6379端口的实例设置为6380端口实例的从数据库。

实现原理

# 一个哨兵进程启动时会读取配置文件的内容，通过如下的配置找出需要监控的主数据库:
sentinel monitor master-name ip redis-port quorum
# 其中 master-name是一个由大小写字母、数字和“.-_”组成的主数据库的名字，因为考虑到故障恢复后当前监
# 控的系统的主数据库的地址和端口会产生变化，
# 所以哨兵提供了命令可以通过主数据库的名字获取当前系统的主数据库的地址和端口号。
# ip表示当前系统中主数据库的地址，而redis-port则表示端口号。
# quorum用来表示执行故障恢复操作前至少需要几个哨兵节点同意，后文会详细介绍。一个哨兵节点可以同时
# 监控多个Redis主从系统,只需要提供多个sentinel monitor配置即可，例如:
sentinel monitor mymaster 127.0.0.16379 2
sentinel monitor othermaster 192.168.1.3 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个操作贯穿哨兵进程的整个生命周期中，非常重要,可以说了解了这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.16379 2

该配置表示只有当至少两个 Sentinel 节点（包括当前节点）认为该主数据库主观下线时，当前哨兵节点才会认为该主数据库客观下线。进行接下来的选举领头哨兵步骤。

虽然当前哨兵节点发现了主数据库客观下线，需要故障恢复，但是故障恢复需要由领头的哨兵来完成，这样可以保证同一时间只有一个哨兵节点来执行故障恢复。选举领头哨兵的过程使用了Raft算法,具体过程如下：

(1）发现主数据库客观下线的哨兵节点（下面称作A)向每个哨兵节点发送命令，要求对方选自己成为领头哨兵。
(2）如果目标哨兵节点没有选过其他人，则会同意将A设置成领头哨兵。
(3）如果A发现有超过半数且超过quorum参数值的哨兵节点同意选自己成为领头哨兵,则A成功成为领头哨兵。
(4）当有多个哨兵节点同时参选领头哨兵，则会出现没有任何节点当选的可能。此时每个参选节点将等待一个随机时间重新发起参选请求，进行下一轮选举，直到选举成功。

因为要成为领头哨兵必须有超过半数的哨兵节点支持，所以每次选举最多只会选出一个领头哨兵。选出领头哨兵后，领头哨兵将会开始对主数据库进行故障恢复。故障恢复的过程相对简单：

首先领头哨兵将从停止服务的主数据库的从数据库中挑选一个来充当新的主数据库。挑选的依据如下：
(1)所有在线的从数据库中，选择优先级最高的从数据库。优先级可以通过slave-priority选项来设置。
(2）如果有多个最高优先级的从数据库，则复制的命令偏移量越大(即复制越完整）越优先。
(3）如果以上条件都一样，则选择运行ID较小的从数据库。
选出一个从数据库后，领头哨兵将向从数据库发送SLAVEOF NO ONE
命令使其升格为主数据库。而后领头哨兵向其他从数据库发送SLAVEOF命令来使其成为新主数据库的从数据库。最后一步则是更新内部的记录,将已经停止服务的旧的主数据库更新为新的主数据库的从数据库，使得当其恢复服务时自动以从数据库的身份继续服务。

哨兵的部署

哨兵以独立进程的方式对一个主从系统进行监控，监控的效果好坏与否取决于哨兵的视角是否有代表性。如果一个主从系统中配置的哨兵较少，哨兵对整个系统的判断的可靠性就会降低。极端情况下，当只有一个哨兵时，哨兵本身就可能会发生单点故障。整体来讲，相对稳妥的哨兵部署方案是使得哨兵的视角尽可能地与每个节点的视角一致，即:
(1）为每个节点（无论是主数据库还是从数据库）部署一个哨兵;
(2）使每个哨兵与其对应的节点的网络环境相同或相近。
这样的部署方案可以保证哨兵的视角拥有较高的代表性和可靠性。举例一个例子:当网络分区后，如果哨兵认为某个分区是主要分区，即意味着从每个节点观察，该分区均为主分区。同时设置 quorum 的值为N/2+1(其中N为哨兵节点数量)，这样使得只有当大部分哨兵节点同意后才会进行故障恢复。
当系统中的节点较多时，考虑到每个哨兵都会和系统中的所有节点建立连接，为每个节点分配一个哨兵会产生较多连接，尤其是当进行客户端分片时使用多个哨兵节点监控多个主数据库会因为Redis不支持连接复用而产生大量冗余连接，同时如果Redis节点负载较高，会在一定程度上影响其对哨兵的回复以及与其同机的哨兵与其他节点的通信。所以配置哨兵时还需要根据实际的生产环境情况进行选择。