redis 哨兵模式 sentinel-CFANZ编程社区

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_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-compress-depth 0
set-max-intset-entries 512
zset-max-ziplist-entries 128
zset-max-ziplist-value 64
hll-sparse-max-bytes 3000
stream-node-max-bytes 4096
stream-node-max-entries 100
activerehashing yes
client-output-buffer-limit normal 0 0 0
client-output-buffer-limit replica 256mb 64mb 60
client-output-buffer-limit pubsub 32mb 8mb 60
hz 10
dynamic-hz yes
aof-rewrite-incremental-fsync yes
rdb-save-incremental-fsync yes

slave 服务器上的配置基本相同只是额外添加上

replicaof 192.168.0.191 6379

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

daemonize no
pidfile /var/run/redis-sentinel.pid
logfile  "sentinel.log" 
dir /var/log/

启动流程

先启动master 192.168.0.191，再启动两个slave。

启动完成后，查看redis的replication状态口令

master

redis 哨兵模式 sentinel_哨兵_02

slave

然后再依次启动sentinel 并观察sentinel的运行日志

redis-sentinel /usr/local/etc/redis-sentinel.conf &
tail -f /var/log/sentinel.log

随着三个sentinelsentinel的启动，日志上也会逐一发现所有所有的sentinel节点。

redis 哨兵模式 sentinel_sentinel_03

模拟故障

salve停服

关闭单台slave，然后恢复slave，并观察sentinel日志。

redis 哨兵模式 sentinel_redis_04

slave停止时，被sentnel标注为+sdonw（主观下线开始，+表示状态开始）

slave重启，被sentient标注为+reboot，几乎同时也被标注为-sdown（主观下线结束，-表示状态结束）

单台slave重启没有触发选举机制，sentient只是记录了slave的状态。

master停服

关闭master，并观察sentinel日志

redis 哨兵模式 sentinel_redis_05 从日志可以看出，master被停附后，sentient先是认为master为+sdown（主观下线），然后+odown（客观下线），开始新时代+new-epoch

接下来就是决定failover，这个过程需要先选举，在接下来的过程中有两个sentinel选择了同一节点，符合sentinel配置文件中quorum的设置，接下来就是角色转变的一些操作。原有的master被变为slave，而且因为是停服状态所以还是+sdown。此时重启原master，会有如下信息输出。原master 状态为-sdonw，身份为slave

redis 哨兵模式 sentinel_哨兵_06

此时观察三个节点的redis与sentinel配置文件，会发现配置文件被自动修改。

sentinel的添加与移除

添加哨兵

添加新的 Sentinel 很简单，因为 Sentinel 实现了自动发现机制。所需要做的就是启动新的 Sentinel 配置来监视当前活动的master。sentinel将在10秒内获得其他sentinel成员的名单以及连接在主机上的一组复制品。

移除哨兵

移除一个Sentinel有点复杂: Sentinel永远不会忘记已经见过Sentinel，即使他们很长一段时间不可达。

因此，为了删除 Sentinel，应该在没有网络分区的情况下执行以下步骤:

停止要移除的的Sentinel进程。
发送一个 SENTINEL RESET * 命令给所有其他 SENTINEL 实例(*指的是sentinel配置文件中的masterName，上文示例为mymaster)。一个接一个，在实例之间至少等待30秒。
通过检查sentinel master masterName，确认所有sentinel同意当前活跃的sentinel数量。