Redis哨兵（Sentinel）模式

Posted 2023-04-19

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了Redis哨兵（Sentinel）模式相关的知识，希望对你有一定的参考价值。

参考技术A

主从切换技术的方法是：当主服务器宕机后，需要手动把一台从服务器切换为主服务器，这就需要人工干预，费事费力，还会造成一段时间内服务不可用。这不是一种推荐的方式，更多时候，我们优先考虑 哨兵模式 。

哨兵模式是一种特殊的模式，首先Redis提供了哨兵的命令，哨兵是一个独立的进程，作为进程，它会独立运行。其原理是 哨兵通过发送命令，等待Redis服务器响应，从而监控运行的多个Redis实例。

这里的哨兵有两个作用

然而一个哨兵进程对Redis服务器进行监控，可能会出现问题，为此，我们可以使用多个哨兵进行监控。各个哨兵之间还会进行监控，这样就形成了多哨兵模式。

用文字描述一下 故障切换（failover） 的过程。假设主服务器宕机，哨兵1先检测到这个结果，系统并不会马上进行failover过程，仅仅是哨兵1主观的认为主服务器不可用，这个现象成为 主观下线 。当后面的哨兵也检测到主服务器不可用，并且数量达到一定值时，那么哨兵之间就会进行一次投票，投票的结果由一个哨兵发起，进行failover操作。切换成功后，就会通过发布订阅模式，让各个哨兵把自己监控的从服务器实现切换主机，这个过程称为 客观下线 。这样对于客户端而言，一切都是透明的。

配置3个哨兵和1主2从的Redis服务器来演示这个过程。

首先配置Redis的主从服务器，修改redis.conf文件如下

上述内容主要是配置Redis服务器，从服务器比主服务器多一个slaveof的配置和密码。

配置3个哨兵，每个哨兵的配置都是一样的。在Redis安装目录下有一个sentinel.conf文件，copy一份进行修改

上述关闭了保护模式，便于测试。

有了上述的修改，我们可以进入Redis的安装目录的src目录，通过下面的命令启动服务器和哨兵

注意启动的顺序。 首先是主机（192.168.11.128）的Redis服务进程，然后启动从机的服务进程，最后启动3个哨兵的服务进程。

上面是通过Jedis进行使用的，同样也可以使用Spring进行配置RedisTemplate使用。

sentinel down-after-milliseconds配置项只是一个哨兵在超过规定时间依旧没有得到响应后，会自己认为主机不可用。对于其他哨兵而言，并不是这样认为。哨兵会记录这个消息，当拥有认为主观下线的哨兵达到sentinel monitor所配置的数量时，就会发起一次投票，进行failover，此时哨兵会重写Redis的哨兵配置文件，以适应新场景的需要。

redis 哨兵模式 sentinel

redis的哨兵模式Sentinel为redis提供高可用性。使用 Sentinel 可以创建一个可以在没有人工干预的情况下抵抗某些类型的故障 Redis 部署。

哨兵的主要功能

监控。监控redis 中master与slave是否正常工作
通知。提供通知API，告知管理员或者其他应用，被监控的redis示例出现了哪些问题，
自动故障转移。如果master服务不可用，sentinel可以进行故障转移，将故障master移除，提升slave作为主，并重新配置其他slave的归属关系。通知使用redis的其他应用使用新的连接地址
配置提供者。sentinel作为客户端服务发现权威来源。客户端链接sentinel，以便获取可用的reids服务地址。发生故障后，哨兵可报告新的连接地址。

哨兵的结构

sentinel哨兵sentinel是一个分布是系统，多个sentinel进程协同工作。其优点如下

当多个sentinel认定master不可用时，才会执行故障检测流程。降低了误报的可能性
多个sentinel协同工作，本身就具有抗故障能力。

部署哨兵

redis-sentinel /path/to/sentinel.conf

或者

redis-server /path/to/sentinel.conf --sentinel

这两者方法其实是一样，如果仔细观察，可以发现，其实redis-sentinel 就是redis-server的一个软链接

redis

要使用sentinel，必须要有配置文件。一般情况下sentinel监听26379端口。

至少要有三个哨兵实例才能做健壮部署。

sentinelsentinel要部署在相互独立的计算机或者虚拟机上。

主观下线与客观下线

