概述

Redis Sentinel，即Redis哨兵，在Redis 2.8版本开始引入。它是Redis高可用的实现方案之一。Sentinel是一个管理多个Redis实例的工具，它的核心功能是可以实现对Redis的监控、通知、自动故障转移。

• 监控（Monitoring）：哨兵会不断地检查主节点和从节点是否运作正常。
• 自动故障转移（Automatic failover）：当主节点不能正常工作时，哨兵会开始自动故障转移操作，它会将失效主节点的其中一个从节点升级为新的主节点，并让其他从节点改为复制新的主节点。
• 配置提供者（Configuration provider）：客户端在初始化时，通过连接哨兵来获得当前Redis服务的主节点地址。
• 通知（Notification）：哨兵可以将故障转移的结果发送给客户端。

其中，监控和自动故障转移功能，使得哨兵可以及时发现主节点故障并完成转移；而配置提供者和通知功能，则需要在与客户端的交互中才能体现。

这里的客户端概率和前面文章的客户端有所区别：在前面的文章中，只要通过API访问redis服务器，都会称作客户端，包括redis-cli、Java客户端Jedis等；为了便于区分说明，本文中的客户端并不包括redis-cli，而是比redis-cli更加复杂：redis-cli使用的是redis提供的底层接口，而客户端则对这些接口、功能进行了封装，以便充分利用哨兵的配置提供者和通知功能。

架构

典型的哨兵架构图如下所示：

它由两部分组成，哨兵节点和数据节点。其中哨兵Sentinel 节点负责监控集群中所有的数据节点包括主、从Redis，当发现主故障时，Sentinel会在所有的从中选一个成为新的主。并且会把其余的从变为新主的从。同时那台有问题的旧主也会变为新主的从，也就是说当旧的主即使恢复时，并不会恢复原来的主身份，而是作为新主的一个从。

在Redis高可用架构中，Sentinel往往不是只有一个，而是有3个或者以上。目的是为了让其更加可靠，毕竟主和从切换角色这个过程还是蛮复杂的。

相关概念

主观失效
SDOWN（subjectively down），直接翻译的为”主观”失效，即当前sentinel实例认为某个redis服务为”不可用”状态.

客观失效
ODOWN（objectively down），直接翻译为”客观”失效，即多个sentinel实例都认为master处于”SDOWN”状态，那么此时master将处于ODOWN，ODOWN可以简单理解为master已经被集群确定为”不可用”，将会开启failover。

部署

环境说明

主机名称	IP地址	redis版本和角色说明
k8s-m1	192.168.2.140:6379	redis 6.0.6（主）
k8s-m2	192.168.2.141:6379	redis 6.0.6（从）
k8s-m3	192.168.2.142:6379	redis 6.0.6（从）
k8s-m1	192.168.2.140:26379	Sentinel01
k8s-m2	192.168.2.141:26379	Sentinel02
k8s-m3	192.168.2.142:26379	Sentinel03

部署主从节点

哨兵系统中的主从节点，与普通的主从节点配置是一样的，并不需要做任何额外配置。具体方法可以参考之前文章的部署步骤。两个从节点的配置除了bind其余完全一样。主从部署完后正常的情况大致如下：

192.168.2.140:6379> INFO replication
# Replication
role:master
connected_slaves:2
slave0:ip=192.168.2.141,port=6379,state=online,offset=82978,lag=0
slave1:ip=192.168.2.142,port=6379,state=online,offset=82978,lag=0
master_replid:8e2309122a5b93327f8469e1b7c1be17c0f23499
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:82978
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:82978
192.168.2.140:6379> 

从返回结果可以看到，当前节点192.168.2.140为master，连接它的有两个slave节点。

部署哨兵节点

哨兵节点本质上是特殊的Redis节点。3个哨兵节点的配置除了绑定的IP地址几乎是完全一样的，下面以某个节点为例介绍节点的配置和启动方式；以下是配置的简化版，实际使用中可以根据使用情况进行修改。

