Redis详解7.哨兵模式

作者: 卢卡斯哔哔哔 | 来源:发表于2019-02-14 13:19 被阅读7次

章节目录

Redis详解1.安装及使用
 Redis详解2.数据结构
 Redis详解3.发布订阅
 Redis详解4.事务
 Redis详解5.数据持久化
 Redis详解6.主从模式
 Redis详解7.哨兵模式
 Redis详解8.Cluster模式

1 简介

参考资料来源

Redis进阶实践之十 Redis哨兵集群模式
 Redis Sentinel机制与用法（一）
Redis Sentinel机制与用法（二）

哨兵模式

上一章讲解了Redis主从模式的实现，主从模式的配置简单，Master节点不需要修改，只需要修改Slave节点即可。在主从模式下如果Master宕机，需要手动重启Master节点或者手动切换主节点来完成系统恢复，这在生产环境中是有问题的。Redis在2.6版本开始提供的了哨兵模式，到Redis的2.8版本以后该模式正式稳定。Sentinel（哨兵）进程监控Redis集群中Master主服务器工作的状态，在Master主服务器发生故障的时候，可以实现Master和Slave服务器的切换，保证系统的高可用。

哨兵

哨兵（Sentinel）是一个分布式系统，你可以在一个架构中运行多个哨兵进程，这些进程使用流言协议（Gossip Protocols）来接收关于Master主服务器是否下线的信息，并使用投票协议（Agreement Protocols）来决定是否执行自动故障迁移，以及选择哪个Slave作为新的Master。
主观宕机：每个哨兵（Sentinel）进程会向其它哨兵、Master、Slave定时发送消息，以确认对方是否”活”着，如果发现对方在指定配置时间内未得到回应，则暂时认为对方已掉线，也就是所谓的主观宕机（Subjective Down，SDOWN）。
客观宕机：当“哨兵群”中的多数Sentinel进程在对Master主服务器做出SDOWN的判断，并且通过SENTINEL is-master-down-by-addr命令互相交流之后，得出的Master Server下线判断，这种方式就是客观宕机（Objectively Down，简称 ODOWN）。
投票：当客观宕机后，哨兵可以通过一定的Vote算法，从剩下的Slave从服务器节点中，选一台提升为Master服务器节点，然后自动修改相关配置，并开启故障转移（failover）。

哨兵进程的作用：

监控：哨兵会不断地检查你的Master和Slave是否运作正常。
提醒：当被监控的某个Redis节点出现问题时，哨兵(sentinel) 可以通过 API 向管理员或者其他应用程序发送通知。
自动故障迁移：当一个Master不能正常工作时，哨兵会开始一次自动故障迁移操作，它会将失效Master的其中一个Slave升级为新的Master，并让失效Master的其他Slave改为复制新的Master；当客户端试图连接失效的Master时，集群也会向客户端返回新Master的地址，使得集群可以使用现在的Master替换失效Master。Master和Slave服务器切换后，Master的redis.conf、Slave的redis.conf和sentinel.conf的配置文件的内容都会发生相应的改变，即，Master主服务器的redis.conf配置文件中会多一行slaveof的配置，sentinel.conf的监控目标会随之调换。

Sentinel进程的工作方式

每个Sentinel进程以每秒钟一次的频率向整个集群中的Master主服务器，Slave从服务器以及其他Sentinel进程发送一个 PING 命令。
如果一个实例（instance）距离最后一次有效回复 PING 命令的时间超过 down-after-milliseconds 选项所指定的值，则这个实例会被Sentinel进程标记为SDOWN。
如果一个Master主服务器被标记为SDOWN，则正在监视这个Master主服务器的所有 Sentinel进程要以每秒一次的频率确认Master主服务器的确进入了主观下线状态。
当有足够数量的Sentinel进程（大于等于配置文件指定的值）在指定的时间范围内确认Master主服务器进入了SDOWN，则Master主服务器会被标记为客观下线ODOWN。
在一般情况下，每个Sentinel进程会以每10 秒一次的频率向集群中的所有Master主服务器、Slave从服务器发送INFO命令。
当Master主服务器被Sentinel进程标记为ODOWN时，Sentinel进程向下线的Master主服务器的所有Slave从服务器发送INFO命令的频率会从 10 秒一次改为每秒一次。
若没有足够数量的Sentinel进程同意 Master主服务器下线， Master主服务器的客观下线状态就会被移除。若Master主服务器重新向Sentinel进程发送 PING 命令返回有效回复，Master主服务器的主观下线状态就会被移除。

2 配置

Redis-Server配置

Redis-Server的配置和主从模式配置是一致的，此处不再介绍。

Redis-Sentinel配置

