微服务框架【第14期】--Redis哨兵模式
微服务框架【第14期】--Redis哨兵模式
导读:
大家好，我是老田。昨天我们了解了Redis的主从模式，今天我们学习Redis的哨兵模式，在 Redis 主从集群中，哨兵模式是实现主从库自动切换的关键机制，它可以有效地解决了主从复制模式下故障转移的问题。
1.Redis哨兵模式
在 Redis 主从复制模式中，因为系统不具备自动恢复的功能，所以当主服务器（master）宕机后，需要手动把一台从服务器（slave）切换为主服务器。在这个过程中，不仅需要人为干预，而且还会造成一段时间内服务器处于不可用状态，同时数据安全性也得不到保障，因此主从模式的可用性较低，不适用于线上生产环境。
Redis 官方推荐一种高可用方案，也就是 Redis Sentinel 哨兵模式，它弥补了主从模式的不足。Sentinel 通过监控的方式获取主机的工作状态是否正常，当主机发生故障时， Sentinel 会自动进行 Failover（即故障转移），并将其监控的从机提升主服务器（master），从而保证了系统的高可用性。
哨兵模式是一种特殊的模式，Redis 为其提供了专属的哨兵命令，它是一个独立的进程，能够独立运行。下面使用 Sentinel 搭建 Redis 集群，基本结构图如下所示：
在上图过程中，哨兵主要有两个重要作用：
第一：哨兵节点会以每秒一次的频率对每个 Redis 节点发送
PING命令，并通过 Redis 节点的回复来判断其运行状态。第二：当哨兵监测到主服务器发生故障时，会自动在从节点中选择一台机器，并将其提升为主服务器，然后使用 PubSub 发布订阅模式，通知其他的从节点，修改配置文件，跟随新的主服务器。
在实际生产情况中，Redis Sentinel 是集群的高可用的保障，为避免 Sentinel 发生意外，它一般是由 3～5 个节点组成，这样就算挂了个别节点，该集群仍然可以正常运转。其结构图如下所示：
上图所示，多个哨兵之间也存在互相监控，这就形成了多哨兵模式。
哨兵实现了什么功能呢？下面是Redis官方文档的描述：
监控（Monitoring）：哨兵会不断地检查主节点和从节点是否运作正常。
自动故障转移（Automatic failover）：当主节点不能正常工作时，哨兵会开始自动故障转移操作，它会将失效主节点的其中一个从节点升级为新的主节点，并让其他从节点改为复制新的主节点。
通知（Notification）：哨兵可以将故障转移的结果发送给客户端。
其中，监控和自动故障转移功能，使得哨兵可以及时发现主节点故障并完成转移；而配置提供者和通知功能，则需要在与客户端的交互中才能体现
2.搭建多哨兵模式
2.1 新建目录
# mkdir /usr/local/sentinel
2.2 复制redis
# cp -r /usr/local/redis/bin/* /usr/local/sentinel
2.3 复制配置文件
从redis解压目录中复制sentinel配置文件
# cd /usr/local/tmp/redis-5.0.5/
# cp sentinel.conf /usr/local/sentinel/
2.4 修改配置文件
# cd /usr/local/sentinel
# vim sentinel.conf`在这里插入代码片`
port 26379
daemonize yes
logfile "/usr/local/sentinel/26379.log"
sentinel monitor mymaster 192.168.52.133 6379 2
复制sentinel.conf，命名为sentinel-26380.conf
# cp sentinel.conf sentinel-26380.conf
# vim sentinel-26380.conf
port 26380
daemonize yes
logfile "/usr/local/sentinel/26380.log"
sentinel monitor mymaster 192.168.52.133 6379 2
复制sentinel.conf，命名为sentinel-26381.conf
# cp sentinel.conf sentinel-26381.conf
# vim sentinel-26381.conf
port 26381
daemonize yes
logfile “/usr/local/sentinel/26381.log”
sentinel monitor mymaster 192.168.52.133 6379 2
2.5 启动主从
如果已经启动状态，忽略下面命令。如果启动部分，全部kill后重新启动。
使用kill杀死全部redis
# ps aux|grep redis
# kill -9 进程号
启动redis主从
# cd /usr/local/replica
# ./startup.sh
2.6 启动三个哨兵
# cd /usr/local/sentinel
# ./redis-sentinel sentinel.conf
# ./redis-sentinel sentinel-26380.conf
# ./redis-sentinel sentinel-26381.conf
2.7 查看日志
# cat 26379.log
2.8 测试宕机
查看redis进程号
# ps aux|grep redis
杀死主进程号
# kill -9 进程号
查看日志，短暂延迟后会发现，出现新的主。
# cat 26379.log
3.sentinel.conf配置项
| 配置项 | 参数类型 | 作用 |
|---|---|---|
| port | 整数 | 启动哨兵进程端口，如果是哨兵集群需要配置多个端口 |
| dir | 文件夹目录 | 哨兵进程服务临时文件夹，默认为/tmp，要保证有可写入的权限 |
| sentinel down-after-milliseconds | <服务名称><毫秒数（整数）> | 指定哨兵在监控Redis服务时，当Redis服务在一个默认毫秒数内都无法回答时，单个哨兵认为的主观下线时间，默认为30000（30秒） |
| sentinel parallel-syncs | <服务名称><服务器数（整数）> | 指定可以有多少个Redis服务同步新的主机，一般而言，这个数字越小同步时间越长，而越大，则对网络资源要求越高 |
| sentinel failover-timeout | <服务名称><毫秒数（整数）> | 指定故障切换允许的毫秒数，超过这个时间，就认为故障切换失败，默认为3分钟 |
| sentinel notification-script | <服务名称><脚本路径> | 指定sentinel检测到该监控的redis实例指向的实例异常时，调用的报警脚本。该配置项可选，比较常用 |
| sentinel auth-pass <master-name> <password> | <服务器名称><密码> | 若主服务器设置了密码，则哨兵必须也配置密码，否则哨兵无法对主从服务器进行监控。该密码与主服务器密码相同。 |
4.主库下线的判定
主观下线和客观下线
主观下线：主观下线，适用于主服务器和从服务器。如果在规定的时间内(配置参数：down-after-milliseconds)，Sentinel 节点没有收到目标服务器的有效回复，则判定该服务器为“主观下线”。比如 Sentinel1 向主服务发送了
PING命令，在规定时间内没收到主服务器PONG回复，则 Sentinel1 判定主服务器为“主观下线”客观下线：有客观下线，只适用于主服务器。Sentinel1 发现主服务器出现了故障，它会通过相应的命令，询问其它 Sentinel 节点对主服务器的状态判断。如果超过半数以上的 Sentinel 节点认为主服务器 down 掉，则 Sentinel1 节点判定主服务为“客观下线”。
5.哨兵集群的选举
投票选举，所有 Sentinel 节点会通过投票机制，按照谁发现谁去处理的原则，选举 Sentinel1 为领头节点去做 Failover（故障转移）操作。Sentinel1 节点则按照一定的规则在所有从节点中选择一个最优的作为主服务器，然后通过发布订阅功能通知其余的从节点（slave）更改配置文件，跟随新上任的主服务器（master）。至此就完成了主从切换的操作。
主库下线和投票选举总结
6.哨兵模式优缺点
优点：
哨兵集群，基于主从复制模式，有主从配置的优点
主从可切换，故障可转移，系统性能较好
哨兵模式是主从模式的升级，手动到自动，系统更健壮
缺点：
Redis在线扩容不友好，集群容量达到一定上限时扩容很麻烦
实现哨兵模式需要繁琐的配置
博观而约取，厚积而薄发！
--END--