port 26379
daemonize yes
pidfile "/var/run/redis-sentinel.pid"
logfile "/usr/local/redis/sentinel.log"
sentinel monitor mymaster 192.168.2.142 6379 2

说明，sentinel monitor mymaster 192.168.2.142 6379 2 配置的含义是：该哨兵节点监控192.168.2.142:6379这个主节点，该主节点的名称是mymaster，最后的2的含义与主节点的故障判定有关：至少需要2个哨兵节点同意，才能判定主节点故障并进行故障转移。这一行是会根据集群的实际情况进行自动变动的。

哨兵节点的启动有两种方式，二者作用是完全相同的：

redis-sentinel sentinel.conf
redis-server sentinel.conf --sentinel

按照上述方式配置和启动之后，整个哨兵系统就启动完毕了。可以通过redis-cli连接哨兵节点进行验证，如下，注意要指定端口。

[root@k8s-m1 redis]# ./src/redis-cli -p 26379
127.0.0.1:26379> INFO sentinel
# Sentinel
sentinel_masters:1
sentinel_tilt:0
sentinel_running_scripts:0
sentinel_scripts_queue_length:0
sentinel_simulate_failure_flags:0
master0:name=mymaster,status=ok,address=192.168.2.141:6379,slaves=2,sentinels=4
127.0.0.1:26379> 

可以看出26379哨兵节点已经在监控mymaster主节点(即192.168.2.141:6379)，并发现了其2个从节点和另外2个哨兵节点。

当所有的数据节点和哨兵节点都正常启动稳定后，此时查看哨兵节点的配置文件，会发现一些变化，以其中一个节点为例：：

[root@k8s-m1 redis]# tail sentinel.conf 
# SENTINEL rename-command mymaster CONFIG CONFIG
# Generated by CONFIG REWRITE
protected-mode no
user default on nopass ~* +@all
sentinel known-replica mymaster 192.168.2.140 6379
sentinel known-replica mymaster 192.168.2.142 6379
sentinel known-sentinel mymaster 192.168.2.142 26379 3e4ccc63758d9bb4f087943a4094bc103a5c0b36
sentinel known-sentinel mymaster 192.168.2.141 0 f0d97ebd0d517c3ac74059011102d7db0e4723db
sentinel known-sentinel mymaster 192.168.2.142 26379 89cdab64fa10d20d827c3e4be7d7f44932e6e5ab
sentinel current-epoch 4

说明，known-replica 和known-sentinel 显示哨兵已经发现了从节点和其他哨兵；带有epoch的参数与配置纪元有关（配置纪元是一个从0开始的计数器，每进行一次领导者哨兵选举，都会+1；领导者哨兵选举是故障转移阶段的一个操作，在后文原理部分会介绍）。

哨兵的相关操作

127.0.0.1:26379> sentinel master mymaster  ##查看主节点的状态信息
 1) "name"
 2) "mymaster"
 3) "ip"
 4) "192.168.2.141"
 5) "port"
 6) "6379"
 7) "runid"
 8) "b2741413c7eddeda239333da172675f8d0c49969"
 9) "flags"
10) "master"
127.0.0.1:26379> sentinel slaves mymaster   ##查看从节点的状态信息，实际是可以看到2个从节点的信息，此处省略了一部分
1)  1) "name"
    2) "192.168.2.142:6379"
    3) "ip"
    4) "192.168.2.142"
    5) "port"
    6) "6379"
    7) "runid"
    8) "6991f330bf5a2410b0718327d92456a329f8c912"
    9) "flags"
   10) "slave"
......
127.0.0.1:26379> sentinel sentinels  mymaster ##查看其它sentinel信息
1)  1) "name"
    2) "89cdab64fa10d20d827c3e4be7d7f44932e6e5ab"
    3) "ip"
    4) "192.168.2.142"
    5) "port"
    6) "26379"
    7) "runid"
    8) "89cdab64fa10d20d827c3e4be7d7f44932e6e5ab"
    9) "flags"
   10) "sentinel"
