Redis 高可用篇:你管这叫 Sentinel 哨兵集群原理(一)

本文涉及的产品
云数据库 Redis 版,社区版 2GB
推荐场景:
搭建游戏排行榜
简介: 技术的迭代非常的快,但是从技术中沉淀下来的思维却是受益终生的。所以不要担心什么中年危机,那些担心中年危机的人通常很难成长起来。只要我们成长,只要我们的认知在不断突破,就不用担心中年危机,这个世界始终是需要那些优秀人才的。

什么是哨兵(Sentinel)


65 哥:码哥,虽然我没女朋友,但是,未雨绸缪我要掌握这个哨兵模式,防止当深夜与女朋友么么哒被打扰,你快说说哨兵的实现原理吧。


搭建实例采用三个哨兵形成集群,三个数据节点(一主两从)方式搭建,如下图所示:


image.png


65 哥你听过「武当派」创始人张三疯么?Redis 主从架构就好比一个武当,掌门人就是 Master。掌门人如果挂了,需要从武当七侠里面选举能人担当掌门人。这就需要一个部门能监控掌门人的生死和武当其他弟子的生命状态,并且能够通过投票从武当弟子中选举一个能者担任新掌门,接着再举行新闻发布会向世界宣布新掌门的信息。这个「部门」就是哨兵。


哨兵在选举新掌门会遇到以下几个问题:


  1. 如何判断掌门真的挂了,有可能假死;


  1. 到底选择哪一个武当子弟作为新掌门?


  1. 通过新闻发布会将新掌门的相关信息通知到所有武当弟子(slave 和 master)和整个武林(客户端)


哨兵部门主要负责的任务是:监控整个武当、选择新掌门,通知整个武当和整个武林。


哨兵机制的主要任务


哨兵是 Redis 的一种运行模式,它专注于对 Redis 实例(主节点、从节点)运行状态的监控,并能够在主节点发生故障时通过一系列的机制实现选主及主从切换,实现故障转移,确保整个 Redis 系统的可用性。结合 Redis 的 官方文档,可以知道 Redis 哨兵具备的能力有如下几个:


  • 监控:持续监控 master 、slave 是否处于预期工作状态。


  • 自动切换主库:当 Master 运行故障,哨兵启动自动故障恢复流程:从 slave 中选择一台作为新 master。


  • 通知:让 slave 执行 replicaof ,与新的 master 同步;并且通知客户端与新 master 建立连接。


哨兵也是一个 Redis 进程,只是不对外提供读写服务,通常哨兵要配置成单数,为啥呢?且听「码哥字节」慢慢分析。


65 哥:那到底「哨兵」这个神秘部门是如何实现这三个能力的?


我们先从全局观看哨兵,简要的了解整个运作流程,接着再针对每一个任务详细分析。首先从监控开始…...


监控


Sentinel 只是武当弟子中的特殊部门,在默认情况下,Sentinel 通过飞鸽传书以每秒一次的频率向所有武当弟子、掌门与哨兵(包括 Master、Slave、其他 Sentinel 在内)发送 PING 命令,如果 slave 没有在在规定时间内响应「哨兵」的 PING 命令,「哨兵」就认为这哥们可能嗝屁了,就会将他记录为「下线状态」;


假如 master 掌门没有在规定时间响应 「哨兵」的 PING 命令,哨兵就判定掌门下线,开始执行「自动切换 master 掌门」的流程。


PING 命令的回复有两种情况:


  1. 有效回复:返回 +PONG、-LOADING、-MASTERDOWN 任何一种;


  1. 无效回复:有效回复之外的回复,或者再指定时间内返回任何回复。


65 哥:哨兵如何判断「掌门」嗝屁呢?掌门诈尸咋办?


为了防止掌门「假死」,「哨兵」设计了「主观下线」和「客观下线」两种暗号。


主观下线


