Redis Sentinel为Redis提供了高可用解决方案。实际上这意味着使用Sentinel可以部署一套Redis,在没有人为干预的情况下去应付各种各样的失败事件。
下面是Sentinel的功能列表:
- 监控(Monitoring):Sentinel不断的去检查你的主从实例是否按照预期在工作。
- 通知(Notification):Sentinel可以通过一个api来通知系统管理员或者另外的应用程序,被监控的Redis实例有一些问题。
- 自动故障转移(Automatic failover):如果一个主节点没有按照预期工作,Sentinel会开始故障转移过程,把一个从节点提升为主节点,并重新配置其他的从节点使用新的主节点,使用Redis服务的应用程序在连接的时候也被通知新的地址。
- 配置提供者(Configuration provider):Sentinel给客户端的服务发现提供来源:对于一个给定的服务,客户端连接到Sentinels来寻找当前主节点的地址。当故障转移发生的时候,Sentinels将报告新的地址。
前言
主从使用一主一从,然后使用sentinel进行高可用配置,当主服务器挂掉,从服务器自动升为主服务器。
1.配置主服务器
# 使得Redis服务器可以跨网络访问(直接注释也行)
bind 0.0.0.0
#开启持久化
appendonly yes
# 设置密码
requirepass "123456"
#配置哨兵的访问此服务名的密码
masterauth 123456
2.配置从服务器
# 使得Redis服务器可以跨网络访问(直接注释也行)
bind 0.0.0.0
#开启持久化
appendonly yes
# 设置密码
requirepass "123456"
# 指定主服务器,注意:有关slaveof的配置只是配置从服务器,主服务器不需要配置
slaveof 192.168.11.128 6379
# 主服务器密码,注意:有关slaveof的配置只是配置从服务器,主服务器不需要配置
masterauth 123456
3.配置一个哨兵(配置sentinel.conf,这个配置文件一般都是在安装目录下)
#哨兵端口
port 26380
# 禁止保护模式
protected-mode no
# 配置监听的主服务器,这里sentinel monitor代表监控,mymaster代表服务器的名称,可以自定义,192.168.11.128代表监控的主服务器,6379代表端口,2代表只有两个或两个以上的哨兵认为主服务器不可用的时候,才会进行failover操作。
sentinel monitor mymaster 192.168.11.128 6379 2
# sentinel author-pass定义服务的密码,mymaster是服务名称,123456是Redis服务器密码
# sentinel auth-pass <master-name> <password>
sentinel auth-pass mymaster 123456
哨兵docker配置
这边有个注意点,docker部署启动容器网络需要使用桥接模式host
进入容器
docker exec -it redis /bin/bash
#cd / (进入根目录)
#apt-get update (更新依赖)
#apt-get install -y vim (安装vim)
#vim sentinel.conf (建立sentinel配置文件保存退出,内容如下)
启动哨兵
redis-sentinel sentinel.conf
如果配置,主服务器(master)出现故障后,哨兵选举新的主服务器(master)
的时间默认为3分钟
要想配置这个时间,我们先来了解下redis哨兵的选举机制
1、主观下线
Sentinel集群的每一个Sentinel节点会定时对redis集群的所有节点发心跳包检测节点是否正常。如果一个节点在down-after-milliseconds
时间内没有回复Sentinel节点的心跳包,则该redis节点被该Sentinel节点主观下线。
2、客观下线
当节点被一个Sentinel节点记为主观下线时,并不意味着该节点肯定故障了,还需要Sentinel集群的其他Sentinel节点共同判断为主观下线才行。
该Sentinel节点会询问其他Sentinel节点,如果Sentinel集群中超过quorum
数量的Sentinel节点认为该redis节点主观下线,则该redis客观下线。
如果客观下线的redis节点是从节点或者是Sentinel节点,则操作到此为止,没有后续的操作了;如果客观下线的redis节点为主节点,则开始故障转移,从从节点中选举一个节点升级为主节点。
3、Sentinel集群选举Leader
如果需要从redis集群选举一个节点为主节点,首先需要从Sentinel集群中选举一个Sentinel节点作为Leader。
每一个Sentinel节点都可以成为Leader,当一个Sentinel节点确认redis集群的主节点主观下线后,会请求其他Sentinel节点要求将自己选举为Leader。被请求的Sentinel节点如果没有同意过其他Sentinel节点的选举请求,则同意该请求(选举票数+1),否则不同意。
如果一个Sentinel节点获得的选举票数达到Leader最低票数(quorum
和Sentinel节点数/2+1
的最大值),则该Sentinel节点选举为Leader;否则重新进行选举。
4、Sentinel Leader决定新主节点
当Sentinel集群选举出Sentinel Leader后,由Sentinel Leader从redis从节点中选择一个redis节点作为主节点:
- 过滤故障的节点
- 选择优先级
slave-priority
最大的从节点作为主节点,如不存在则继续 - 选择复制偏移量(数据写入量的字节,记录写了多少数据。主服务器会把偏移量同步给从服务器,当主从的偏移量一致,则数据是完全同步)最大的从节点作为主节点,如不存在则继续
- 选择
runid
(redis每次启动的时候生成随机的runid
作为redis的标识)最小的从节点作为主节点
了解了选举机制我们来看看sentinel.conf的具体配置
1.
sentinel down-after-milliseconds <master-name> <milliseconds>
sentinel down-after-milliseconds mymaster 30000
这个配置项指定了需要多少失效时间,一个master才会被这个sentinel主观地认为是不可用的。 单位是毫秒,默认为30秒
sentinel parallel-syncs <master-name> <numslaves>
这个配置项指定了在发生failover主备切换时最多可以有多少个slave同时对新的master进行 同步,这个数字越小,完成failover所需的时间就越长,但是如果这个数字越大,就意味着越 多的slave因为replication而不可用。可以通过将这个值设为 1 来保证每次只有一个slave 处于不能处理命令请求的状态。