......
127.0.0.1:26379> 

演示故障转移

下面将演示当主节点发生故障时，哨兵的监控和自动故障转移功能。
（1）首先，使用systemctl stop redis或者kill 命令停止主节点：

[root@k8s-m2 redis]# ps aux|grep redis
root      1144  0.3  0.0 257312  4448 ?        Ssl  Mar18  49:02 /usr/local/redis/src/redis-server 192.168.2.141:6379
root     17653  0.6  0.0 162684  3332 ?        Ssl  Mar27   6:39 ./src/redis-sentinel *:26379 [sentinel]
root     31147  0.0  0.0 112816   972 pts/1    S+   10:38   0:00 grep --color=auto redis

[root@k8s-m2 redis]# systemctl stop  redis

[root@k8s-m2 redis]# ps aux|grep redis
root     17653  0.6  0.0 162684  3332 ?        Ssl  Mar27   6:39 ./src/redis-sentinel *:26379 [sentinel]
root     32017  0.0  0.0 112816   972 pts/1    S+   10:39   0:00 grep --color=auto redis

（2）如果此时立即在哨兵节点中使用info Sentinel命令查看，会发现主节点还没有切换过来，因为哨兵发现主节点故障并转移，需要一段时间。

127.0.0.1:26379> INFO sentinel
# Sentinel
sentinel_masters:1
sentinel_tilt:0
sentinel_running_scripts:0
sentinel_scripts_queue_length:0
sentinel_simulate_failure_flags:0
master0:name=mymaster,status=ok,address=192.168.2.141:6379,slaves=2,sentinels=4

（3）一段时间以后，再次在哨兵节点中执行info Sentinel查看，发现主节点已经从192.168.2.141:6379切换成192.168.2.140:6379节点。

127.0.0.1:26379> INFO sentinel
# Sentinel
sentinel_masters:1
sentinel_tilt:0
sentinel_running_scripts:0
sentinel_scripts_queue_length:0
sentinel_simulate_failure_flags:0
master0:name=mymaster,status=ok,address=192.168.2.140:6379,slaves=2,sentinels=4

但是同时可以发现，哨兵节点认为新的主节点仍然有2个从节点，这是因为哨兵在切换成主节点的同时，将原来的主节点置为其从节点；虽然原来的主节点已经挂掉，但是由于哨兵并不会对其进行客观下线（其含义将在原理部分介绍），因此认为该从节点一直存在。当原来的主节点重新启动后，会自动变成现有主节点的从节点。下面验证一下。

（4）重启节点192.168.2.141上的redis：可以看到节点192.168.2.141成为了节点192.168.2.140的从节点（online）。注意要去当前的主节点上查看。

192.168.2.140:6379> info replication
# Replication
role:master
connected_slaves:2
slave0:ip=192.168.2.142,port=6379,state=online,offset=140437186,lag=0
slave1:ip=192.168.2.141,port=6379,state=online,offset=140437186,lag=0
master_replid:3da2ea6bc0d4fdeb68065ca00d87d05f0217e5ef
master_replid2:6c86696332d33fe60ba1ea097c5ed1d4cab6987e
master_repl_offset:140437327
second_repl_offset:140359628
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:139679072
repl_backlog_histlen:758256
192.168.2.140:6379> 

（5）在故障转移阶段，哨兵和主从两类节点的配置文件都会被自动改写。

对于主从节点，主要是slaveof配置的变化：新的主节点没有了slaveof配置，其从节点则slaveof新的主节点。如下：k8s-m2（192.168.2.141）为从节点

