Broker的主从架构是怎么实现的?
前言
上一篇文章我们一起聊了聊RocketMQ的NameServer的一些内部工作流程,了解了NameServer的部署和与Broker之间的联系,那么今天我们就来一起聊聊Broker的一些内部原理。
Master Broker与Slave Broker之间的消息同步
看过之前文章的小伙伴们都清楚,Broker是RocketMQ的核心模块,负责接收并存储消息,为了保证整个MQ的高可用,一般情况都会将Broker部署成集群,集群中的每一部分都由Master和Slave组成,那么Master与Slave之间的数据是如何保证同步一致的呢?
是Master主动把数据推送给Slave?还是Slave主动发送请求去Master拉取最新数据?
答案是第二种,RocketMQ的内部原理就是Slave不停的向Master发送请求拉取数据,也就是说这是一种Pull模式拉取消息,而不是Push模式推送消息。
Master Broker与Slave Broker实现读写分离了吗
上边我们了解到,Master Broker主要接收来自系统的请求,之后Slave Broker会向Master Broker发出拉取请求,同步数据。那么,当系统访问Broker获取数据的时候是什么样的过程呢?如果实现了读写分离,是不是Master Broker只负责消息的写入操作,Slave Broker只负责消息的读取呢?
其实不是这样的,当读取数据的时候,是既可能在Master Broker读取数据,也可能在Slave Broker读取数据的。
作为消费者,向MQ获取数据的时候,首先与Master Broker建立连接,并发送请求获取一批消息。
而此时,Master Broker不是直接返回消息给消费者的,而是会根据Master Broker的负载情况以及Slave Broker的同步情况,向消费者建议下次应该从Master Broker获取消息还是应该从Slave Broker获取消息。
具体什么时候会建议去Master Broker获取消息呢?
举个例子,如果在一段时间内Master Broker突然新增了大量的消息,而这时Slave Broker同步这些消息也是需要一定的时间的,所以主从的数据是不一致的,为了保证读取消息的可靠性,就只能从Master Broker获取消息。
那么什么时候会建议去Slave Broker获取消息呢?
再看个例子,如果一段时间内,Master Broker由于业务原因接收了海量的并发请求,导致本身负载很重,这时对于消费者新发来的请求,如果继续从Master Broker获取消息,就会导致性能很慢,而且增加Master Broker服务器的压力,所以这个时候就会建议从Slave Broker获取消息了。
所以我们总结出来,当写入消息的时候,一般是选择Master Broker来写入的,而对于读取消息,从哪里获取数据,要视当时情况而定。所以不能说是完全的读写分离。
如果Slave Broker宕机怎么办
现在我们想想,如果Slave Broker宕机了,对于整体MQ系统来讲,会有多大的影响?
实际上,这种情况是没有太大的影响的,因为我们刚刚已经知道,所有的写请求都会发送给Master Broker,而所有的读请求通过Master Broker也可以进行下去。
所以Slave Broker宕机了,其实不影响整个MQ的运行过程,如果非要说出个影响了,那就是可供读取消息的机器少了一台而已,如果这时候出现海量并发读取消息的情况,性能会变差。
所以,Slave Broker宕机,一般会有监控系统监控的到,维护人员及时手动处理重新启动就可以了。
如果Master Broker宕机怎么办
现在我们假设,Master Broker突然宕机了,对于MQ整体上有什么影响呢.
这种情况对于消息的写入和读取就会产生影响了。但是我们知道,在Slave Broker上是有一份与Master Broker相同的备份数据的,只不过可能存在消息同步的过程中宕机的情况,导致部分数据丢失。
那么RocketMQ可以自动将Slave切换为Master吗?答案是否定的。
在RocketMQ4.5之前,一旦Master发生故障,Slave是没法自动切换成Master提供服务的。
在这种情况下,就需要运维人员手动修改Slave Broker的配置,重启服务将其切换为Master,这样不仅过程麻烦,而且中途还会发生服务不可用的状况,没有真正的实现高可用。
Dledger实现RocketMQ的高可用
在RocketMQ4.5后,针对于上边说到的情况有了新的解决方案,就是Dledger。
小伙伴们一定会问,Dledger是什么呢?
Dledger是一个基于Raft协议实现的机制,暂时知道这里就可以了,至于什么是Raft,Dledger原理这里就先不聊了,那又是一个大的话题,感兴趣的小伙伴可以自行百度了解。
我们主要要聊的是基于Dledger可以实现RocketMQ的高可用主从自动切换效果。
简单的解释一下,就是当Master Broker宕机的时候,就可以在多个Slave Broker中根据Dledger机制进行leader选举,选出一个新的Master对外继续提供服务。整个过程可能在10秒或几十秒的时间,这样的话就实现了主从切换的自动化了。
总结
今天我们主要聊了聊Broker的主从架构,下边的文章我们将继续探索RocketMQ的生产部署架构,欢迎小伙伴们持续关注。
往期文章推荐:
中间件专辑:
算法专辑:
最新文章
- 安装zeppelin
- 一. DotNet MVC4.0+EasyUI Web简单框架-前言
- 跨浏览器事件EventUtil
- PHP中的 extends与implements 区别 [转]
- loj 1055(bfs)
- 解决:warning LNK4098: 默认库“MSVCRT”与其他库的使用冲突;找到 MSIL .netmodule 或使用 /GL 编译的模块;正在。。;LINK : warning LNK4075: 忽略“/INCREMENTAL”(由于“/LTCG”规范)
- 11、NFC技术:NDEF Uri格式解析
- ASP.NET C# 文件下载
- ext3文件系统,reiserfs,xfs,jsf那种性能好点
- css重点
- [编程语言][java][java se]java泛型中? T K V E含义(学习)
- iOS·UIKit框架注解 &; Foundation
- 博弈论(Game Theory) - 04 - 纳什均衡
- 详解Vue 开发模式下跨域问题
- tp5框架中jquery+ajax分页
- java后端导出excel表格
- Java 编程下正则表达式判断字符串是否包含中文
- 深入理解Java类加载器(1)
- 7 SQL优化技术
- C#中HttpWebRequest的GetRequestStream执行的效率太低,甚至偶尔死掉
热门文章
- MySql实现 split
- 解决 SQLException: Value '0000-00-00 00:00:00' can not be represented as java.sql.Timestamp的问题
- 【Canal】数据同步的终极解决方案,阿里巴巴开源的Canal框架当之无愧!!
- JS与React分别实现倒计时(天时分秒)
- java 序列化流与反序列化流
- 商业分析-04行为&;业务相关数据指标
- MyKTV系统项目的感想
- 怎么把txt转换成excel
- kafka-clients 1.0 内部响应接口文档
- Istio Routing 实践掌握virtualservice/gateway/destinationrule/AB版本发布/金丝雀发布