哨兵利用 PING 命令来检测掌门、 slave 的生命状态。如果是无效回复,哨兵就把这个哥们标记为「主观下线」。检测到的是武当小弟,也就是 slave 角色。那么就直接标记「主观下线」。


因为 master 掌门还在,slave 的嗝屁对整个武当影响不大。依然可以对外开会,比武论剑、吃香喝辣…...


如果检测到是 master 掌门完蛋,这时候哨兵不能这么简单的标记「主观下线」,开启新掌门选举。


因为有可能出现误判,掌门并没有嗝屁,一旦启动了掌门切换,后续的选主、通知开发布会,slave 花时间与新 master 同步数据都会消耗大量资源。


所以「哨兵」要降低误判的概率,误判一般会发生在集群网络压力较大、网络拥塞,或者是主库本身压力较大的情况下。


既然一个人容易误判,那就多个人一起投票判断。哨兵机制也是类似的,采用多实例组成的集群模式进行部署,这就是哨兵集群。引入多个哨兵实例一起来判断,就可以避免单个哨兵因为自身网络状况不好,而误判主库下线的情况。


同时,多个哨兵的网络同时不稳定的概率较小,由它们一起做决策,误判率也能降低。


客观下线


判断 master 是否下线不能只有一个「哨兵」说了算,只有过半的哨兵判断 master 已经「主观下线」,这时候才能将 master 标记为「客观下线」,也就是说这是一个客观事实,掌门真的嗝屁了,华佗再世也治不好了。


只有 master 被判定为「客观下线」,才会进一步触发哨兵开始主从切换流程。


image.png


主观下线与客观下线的区别


简单来说,主观下线是哨兵自己认为节点宕机,而客观下线是不但哨兵自己认为节点宕机,而且该哨兵与其他哨兵沟通后,达到一定数量的哨兵都认为该哥们嗝屁了。


这里的「一定数量」是一个法定数量(Quorum),是由哨兵监控配置决定的,解释一下该配置:


# sentinel monitor <master-name> <master-host> <master-port> <quorum>
# 举例如下:
sentinel monitor mymaster 127.0.0.1 6379 2


这条配置项用于告知哨兵需要监听的主节点:


  • sentinel monitor:代表监控。


  • mymaster:代表主节点的名称,可以自定义。


  • 192.168.11.128:代表监控的主节点 ip,6379 代表端口。


  • 2:法定数量,代表只有两个或两个以上的哨兵认为主节点不可用的时候,才会把 master 设置为客观下线状态,然后进行 failover 操作。


「客观下线」的标准就是,当有 N 个哨兵实例时,要有 N/2 + 1 个实例判断 master 为「主观下线」,才能最终判定 Master 为「客观下线」,其实就是过半机制。


自动切换主库


65 哥:既然判断 master 客观下线了,那就要从选出一个新掌门人了吧。


「哨兵」的第二个任务,选择新 master 掌门。需要从武当弟子中按照一定规则选择一个牛逼人物作为新掌门,完成选任掌门后,新 master 带领众弟子一起吃香喝辣。


按照一定的「筛选条件」 + 「打分」策略,选出「最强王者」担任掌门,也就是通过一些条件海选过滤一些「无能之辈」,接着将通过海选的靓仔全都打分排名,将最高者选为新 master。


如图所示:


image.png


网络经常断开的靓仔也不可取,你想,即使变成 master,可是很快网络出了故障,又得重新选择新 master,这不闹着玩么,得排除掉!


筛选条件


65 哥:那都有哪些筛选条件呀?


  • 从库当前在线状态,下线的直接丢弃;


  • 评估之前的网络连接状态 down-after-milliseconds * 10:如果从库总是和主库断连,而且断连次数超出了一定的阈值(10 次),我们就有理由相信,这个从库的网络状况并不是太好,就可以把这个从库筛掉了。


打分