[root@k8s-m2 redis]# tail  /etc/redis/redis.conf 
# to suppress
#
# ignore-warnings ARM64-COW-BUG
# Generated by CONFIG REWRITE
save 3600 1
save 300 100
save 60 10000
user default on sanitize-payload #8d969eef6ecad3c29a3a629280e686cf0c3f5d5a86aff3ca12020c923adc6c92 ~* &* +@all
requirepass "123456"
replicaof 192.168.2.140 6379

对于哨兵节点，除了主从节点信息的变化，纪元(epoch)也会变化，下图中可以看到纪元相关的参数都+1了。
[root@k8s-m2 redis]# tail sentinel.conf

# SENTINEL rename-command mymaster CONFIG CONFIG
# Generated by CONFIG REWRITE
protected-mode no
user default on nopass sanitize-payload ~* &* +@all
sentinel known-replica mymaster 192.168.2.141 6379
sentinel known-replica mymaster 192.168.2.142 6379
sentinel known-sentinel mymaster 192.168.2.141 26379 f0d97ebd0d517c3ac74059011102d7db0e4723db
sentinel known-sentinel mymaster 192.168.2.141 26379 3e4ccc63758d9bb4f087943a4094bc103a5c0b36
sentinel current-epoch 6
sentinel known-sentinel mymaster 192.168.2.142 26379 89cdab64fa10d20d827c3e4be7d7f44932e6e5ab

总结

哨兵系统的搭建过程，有几点需要注意：

（1）哨兵系统中的主从节点，与普通的主从节点并没有什么区别，故障发现和转移是由哨兵来控制和完成的。

（2）哨兵节点本质上是redis节点。

（3）每个哨兵节点，只需要配置监控主节点，便可以自动发现其他的哨兵节点和从节点。

（4）在哨兵节点启动和故障转移阶段，各个节点的配置文件会被重写(config rewrite)。

（5）上面的示例中，一个哨兵只监控了一个主节点；实际上，一个哨兵可以监控多个主节点，通过配置多条sentinel monitor即可实现。

客户端访问哨兵系统

上一小节演示了哨兵的两大作用：监控和自动故障转移，本小节则结合客户端演示哨兵的另外两个作用：配置提供者和通知。

代码示例

先以Java客户端Jedis为例，下面代码可以连接我们的哨兵系统，并进行各种读写操作（代码中只演示如何连接哨兵，异常处理、资源关闭等未考虑）。

import redis.clients.jedis.Jedis;
import redis.clients.jedis.JedisSentinelPool;
import redis.clients.jedis.exceptions.JedisException;
import java.util.HashSet;
import java.util.Set;

public class RedisSentinelExample {

    public static void main(String[] args) {
        // Redis Sentinel 配置
        String masterName = "mymaster";
        Set<String> sentinelSet = new HashSet<>();
        sentinelSet.add("192.168.2.140:26379");
        sentinelSet.add("192.168.2.141:26379");
        sentinelSet.add("192.168.2.142:26379");

        // 创建 JedisSentinelPool
        JedisSentinelPool sentinelPool = new JedisSentinelPool(masterName, sentinelSet);

        Jedis jedis = null;
        try {
            // 从 Sentinel Pool 获取 Jedis 实例
            jedis = sentinelPool.getResource();
            
            // 进行 Redis 操作
            jedis.set("key", "value");
            String result = jedis.get("key");
            System.out.println("Result: " + result);
        } catch (JedisException e) {
            e.printStackTrace();
        } finally {
            if (jedis != null) {
                jedis.close();
            }
        }
        
        // 关闭 Sentinel Pool
        if (sentinelPool != null) {
            sentinelPool.close();
        }
    }
}

客户端原理

Jedis客户端对哨兵提供了很好的支持。如上述代码所示，我们只需要向Jedis提供哨兵节点集合和masterName，构造JedisSentinelPool对象；然后便可以像使用普通redis连接池一样来使用了：通过pool.getResource()获取连接，执行具体的命令。

