Redis配置哨兵及其机制

一、Redis哨兵诞生背景

在Redis主从复制的场景下,如果从库宕机,主库以及其它从库可以正常工作。但是主库挂掉后,虽然从库可以继续为客户端提供读请求,但是,却没有实例来继续完成读请求了。

在这里插入图片描述
主库挂掉后数据该往哪写?如何保证业务的可持续运行?

这儿就需要Redis的哨兵来解决了。

二、关于哨兵

哨兵是一个独立的 Redis 进程,示例:

[root@iZ2zehs3cdd8rznk6ueeisZ ~]# ps aux | grep redis
redis    3040441  0.0  0.1  61984  4376 ?        Ssl  Nov11   3:21 /www/server/redis/src/redis-server 127.0.0.1:6379
root     3419825  0.0  0.3  61984 12832 pts/1    Sl+  08:52   0:00 /www/server/redis/src/redis-sentinel *:26379 [sentinel]
root     3419889  0.0  0.0  12132  1144 pts/2    S+   08:52   0:00 grep --color=auto redis

Sentinel(哨兵) 是用于监控 Redis 的主从实例,是 Redis 高可用的一个解决方案。当 Master 服务宕机后,能通过其余的 Slave 服务来选举出新的 Master 服务。解决了主从同步过程中主库宕机的问题。

三、哨兵机制的基本流程

哨兵主要的三个任务:监控、选主(选举新的主库)、通知。

在这里插入图片描述

3.1 监控

监控是指哨兵在运行的过程中,周期性的给所有主从库发送 PING 命令,检测它们是否在线。

如果从库没有在规定时间响应哨兵的 PING 命令, 哨兵就会把它标记为 下线状态

同样,如果主库没有在规定时间相应哨兵的 PING 命令,哨兵就会判断主库下线,然后进行 自动切换主库 的流程。

3.2 选主

这个流程是哨兵的第二个任务。

当主库挂掉后,哨兵会在多个从库中,按照一个规则选出一个新的主库。

3.3 通知

通知是哨兵执行的最后一个任务。

哨兵会把新主库的连接信息发给其他从库,让它们执行 replicaof 命令,和新主库建立连接,并进行数据复制。同时,哨兵会把新主库的连接信息通知给客户端,让它们把请求操作发到新主库上。

四、关于主观下线和客观下线

哨兵的第一个任务就是监控,在监控的过程中有两个概念:主观下线和客观下线。

4.1 主观下线

哨兵进程会使用 PING 命令检测它自己和主、从库的网络连接情况,用来判断实例的状态。如果哨兵发现主库或从库对 PING 命令的响应超时了,那么,哨兵就会先把它标记为 主观下线

如果检测的是从库,那么,哨兵简单地把它标记为 主观下线 就行了,因为从库的下线影响一般不太大,集群的对外服务不会间断。

4.2 客观下线

但是如果检测的是主库,那么就不能简单的标记为客观下线了,因为在特殊的情况下哨兵会误判,导致进行主从切换,本来主库没问题的,一旦进行切换,会造成多余的计算及开销。

关于造成误判的原因:

  • 集群网络压力较大
  • 主库读写压力大
  • 网络延迟

如何避免这个问题呢?那就需要标记为客观下线了。

客观下线是所有哨兵一起判断,多数人认为主库下线了,才算真下线,才能进行后续切换。

引入多个哨兵实例一起来判断,就可以避免单个哨兵因为自身网络状况不好,而误判主库下线的情况。同时,多个哨兵的网络同时不稳定的概率较小,由它们一起做决策,误判率也能降低。

在这里插入图片描述

多数服从少数,当有 N 个哨兵实例时,最好要有 N/2 + 1 个实例判断主库为 主观下线,才能最终判定主库为 客观下线

五、选主规则

选主的时候,主要过程是:筛选 + 打分

先筛选掉一部分不符合规则的从库,在对剩下的从库进行打分,得分高者将成为主库。

在这里插入图片描述

在筛选的过程中,不但要看当前从库的状态,如果从库当前的状态是连接状态,那么不能说明当前从库的状态就是好的。例如,选了这个当前正在连接状态的从库,但是以前的网络状态不好,导致它成为了主库后,很快就宕机了,这就不符合我们的预期了。

因此,除了判断当前实例的网络状态,还要要先进行判断之前的网络状态。

接下来就要给剩余的从库打分了。

5.1 优先级最高的从库得分高

用户可以通过 slave-priority 配置项,给不同的从库设置不同优先级。

在选主时,哨兵会给优先级高的从库打高分,如果有一个从库优先级最高,那么它就是新主库了。如果从库的优先级都一样,那么哨兵开始第二轮打分。

5.2 和旧主库同步程度最接近的从库得分高

主从库同步时有个命令传播的过程。在这个过程中,主库会用 master_repl_offset 记录当前的最新写操作在 repl_backlog_buffer 中的位置,而从库会用 slave_repl_offset 这个值记录当前的复制进度。

此时,我们想要找的从库,它的 slave_repl_offset 需要最接近 master_repl_offset。如果在所有从库中,有从库的 slave_repl_offset 最接近 master_repl_offset,那么它的得分就最高,可以作为新主库。

就像下图所示,旧主库的 master_repl_offset 是 1000,从库 1、2 和 3 的 slave_repl_offset 分别是 950、990 和 900,那么,从库 2 就应该被选为新主库。

在这里插入图片描述

如果有两个从库的 slave_repl_offset 值大小是一样的(例如,从库 1 和从库 2 的 slave_repl_offset 值都是 990),我们就需要给它们进行第三轮打分了。

5.3 ID 号小的从库得分高

每个实例都会有一个 ID,这个 ID 就类似于这里的从库的编号。目前,Redis 在选主库时,有一个默认的规定:在优先级和复制进度都相同的情况下,ID 号最小的从库得分最高,会被选为新主库。

六、配置流程

首先,先搞好主从同步,我搞了四台服务器,配置了一主三从。

关于 Redis 搭建主从同步:链接: Redis 搭建主从同步

修改四台服务器中的配置文件:sentinel.conf(通常该文件和 redis.conf 同目录)

四台服务器中配置相同几乎一样,本示例只为了实现该效果,如果在生产环境中搭建,需要根据自己的业务需求来配置不同的参数项。

sentinel.conf

sentinel announce-ip 39.101.1.111 #很多人测试是用的一台服务器,多个不同端口的redis服务,我这边是多个服务器,因此要指定当前ip,不同服务器用不同的当前IP。
sentinel monitor mymaster 39.101.1.111 6379 2 # 指定主库IP地址以及端口

四台服务器的 sentinel.conf 编辑完后,各自启动:/www/server/redis/src/redis-sentinel sentinel.conf

在这里插入图片描述

七、总结

Redis 哨兵是为了解决 Redis 主从同步的时候宕机问题,是 Redis一种高可用的实现方案。

但是哨兵也会宕机,这时候又需要 Redis集群来解决了……

参考文档:https://time.geekbang.org/column/article/274483

  • 1
    点赞
  • 7
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值