Redis Sentinel 有两个不同的关于下线的概念，一个叫做主观下线(Subjectively Down condition，SDOWN) ，指的是一个Sentinel 实例自身检测到master下线宕机状态。另一种称为“客观下线”(ODOWN) ，当有足够多的 Sentinels (至少是sentinel配置文件中quorum的数量)具有 SDOWN 条件并使用 SENTINEL is-master-Down-by-addr 命令从其他 Sentinels 获得反馈时，就会达到 ODOWN 条件。

sentinel配置

配置文件基本内容如下

port 26379
sentinel monitor mymaster 192.168.0.191 6379 2
sentinel down-after-milliseconds mymaster 5000
sentinel failover-timeout mymaster 60000
sentinel parallel-syncs mymaster 1

简单的解释一下这个配置文件

port

就是sentinel哨兵运行的端口

sentinel monitor masterName masterIp masterPort quorum

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

sentinel down-after-milliseconds masterName time

sentinel down-after-milliseconds与主观下线的判断有关：sentinel使用ping命令对其他节点进行心跳检测，如果其他节点超过down-after-milliseconds配置的时间没有回复，sentinel就会将其进行主观下线。该配置对master、slave和sentinel节点的主观下线判定都有效。 down-after-milliseconds的默认值是30000，即30s；可以根据不同的网络环境和应用要求来调整：值越大，对主观下线的判定会越宽松，好处是误判的可能性小，坏处是故障发现和故障转移的时间变长，客户端等待的时间也会变长。例如，如果应用对可用性要求较高，则可以将值适当调小，当故障发生时尽快完成转移；如果网络环境相对较差，可以适当提高该阈值，避免频繁误判。

sentinel failover-timeout masterName time

sentinel failover-timeout与故障转移超时的判断有关，但是该参数不是用来判断整个故障转移阶段的超时，而是其几个子阶段的超时，例如如果主节点晋升从节点时间超过timeout，或从节点向新的主节点发起复制操作的时间(不包括复制数据的时间)超过timeout，都会导致故障转移超时失败。 failover-timeout的默认值是180000，即180s；如果超时，则下一次该值会变为原来的2倍。

sentinel parallel-syncs masterName number

sentinel parallel-syncs与故障转移之后从节点的复制有关：它规定了每次向新的主节点发起复制操作的从节点个数。例如，假设主节点切换完成之后，有3个从节点要向新的主节点发起复制；如果parallel-syncs=1，则从节点会一个一个开始复制；如果parallel-syncs=3，则3个从节点会一起开始复制。 parallel-syncs取值越大，从节点完成复制的时间越快，但是对主节点的网络负载、硬盘负载造成的压力也越大；应根据实际情况设置。例如，如果主节点的负载较低，而从节点对服务可用的要求较高，可以适量增加parallel-syncs取值。parallel-syncs的默认值是1。

除上述几个参数外，还有一些其他参数，如安全验证相关的参数等

实操演示

基本结构

使用3个节点分别部署 redis 服务与sentinel，其中192.168.0.191作为主。在操作过程中注意保证防火墙开放了相应的端口。

192.168.0.191
192.168.0.192
192.168.0.193

redis与sentinel配置

redis的master节点配置如下

bind 127.0.0.1 192.168.0.191
protected-mode yes
port 6379
tcp-backlog 511
timeout 0
tcp-keepalive 300
daemonize yes
supervised no
pidfile /var/run/redis_6379.pid
loglevel notice
logfile "/var/log/redis.log"
databases 16
always-show-logo yes
save 900 1
save 300 10
save 60 10000
stop-writes-on-bgsave-error yes
rdbcompression yes
rdbchecksum yes
dbfilename dump.rdb
dir /var
replica-serve-stale-data yes
replica-read-only yes
repl-diskless-sync no
repl-diskless-sync-delay 5
repl-disable-tcp-nodelay no
replica-priority 100
lazyfree-lazy-eviction no
lazyfree-lazy-expire no
lazyfree-lazy-server-del no
replica-lazy-flush no
appendonly no
appendfilename "appendonly.aof"
appendfsync everysec
no-appendfsync-on-rewrite no
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
aof-load-truncated yes
aof-use-rdb-preamble yes
lua-time-limit 5000
slowlog-log-slower-than 10000
slowlog-max-len 128
latency-monitor-threshold 0
notify-keyspace-events ""
hash-max-ziplist-entries 512
hash-max-ziplist-value 64
list-max-ziplist-size -2
list-compressRedis哨兵（Sentinel）模式
 Sentinel  Redis哨兵模式
 redis哨兵模式
 搞懂Redis (八) - 哨兵机制
 Redis哨兵（Sentinel）模式
 Redis集群-哨兵模式原理（Sentinel）