在整个过程中，我们的代码不需要显式的指定主节点的地址，就可以连接到主节点；代码中对故障转移没有任何体现，就可以在哨兵完成故障转移后自动的切换主节点。之所以可以做到这一点，是因为在JedisSentinelPool的构造器中，进行了相关的工作；主要包括以下两点：

（1）遍历哨兵节点，获取主节点信息：遍历哨兵节点，通过其中一个哨兵节点+masterName获得主节点的信息；该功能是通过调用哨兵节点的sentinel get-master-addr-by-name命令实现，该命令示例如下：

127.0.0.1:26379>  sentinel get-master-addr-by-name mymaster
1) "192.168.2.140"
2) "6379"
127.0.0.1:26379> 

一旦获得主节点信息，停止遍历（因此一般来说遍历到第一个哨兵节点，循环就停止了）。

（2）增加对哨兵的监听：这样当发生故障转移时，客户端便可以收到哨兵的通知，从而完成主节点的切换。具体做法是：利用redis提供的发布订阅功能，为每一个哨兵节点开启一个单独的线程，订阅哨兵节点的+switch-master频道，当收到消息时，重新初始化连接池。

总结

通过客户端原理的介绍，可以加深对哨兵功能的理解：

（1）配置提供者：客户端可以通过哨兵节点+masterName获取主节点信息，在这里哨兵起到的作用就是配置提供者。

需要注意的是，哨兵只是配置提供者，而不是代理。二者的区别在于：如果是配置提供者，客户端在通过哨兵获得主节点信息后，会直接建立到主节点的连接，后续的请求(如set/get)会直接发向主节点；如果是代理，客户端的每一次请求都会发向哨兵，哨兵再通过主节点处理请求。

举一个例子可以很好的理解哨兵的作用是配置提供者，而不是代理。在前面部署的哨兵系统中，将哨兵节点的配置文件进行如下修改：

sentinel monitor mymaster 192.168.92.128 6379 2
改为
sentinel monitor mymaster 127.0.0.1 6379 2

然后，将前述客户端代码在局域网的另外一台机器上运行，会发现客户端无法连接主节点；这是因为哨兵作为配置提供者，客户端通过它查询到主节点的地址为127.0.0.1:6379，客户端会向127.0.0.1:6379建立redis连接，自然无法连接。如果哨兵是代理，这个问题就不会出现了。

（2）通知：哨兵节点在故障转移完成后，会将新的主节点信息发送给客户端，以便客户端及时切换主节点。

基本原理

前面介绍了哨兵部署、使用的基本方法，本部分介绍哨兵实现的基本原理。

哨兵节点支持的命令

哨兵节点作为运行在特殊模式下的redis节点，其支持的命令与普通的redis节点不同。在运维中，我们可以通过这些命令查询或修改哨兵系统；不过更重要的是，哨兵系统要实现故障发现、故障转移等各种功能，离不开哨兵节点之间的通信，而通信的很大一部分是通过哨兵节点支持的命令来实现的。下面介绍哨兵节点支持的主要命令。

（1）基础查询：通过这些命令，可以查询哨兵系统的拓扑结构、节点信息、配置信息等。
info sentinel：获取监控的所有主节点的基本信息
sentinel masters：获取监控的所有主节点的详细信息
sentinel master mymaster：获取监控的主节点mymaster的详细信息
sentinel slaves mymaster：获取监控的主节点mymaster的从节点的详细信息
sentinel sentinels mymaster：获取监控的主节点mymaster的哨兵节点的详细信息
sentinel get-master-addr-by-name mymaster：获取监控的主节点mymaster的地址信息，前文已有介绍
sentinel is-master-down-by-addr：哨兵节点之间可以通过该命令询问主节点是否下线，从而对是否客观下线做出判断

（2）增加/移除对主节点的监控
sentinel monitor mymaster2 192.168.92.128 16379 2：与部署哨兵节点时配置文件中的sentinel monitor功能完全一样，不再详述

sentinel remove mymaster2：取消当前哨兵节点对主节点mymaster2的监控