过滤掉不合适的 slave 之后,则进入打分环节。打分会按照三个规则进行三轮打分,规则分别为:


  1. slave 优先级,通过 slave-priority 配置项,给不同的从库设置不同优先级(后台有人没办法),优先级高的直接晋级为新 master 掌门。


  1. slave_repl_offsetmaster_repl_offset进度差距(谁的武功与之前掌门的功夫越接近谁就更牛逼),如果都一样,那就继续下一个规则。其实就是比较 slave 与旧 master 复制进度的差距;


  1. slave runID,在优先级和复制进度都相同的情况下,ID 号最小的从库得分最高,会被选为新主库。 (论资排辈,根据 runID 的创建时间来判断,时间早的上位);


通知


65 哥:为哈还要召开新闻发布会呢?


重新选举新 master 掌门这种事情,何等大事,怎能不告知天下。再者其他 slave 弟子也要知道新掌门是谁,一起追随新掌门吃香喝辣大保健。


最后一个任务,「哨兵」将新 「master 掌门」的连接信息发送给其他 slave 武当弟子,并且让 slave 执行 replacaof 命令,和新「master 掌门」建立连接,并进行数据复制学习新掌门的所有武功。


除此之外,「哨兵」还需要将新掌门的连接信息通知整个武林(客户端),使得让所有想拜访、讨教的人能找到新任掌门,这样诸多事宜才能交给新掌门做决定(将读写请求转移到新 master)。


哨兵的主要任务与实现目标


image.png

相关实践学习
基于Redis实现在线游戏积分排行榜
本场景将介绍如何基于Redis数据库实现在线游戏中的游戏玩家积分排行榜功能。
云数据库 Redis 版使用教程
云数据库Redis版是兼容Redis协议标准的、提供持久化的内存数据库服务,基于高可靠双机热备架构及可无缝扩展的集群架构,满足高读写性能场景及容量需弹性变配的业务需求。 产品详情:https://www.aliyun.com/product/kvstore &nbsp; &nbsp; ------------------------------------------------------------------------- 阿里云数据库体验:数据库上云实战 开发者云会免费提供一台带自建MySQL的源数据库&nbsp;ECS 实例和一台目标数据库&nbsp;RDS实例。跟着指引,您可以一步步实现将ECS自建数据库迁移到目标数据库RDS。 点击下方链接,领取免费ECS&amp;RDS资源,30分钟完成数据库上云实战!https://developer.aliyun.com/adc/scenario/51eefbd1894e42f6bb9acacadd3f9121?spm=a2c6h.13788135.J_3257954370.9.4ba85f24utseFl
相关文章
|
23天前
|
运维 NoSQL 算法
Redis-Cluster 与 Redis 集群的技术大比拼
Redis-Cluster 与 Redis 集群的技术大比拼
20 0
|
28天前
|
NoSQL 前端开发 Redis
Redis 集群面试题
Redis 集群面试题
28 0
|
28天前
|
NoSQL Linux Redis
Redis 6.X Cluster 集群搭建
Redis 6.X Cluster 集群搭建
27 0
|
2月前
|
NoSQL Java Redis
SpringBoot2.0整合Redis高可用之Sentinel哨兵
本篇博文分享的是一主二从三哨兵模式。至于为什么用三个哨兵,同第一段。本文是模拟环境,都是一个服务器上面。
42 0
|
28天前
|
监控 NoSQL 程序员
Redis 高可用篇:你管这叫 Sentinel 哨兵集群原理
Redis 高可用篇:你管这叫 Sentinel 哨兵集群原理
70 5
|
2月前
|
监控 NoSQL Redis
Redis - 主从复制那些事与高可用sentinel
Redis - 主从复制那些事与高可用sentinel
30 0
|
监控 NoSQL Redis
|
NoSQL 数据可视化 Redis
Redis高可用Sentinel哨兵模式环境搭建
Redis高可用Sentinel哨兵模式环境搭建
413 0
|
监控 NoSQL Redis
Redis 高可用之 Sentinel
Redis 高可用之 Sentinel
Redis 高可用之 Sentinel