# sentinel的固定配置格式sentinel <option_name> <master_name> <option_value>

# 配置sentinel监控的master
# sentinel监控的master的名字叫做mymaster，地址为127.0.0.1:6380
# sentinel在集群式时，需要多个sentinel互相沟通来确认某个master是否真的死了；
# 数字1代表，当集群中有1个sentinel认为master死了时，才能真正认为该master已经不可用了。
sentinel monitor mymaster 127.0.0.1 6380 1

# sentinel会向master发送心跳PING来确认master是否存活
# 如果master在“一定时间范围”内不回应PONG或者是回复了一个错误消息
# 那么这个sentinel会主观地认为这个master已经不可用了（SDOWN）
# 而这个down-after-milliseconds就是用来指定这个“一定时间范围”的，单位是毫秒。
sentinel down-after-milliseconds mymaster 5000

# 在发生failover主备切换时，这个选项指定了最多可以有多少个slave同时对新的master进行同步
# 这个数字越小，完成failover所需的时间就越长
# 但是如果这个数字越大，就意味着越多的slave因为replication而不可用。
# 可以通过将这个值设为 1 来保证每次只有一个slave处于不能处理命令请求的状态。
sentinel parallel-syncs mymaster 1

# 实现主从切换，完成故障转移的所需要的最大时间值。
# 若Sentinel进程在该配置值内未能完成故障转移的操作，则认为本次故障转移操作失败。
sentinel failover-timeout mymaster 60000

# 指定Sentinel进程检测到Master-Name所指定的“Master主服务器”的实例异常的时候，所要调用的报警脚本。
sentinel notification-script mymaster <script-path>

启动Sentinel

方式1：redis-sentinel redis-sentinel.conf
方式2：redis-server sentinel.conf --sentinel

3 测试主从切换

启动Sentinel

36849:X 14 Feb 2019 12:56:29.190 # Sentinel ID is 72e957adcddf731147b659392ef51c25549c71bc
36849:X 14 Feb 2019 12:56:29.190 # +monitor master mymaster 127.0.0.1 6380 quorum 1
36849:X 14 Feb 2019 12:56:29.191 * +slave slave 127.0.0.1:6381 127.0.0.1 6381 @ mymaster 127.0.0.1 6380
36849:X 14 Feb 2019 12:56:29.192 * +slave slave 127.0.0.1:6382 127.0.0.1 6382 @ mymaster 127.0.0.1 6380

查看Redis集群信息

127.0.0.1:6380> INFO Replication
# Replication
role:master
connected_slaves:2
slave0:ip=127.0.0.1,port=6381,state=online,offset=3033,lag=0
slave1:ip=127.0.0.1,port=6382,state=online,offset=3033,lag=1

查看进程信息

# ps -l | grep "redis"
501 36818 34208  4006   0  31  0  4374192   2572 -   S+    0 ttys000    0:00.12 redis-server 127.0.0.1:6380
501 36819 34237  4006   0  31  0  4384432   2596 -   S+    0 ttys001    0:00.11 redis-server 127.0.0.1:6381
501 36822 34274  4006   0  31  0  4383408   2552 -   S+    0 ttys002    0:00.11 redis-server 127.0.0.1:6382
501 36849 34951  4006   0  31  0  4333232   2540 -   S+    0 ttys003    0:00.15 redis-sentinel *:26379 [sentinel]

kill掉Master节点

kill 36818

Sentinel日志