（3）强制故障转移
sentinel failover mymaster：该命令可以强制对mymaster执行故障转移，即便当前的主节点运行完好；例如，如果当前主节点所在机器即将报废，便可以提前通过failover命令进行故障转移。结果就是redis的主节点会改变。

基本原理

关于哨兵的原理，需要先了解以下几个关键概念。

（1）定时任务：每个哨兵节点维护了3个定时任务。定时任务的功能分别如下：通过向主从节点发送info命令获取最新的主从结构；通过发布订阅功能获取其他哨兵节点的信息；通过向其他节点发送ping命令进行心跳检测，判断是否下线。

（2）主观下线：在心跳检测的定时任务中，如果其他节点超过一定时间没有回复，哨兵节点就会将其进行主观下线。顾名思义，主观下线的意思是一个哨兵节点“主观地”判断下线；与主观下线相对应的是客观下线。

（3）客观下线：哨兵节点在对主节点进行主观下线后，会通过sentinel is-master-down-by-addr命令询问其他哨兵节点该主节点的状态；如果判断主节点下线的哨兵数量达到一定数值，则对该主节点进行客观下线。

需要特别注意的是，客观下线是主节点才有的概念；如果从节点和哨兵节点发生故障，被哨兵主观下线后，不会再有后续的客观下线和故障转移操作。

（4）选举领导者哨兵节点：当主节点被判断客观下线以后，各个哨兵节点会进行协商，选举出一个领导者哨兵节点，并由该领导者节点对其进行故障转移操作。

监视该主节点的所有哨兵都有可能被选为领导者，选举使用的算法是Raft算法；Raft算法的基本思路是先到先得：即在一轮选举中，哨兵A向B发送成为领导者的申请，如果B没有同意过其他哨兵，则会同意A成为领导者。选举的具体过程这里不做详细描述，一般来说，哨兵选择的过程很快，谁先完成客观下线，一般就能成为领导者。

（5）故障转移：选举出的领导者哨兵，开始进行故障转移操作，该操作大体可以分为3个步骤：

在从节点中选择新的主节点：选择的原则是，首先过滤掉不健康的从节点；然后选择优先级最高的从节点(由slave-priority指定)；如果优先级无法区分，则选择复制偏移量最大的从节点；如果仍无法区分，则选择runid最小的从节点。
更新主从状态：通过slaveof no one命令，让选出来的从节点成为主节点；并通过slaveof命令让其他节点成为其从节点。
将已经下线的主节点设置为新的主节点的从节点，当之前下线的主节点重新上线后，它会成为新的主节点的从节点。

通过上述几个关键概念，可以基本了解哨兵的工作原理。为了更形象的说明，下图展示了领导者哨兵节点的日志，包括从节点启动到完成故障转移。

