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

本文涉及的产品
云数据库 Redis 版,社区版 2GB
推荐场景:
搭建游戏排行榜
简介: 接上文。

哨兵集群工作原理


「哨兵」部门并不是一个人,多个人共同组成一个「哨兵集群」,即使有一些「哨兵」被老王打死了,其他的「哨兵」依然可以共同协作完成监控、新掌门选举以及通知 slave 、master 以及每一个武林人士(客户端)。


在配置哨兵集群的时候,哨兵配置中只设置了监控的 master IP 和 port,并没有配置其他哨兵的连接信息。


sentinel monitor <master-name> <ip> <redis-port> <quorum>


哨兵之间是如何知道彼此的?如何知道 slave 并监控他们的?由哪一个「哨兵」执行主从切换呢?


带着这些问题,跟着「码哥字节」一起追本溯源,深入哨兵集群心脏。


pub/sub 实现哨兵间通信和发现 slave


65 哥:哨兵之间是如何知道彼此的?


哨兵之间可以相互通信约会搞事情,主要归功于 Redis 的 pub/sub 发布/订阅机制。


哨兵与 master 建立通信,利用 master 提供发布/订阅机制发布自己的信息,比如身高体重、是否单身、IP、端口……


master 有一个 __sentinel__:hello 的专用通道,用于哨兵之间发布和订阅消息。这就好比是 __sentinel__:hello 微信群,哨兵利用 master 建立的微信群发布自己的消息,同时关注其他哨兵发布的消息


image.png


当多个哨兵实例都在主库上做了发布和订阅操作后,它们之间就能知道彼此的 IP 地址和端口,从而相互发现建立连接。


Redis 通过频道的方式对消息进行分别管理,这里的频道其实就是不同的微信群。比如“码哥字节读者技术群”就是专门分享技术的群。朋友们可以关注公众号,后台回复“加群”,一起成长。


65 哥:哨兵之间虽然建立连接了,但是还需要和 slave 建立连接,不然没法监控他们呀,如何知道 slave 并监控他们的?


的确,哨兵之间建立连接形成集群还不够,还需要跟 slave 建立连接,不然没法监控他们,无法对主从库进行心跳判断。


除此之外,如果发生了主从切换也得通知 slave 重新跟新 master 建立连接执行数据同步。关于主从架构数据同步原理可移步《Redis 高可用篇:你管这叫主从架构数据一致性同步》。


关键还是利用 master 来实现,哨兵向 master 发送 INFO 命令, master 掌门自然是知道自己门下所有的 salve 小弟的。所以 master 接收到命令后,便将 slave 列表告诉哨兵。


哨兵根据 master 响应的 slave 名单信息与每一个 salve 建立连接,并且根据这个连接持续监控哨兵。


如图所示,哨兵 2 向 Master 发送 INFO 命令,Master 就把 slave 列表返回给哨兵 2,哨兵 2 便根据 slave 列表连接信息与每一个 slave 建立连接,并基于此连接实现持续监控。


剩下的哨兵也同理基于此实现监控。


image.png


选择哨兵执行主从切换


65 哥:master 嗝屁了以后,哨兵这么多,那到底让哪一个哨兵来执行新 master 切换呢?


这个跟哨兵判断 master “客观下线”类似,也是通过投票的方式选出来的。


任何一个哨兵判断 master “主观下线”后,就会给其他哨兵基友发送 is-master-down-by-addr 命令,好基友则根据自己跟 master 之间的连接状况分别响应 Y 或者 NY 表示赞成票, N 就是反对。


如果某个哨兵获得了大多数哨兵的“赞成票”之后,就可以标记 master 为 “客观下线”,赞成票数是通过哨兵配置文件中的 quorum 配置项设定。


sentinel monitor <master-name> <ip> <redis-port> <quorum>


比如一共 3 个哨兵组成集群,那么 quorum 就可以配置成 2,当一个哨兵获得了 2 张赞成票,就可以标记 master “客观下线”,当然这个票包含自己的那一票。


获得多数赞成票的哨兵可以向其他哨兵发送命令,申明自己想要执行主从切换。并让其他哨兵进行投票,投票过程就叫做 “Leader 选举”。


想要成为 “Leader”没那么简单,得有两把刷子。需要满足以下条件:


  1. 获得其他哨兵基友过半的赞成票;


  1. 赞成票的数量还要大于等于配置文件的 quorum 的值。


如果哨兵集群有 2 个实例,此时,一个哨兵要想成为 Leader,必须获得 2 票,而不是 1 票。所以,如果有个哨兵挂掉了,那么,此时的集群是无法进行主从库切换的。因此,通常我们至少会配置 3 个哨兵实例。


这也是为啥哨兵集群部署成单数的原因,双数的话多余浪费。


选举流程如下图所示:


image.png


通过 pub/sub 实现客户端事件通知


65 哥:新 master 选出来了,要怎么公示天下呢?


当然是召开新闻发布会呀,邀请消息相关类型的媒体报道传播,感兴趣的人自然就去关注订阅相关事件,并根据事件做出行动。