# sdown掉原Master节点
36849:X 14 Feb 2019 13:00:11.190 # +sdown master mymaster 127.0.0.1 6380
# odown掉原Master节点
36849:X 14 Feb 2019 13:00:11.190 # +odown master mymaster 127.0.0.1 6380 #quorum 1/1
36849:X 14 Feb 2019 13:00:11.190 # +new-epoch 1
36849:X 14 Feb 2019 13:00:11.190 # +try-failover master mymaster 127.0.0.1 6380
36849:X 14 Feb 2019 13:00:11.191 # +vote-for-leader 72e957adcddf731147b659392ef51c25549c71bc 1
36849:X 14 Feb 2019 13:00:11.191 # +elected-leader master mymaster 127.0.0.1 6380
36849:X 14 Feb 2019 13:00:11.191 # +failover-state-select-slave master mymaster 127.0.0.1 6380
# 6381选举为主节点
36849:X 14 Feb 2019 13:00:11.245 # +selected-slave slave 127.0.0.1:6381 127.0.0.1 6381 @ mymaster 127.0.0.1 6380
36849:X 14 Feb 2019 13:00:11.245 * +failover-state-send-slaveof-noone slave 127.0.0.1:6381 127.0.0.1 6381 @ mymaster 127.0.0.1 6380
36849:X 14 Feb 2019 13:00:11.337 * +failover-state-wait-promotion slave 127.0.0.1:6381 127.0.0.1 6381 @ mymaster 127.0.0.1 6380
36849:X 14 Feb 2019 13:00:11.943 # +promoted-slave slave 127.0.0.1:6381 127.0.0.1 6381 @ mymaster 127.0.0.1 6380
36849:X 14 Feb 2019 13:00:11.943 # +failover-state-reconf-slaves master mymaster 127.0.0.1 6380
36849:X 14 Feb 2019 13:00:12.006 * +slave-reconf-sent slave 127.0.0.1:6382 127.0.0.1 6382 @ mymaster 127.0.0.1 6380
36849:X 14 Feb 2019 13:00:12.994 * +slave-reconf-inprog slave 127.0.0.1:6382 127.0.0.1 6382 @ mymaster 127.0.0.1 6380
36849:X 14 Feb 2019 13:00:12.994 * +slave-reconf-done slave 127.0.0.1:6382 127.0.0.1 6382 @ mymaster 127.0.0.1 6380
36849:X 14 Feb 2019 13:00:13.050 # +failover-end master mymaster 127.0.0.1 6380
# 切换6381为新的主节点
36849:X 14 Feb 2019 13:00:13.050 # +switch-master mymaster 127.0.0.1 6380 127.0.0.1 6381
# 6382作为6381的Slave节点
36849:X 14 Feb 2019 13:00:13.050 * +slave slave 127.0.0.1:6382 127.0.0.1 6382 @ mymaster 127.0.0.1 6381
36849:X 14 Feb 2019 13:00:13.050 * +slave slave 127.0.0.1:6380 127.0.0.1 6380 @ mymaster 127.0.0.1 6381
36849:X 14 Feb 2019 13:00:43.064 # +sdown slave 127.0.0.1:6380 127.0.0.1 6380 @ mymaster 127.0.0.1 6381

新的主节点

# 6381日志
Setting secondary replication ID to 2cc46e6225022394b9277c3c1031299ffa61301c, valid up to offset: 12806. New replication ID is e76568505649a7bdf3f8aaadb2c3bb853d288395
36819:M 14 Feb 2019 13:00:11.337 * Discarding previously cached master state.
36819:M 14 Feb 2019 13:00:11.337 * MASTER MODE enabled (user request from 'id=4 addr=127.0.0.1:50356 fd=8 name=sentinel-72e957ad-cmd age=222 idle=0 flags=x db=0 sub=0 psub=0 multi=3 qbuf=140 qbuf-free=32628 obl=36 oll=0 omem=0 events=r cmd=exec')
36819:M 14 Feb 2019 13:00:11.339 # CONFIG REWRITE executed with success.
36819:M 14 Feb 2019 13:00:12.607 * Replica 127.0.0.1:6382 asks for synchronization
36819:M 14 Feb 2019 13:00:12.607 * Partial resynchronization request from 127.0.0.1:6382 accepted. Sending 289 bytes of backlog starting from offset 12806.

查看主节点

# 6381变成主节点
127.0.0.1:6381> INFO Replication
# Replication
role:master
connected_slaves:1
slave0:ip=127.0.0.1,port=6382,state=online,offset=24504,lag=0

配置文件的变化

# 6381变成主节点
# redis移除了配置文件redis_slave1.conf中slaveof这行配置
slaveof 127.0.0.1 6380
# 6382变成6381的从节点
# redis移除配置文件redis_slave2.conf中原来的slaveof配置，增加下面这行配置
replicaof 127.0.0.1 6381

4 哨兵模式的优缺点

优点

哨兵集群模式是基于主从模式的，所有主从的优点，哨兵模式同样具有。
主从可以切换，故障可以转移，系统可用性更好。
哨兵模式是主从模式的升级，系统更健壮，可用性更高。

缺点

Redis较难支持在线扩容，在集群容量达到上限时在线扩容会变得很复杂。
实现哨兵模式的配置也不简单，甚至可以说有些繁琐

Redis详解7.哨兵模式

章节目录

1 简介

参考资料来源

哨兵模式

哨兵

哨兵进程的作用：

Sentinel进程的工作方式

2 配置

Redis-Server配置

Redis-Sentinel配置

启动Sentinel

3 测试主从切换

启动Sentinel

查看Redis集群信息

查看进程信息

kill掉Master节点

Sentinel日志

新的主节点

查看主节点

配置文件的变化

4 哨兵模式的优缺点

优点

缺点

相关文章

网友评论

延伸阅读

深度阅读

栏目导航

热点阅读

Spring全家桶