2107:X 28 Mar 2024 14:22:37.185 # +sdown master mymaster 192.168.2.141 6379
2107:X 28 Mar 2024 14:22:37.367 # +new-epoch 9
2107:X 28 Mar 2024 14:22:37.401 # +vote-for-leader 3e4ccc63758d9bb4f087943a4094bc103a5c0b36 9
2107:X 28 Mar 2024 14:22:38.290 # +odown master mymaster 192.168.2.141 6379 #quorum 3/2
2107:X 28 Mar 2024 14:22:38.290 # +new-epoch 10
2107:X 28 Mar 2024 14:22:38.290 # +try-failover master mymaster 192.168.2.141 6379
2107:X 28 Mar 2024 14:22:38.299 # +vote-for-leader 3e4ccc63758d9bb4f087943a4094bc103a5c0b36 10
2107:X 28 Mar 2024 14:22:38.341 # 3e4ccc63758d9bb4f087943a4094bc103a5c0b36 voted for 3e4ccc63758d9bb4f087943a4094bc103a5c0b36 10
2107:X 28 Mar 2024 14:22:38.341 # 89cdab64fa10d20d827c3e4be7d7f44932e6e5ab voted for 3e4ccc63758d9bb4f087943a4094bc103a5c0b36 10
2107:X 28 Mar 2024 14:22:38.383 # +elected-leader master mymaster 192.168.2.141 6379
2107:X 28 Mar 2024 14:22:38.383 # +failover-state-select-slave master mymaster 192.168.2.141 6379
2107:X 28 Mar 2024 14:22:38.441 # +selected-slave slave 192.168.2.142:6379 192.168.2.142 6379 @ mymaster 192.168.2.141 6379
2107:X 28 Mar 2024 14:22:38.441 * +failover-state-send-slaveof-noone slave 192.168.2.142:6379 192.168.2.142 6379 @ mymaster 192.168.2.141 6379
2107:X 28 Mar 2024 14:22:38.500 * +failover-state-wait-promotion slave 192.168.2.142:6379 192.168.2.142 6379 @ mymaster 192.168.2.141 6379
2107:X 28 Mar 2024 14:22:38.830 # +promoted-slave slave 192.168.2.142:6379 192.168.2.142 6379 @ mymaster 192.168.2.141 6379
2107:X 28 Mar 2024 14:22:38.830 # +failover-state-reconf-slaves master mymaster 192.168.2.141 6379
2107:X 28 Mar 2024 14:22:38.883 * +slave-reconf-sent slave 192.168.2.140:6379 192.168.2.140 6379 @ mymaster 192.168.2.141 6379
2107:X 28 Mar 2024 14:22:39.474 # -odown master mymaster 192.168.2.141 6379
2107:X 28 Mar 2024 14:22:39.811 * +slave-reconf-inprog slave 192.168.2.140:6379 192.168.2.140 6379 @ mymaster 192.168.2.141 6379
2107:X 28 Mar 2024 14:22:39.811 * +slave-reconf-done slave 192.168.2.140:6379 192.168.2.140 6379 @ mymaster 192.168.2.141 6379
2107:X 28 Mar 2024 14:22:39.872 # +failover-end master mymaster 192.168.2.141 6379
2107:X 28 Mar 2024 14:22:39.873 # +switch-master mymaster 192.168.2.141 6379 192.168.2.142 6379
2107:X 28 Mar 2024 14:22:39.873 * +slave slave 192.168.2.140:6379 192.168.2.140 6379 @ mymaster 192.168.2.142 6379
2107:X 28 Mar 2024 14:22:39.873 * +slave slave 192.168.2.141:6379 192.168.2.141 6379 @ mymaster 192.168.2.142 6379
2107:X 28 Mar 2024 14:23:09.884 # +sdown slave 192.168.2.141:6379 192.168.2.141 6379 @ mymaster 192.168.2.142 6379
2107:X 28 Mar 2024 14:24:12.421 # -sdown slave 192.168.2.141:6379 192.168.2.141 6379 @ mymaster 192.168.2.142 6379
2107:X 28 Mar 2024 14:24:22.400 * +convert-to-slave slave 192.168.2.141:6379 192.168.2.141 6379 @ mymaster 192.168.2.142 6379

配置与实践建议

配置

下面介绍与哨兵相关的几个配置。

（1） sentinel monitor {masterName} {masterIp} {masterPort} {quorum}

sentinel monitor是哨兵最核心的配置，在前文讲述部署哨兵节点时已说明，其中：masterName指定了主节点名称，masterIp和masterPort指定了主节点地址，quorum是判断主节点客观下线的哨兵数量阈值：当判定主节点下线的哨兵数量达到quorum时，对主节点进行客观下线。建议取值为哨兵数量的一半加1（多数）。

（2） sentinel down-after-milliseconds {masterName} {time}

sentinel down-after-milliseconds与主观下线的判断有关：哨兵使用ping命令对其他节点进行心跳检测，如果其他节点超过down-after-milliseconds配置的时间没有回复，哨兵就会将其进行主观下线。该配置对主节点、从节点和哨兵节点的主观下线判定都有效。