在 Redis 也是类似,通过 pub/sub 机制发布不同事件,让客户端在这里订阅消息。客户端可以订阅哨兵的消息,哨兵提供的消息订阅频道有很多,不同频道包含了主从库切换过程中的不同关键事件。

也就是在不同的“微信群”发布不同的事件,让对该事件感兴趣的人进群即可。


master 下线事件


  • +sdown:进入“主观下线”状态;


  • -sdown:退出“主观下线”状态;


  • +odown:进入“客观下线”状态;


  • -odown:退出“客观下线”状态;


slave 重新配置事件


  • +slave-reconf-sent:哨兵发送 replicaof 命令重新配置从库;


  • +slave-reconf-inprog:slave 配置了新 master,但是尚未进行同步;


  • +slave-reconf-done:slave 配置了新 master,并与新 master 完成了数据同步;


新主库切换


+switch-master:master 地址发生了变化。


知道了这些频道之后,就可以让客户端从哨兵这里订阅消息了。客户端读取哨兵的配置文件后,可以获得哨兵的地址和端口,和哨兵建立网络连接。


然后,我们可以在客户端执行订阅命令,来获取不同的事件消息。


举个栗子:如下指令订阅“所有实例进入客观下线状态的事件”


SUBSCRIBE +odown


注意事项与配置说明


发现了没,Redis 的 pub/sub 发布订阅机制尤其重要,有了 pub/sub 机制,哨兵和哨兵之间、哨兵和从库之间、哨兵和客户端之间就都能建立起连接了,各种事件的发布也是通过这个机制实现。


down-after-milliseconds


Sentinel 配置文件中的 down-after-milliseconds 选项指定了 Sentinel 判断实例进入主观下线所需的时间长度:如果一个实例在 down-after-milliseconds 毫秒内,连续向 Sentinel 返回无效回复,那么 Sentinel 会修改这个实例所对应数据,以此来表示这个实例已经进入主观下线状态。


要保证所有哨兵实例的配置是一致的,尤其是主观下线的判断值 down-after-milliseconds。因为这个值在不同的哨兵实例上配置不一致,导致哨兵集群一直没有对有故障的主库形成共识,也就没有及时切换主库,最终的结果就是集群服务不稳定


down-after-milliseconds * 10


down-after-milliseconds 是我们认定主从库断连的最大连接超时时间。如果在 down-after-milliseconds 毫秒内,主从节点都没有通过网络联系上,我们就可以认为主从节点断连了。如果发生断连的次数超过了 10 次,就说明这个从库的网络状况不好,不适合作为新主库。


总结


哨兵主要任务


Redis 哨兵机制是实现 Redis 不间断服务的高可用手段之一。主从架构集群的数据同步,是数据可靠的基础保障;主库宕机,自动执行主从切换是服务不间断的关键支撑。


Redis 哨兵机制实现了主从库的自动切换,再也不怕跟女盆友么么哒的时候 master 宕机了:


  • 监控 master 与 slave 运行状态,判断是否客观下线;


  • master 客观下线后,选择一个 slave 切换成 master;


  • 通知 slave 和客户端新 master 信息。


哨兵集群原理


为了避免单个哨兵故障后无法进行主从切换,以及为了减少误判率,又引入了哨兵集群;哨兵集群又需要有一些机制来支撑它的正常运行:


  • 基于 pub/sub 机制实现哨兵集群之间的通信;


  • 基于 INFO 命令获取 slave 列表,帮助 哨兵与 slave 建立连接;


  • 通过哨兵的 pub/sub,实现了与客户端和哨兵之间的事件通知。


主从切换,并不是随意选择一个哨兵就可以执行,而是通过投票仲裁,选择一个 Leader,由这个 Leader 负责主从切换。

相关实践学习
基于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
相关文章
|
20天前
|
编解码 算法 定位技术
GEE时序——利用sentinel-2(哨兵-2)数据进行地表物候学分析(时间序列平滑法估算和非平滑算法代码)
GEE时序——利用sentinel-2(哨兵-2)数据进行地表物候学分析(时间序列平滑法估算和非平滑算法代码)
29 3
|
20天前
|
存储 编解码 人工智能
GEE数据集——哨兵2号Sentinel-2 云概率数据集
GEE数据集——哨兵2号Sentinel-2 云概率数据集
20 2
|
23天前
|
NoSQL Redis Docker
关于redis的一主三从三哨兵的实现
关于redis的一主三从三哨兵的实现
16 0
|
28天前
|
监控 NoSQL 程序员
Redis 高可用篇:你管这叫 Sentinel 哨兵集群原理
Redis 高可用篇:你管这叫 Sentinel 哨兵集群原理
70 5
|
28天前
|
NoSQL Linux Redis
Redis 6.X Sentinel 哨兵集群搭建
Redis 6.X Sentinel 哨兵集群搭建
23 5
|
2月前
|
NoSQL Java Redis
SpringBoot2.0整合Redis高可用之Sentinel哨兵
本篇博文分享的是一主二从三哨兵模式。至于为什么用三个哨兵,同第一段。本文是模拟环境,都是一个服务器上面。
42 0
|
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