down-after-milliseconds的默认值是30000，即30s；可以根据不同的网络环境和应用要求来调整：值越大，对主观下线的判定会越宽松，好处是误判的可能性小，坏处是故障发现和故障转移的时间变长，客户端等待的时间也会变长。例如，如果应用对可用性要求较高，则可以将值适当调小，当故障发生时尽快完成转移；如果网络环境相对较差，可以适当提高该阈值，避免频繁误判。

（3） sentinel parallel-syncs {masterName} {number}

sentinel parallel-syncs与故障转移之后从节点的复制有关：它规定了每次向新的主节点发起复制操作的从节点个数。例如，假设主节点切换完成之后，有3个从节点要向新的主节点发起复制；如果parallel-syncs=1，则从节点会一个一个开始复制；如果parallel-syncs=3，则3个从节点会一起开始复制。

parallel-syncs取值越大，从节点完成复制的时间越快，但是对主节点的网络负载、硬盘负载造成的压力也越大；应根据实际情况设置。例如，如果主节点的负载较低，而从节点对服务可用的要求较高，可以适量增加parallel-syncs取值。parallel-syncs的默认值是1。

（4） sentinel failover-timeout {masterName} {time}

sentinel failover-timeout与故障转移超时的判断有关，但是该参数不是用来判断整个故障转移阶段的超时，而是其几个子阶段的超时，例如如果主节点晋升从节点时间超过timeout，或从节点向新的主节点发起复制操作的时间(不包括复制数据的时间)超过timeout，都会导致故障转移超时失败。

failover-timeout的默认值是180000，即180s；如果超时，则下一次该值会变为原来的2倍。

（5）除上述几个参数外，还有一些其他参数，如安全验证相关的参数，这里不做介绍。

实践建议

（1）哨兵节点的数量应不止一个，一方面增加哨兵节点的冗余，避免哨兵本身成为高可用的瓶颈；另一方面减少对下线的误判。此外，这些不同的哨兵节点应部署在不同的物理机上。

（2）哨兵节点的数量应该是奇数，便于哨兵通过投票做出“决策”：领导者选举的决策、客观下线的决策等。

（3）各个哨兵节点的配置应一致，包括硬件、参数等；此外，所有节点都应该使用ntp或类似服务，保证时间准确一致。

（4）哨兵的配置提供者和通知客户端功能，需要客户端的支持才能实现，如前文所说的Jedis；如果开发者使用的库未提供相应支持，则可能需要开发者自己实现。

（5）当哨兵系统中的节点在docker（或其他可能进行端口映射的软件）中部署时，应特别注意端口映射可能会导致哨兵系统无法正常工作，因为哨兵的工作基于与其他节点的通信，而docker的端口映射可能导致哨兵无法连接到其他节点。例如，哨兵之间互相发现，依赖于它们对外宣称的IP和port，如果某个哨兵A部署在做了端口映射的docker中，那么其他哨兵使用A宣称的port无法连接到A。

总结

本文介绍了哨兵的作用：监控、故障转移、配置提供者和通知；然后讲述了哨兵系统的部署方法，以及通过客户端访问哨兵系统的方法；再然后简要说明了哨兵实现的基本原理；并在最后给出了关于哨兵实践的一些建议。

在主从复制的基础上，哨兵引入了主节点的自动故障转移，进一步提高了Redis的高可用性；但是哨兵模式同样还是有很显的缺陷就是哨兵无法对从节点进行自动故障转移，在读写分离场景下，从节点故障会导致读服务不可用，就需要我们对从节点做额外的监控、切换操作。

同时，哨兵仍然没有解决写操作无法负载均衡、及存储能力受到单机限制的问题；这些问题的解决需要使用到真正的集群，后续将会介绍。

更多关于redis的知识分享，请前往博客主页。编写过程中，难免出现差错，敬请指出