38.RocketMQ之Broker的主从架构

这篇具有很好参考价值的文章主要介绍了38.RocketMQ之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秒或几十秒的时间,这样的话就实现了主从切换的自动化了。文章来源地址https://www.toymoban.com/news/detail-545606.html

到了这里,关于38.RocketMQ之Broker的主从架构的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • RocketMQ源码阅读-Broker消息接收

    Broker接收 Producer 发送的消息。 Broker在RocketMQ中也是一个独立的Model,rocketmq-broker。 Broker的核心类为SendMessageProcessor。 同样从单元测试入手,看Broker接收消息的流程。 SendMessageProcessor的单元测试类为org.apache.rocketmq.broker.processor.SendMessageProcessorTest。 包含上面这些方法,其中ini

    2024年01月17日
    浏览(33)
  • [RocketMQ] Broker启动流程源码解析 (二)

    1.Brocker介绍 Broker主要负责消息的存储、投递和查询以及服务高可用保证, Broker包含了以下几个重要子模块。 Remoting Module: 整个Broker的实体, 负责处理来自Client端的请求 Client Manager: 负责管理客户端 Producer和Consumer, 维护Consumer的Topic订阅信息 Store Service: 提供方便简单的API接口处理

    2024年02月09日
    浏览(53)
  • RocketMQ的学习历程(5)----broker内部设计

    在首个学习历程中,我们已经了解了,RokctMQ简单的工作流程。 如果想要更深的理解RokcetMQ消息处理的流程,broker内部流程的理解是必要的, 这里我们就了解一下Broker内部的工作流程。 当Consumer消费消息时,需要先读取ConsumeQueue得到offset,再通过offset找到CommitLog对应的消息内

    2024年02月07日
    浏览(39)
  • rocketMQ5.0启动broker报错:module java.base does not export sun.nio.ch to unnamed module

    最近在搭建RocketMQ5.0,然后按照官方流程:https://rocketmq.apache.org/zh/docs/quickStart/02quickstart 先启动namesrv完,再启动broker的时候遇到以下错误。 之前大家如果搭建过老版本的RocketMQ基本都遇到过,因为使用jdk版本高的原因,jdk1.8以上涉及到导包的问题,所以RocketMQ启动命令不兼容

    2024年02月12日
    浏览(45)
  • [RocketMQ] Broker asyncSendMessage处理消息以及自动创建Topic (十)

    asyncSendMessage方法用来处理来自producer发送的消息。 1.asyncSendMessage异步处理单条消息 调用preSend方法创建响应的命令对象, 包括自动创建topic的逻辑, 随后创建响应头对象。 随后创建MessageExtBrokerInner对象, 从请求中获取消息的属性并设置到对象属性中, 消息体, topic。 判断如果是重

    2024年02月12日
    浏览(35)
  • [RocketMQ] Broker CommitLogDispatcher 异步构建ConsumeQueue和IndexFile源码解析 (十四)

    CommitLogDispatcherBuildConsumeQueue: 异步构建ConsumerQueue。 CommitLogDispatcherBuildIndex: 异步构建IndexFile。 1.CommitLogDispatcherBuildConsumeQueue构建ConsumeQueue CommitLogDispatcherBuildConsumeQueue用于接收分发请求并构建ConsumeQueue。 对于非事务消息或者是事务commit消息, 调用DefaultMessageStore#putMessagePositionI

    2024年02月17日
    浏览(42)
  • [RocketMQ] Broker asyncPutMessage处理消息以及存储的高性能设计措施 (十一)

    asyncPutMessage方法真正的用来存储消息。 1.asyncPutMessage存储普通消息 DefaultMessageStore#asyncPutMessage() checkStoreStatus, checkMessage, checkLmqMessage校验。 CommitLog#asyncPutMessage存储消息, 更新耗时时间和失败次数。 1.1 checkStoreStatus检查存储状态 如果DefaultMessageStore是shutdown状态, 返回SERVICE_NOT_

    2024年02月13日
    浏览(49)
  • RocketMQ如何实现消息轨迹:消息何时发送的?耗时多久?谁消费的?存在哪个broker了?

    更多RocketMQ内容,见专栏:https://blog.csdn.net/saintmm/category_11280399.html 消息轨迹简单来说就是日志,其把消息的生产、存储、消费等所有的访问和操作日志。 在项目中存在发送方与消费方相互“扯皮”的情况: 发送方说消息已经发送成功,而消费方说没有消费到。 这时我们就希

    2024年01月17日
    浏览(52)
  • rocketMq启动broker报错找不到或无法加载主类 Files\Java\jdk1.8.0_171\lib\dt.jar;C:\Program]

    假如弹出提示框提示‘错误: 找不到或无法加载主类 xxxxxx’。 将\\\"%CLASSPATH%\\\"加上英文双引号,切勿别加中文双引号 同理 将\\\"%CLASSPATH%\\\"加上英文双引号,切勿别加中文双引号 start mqbroker.cmd -n 127.0.0.1:9876 autoCreateTopicEnable=true

    2024年02月12日
    浏览(60)
  • 【RocketMq系列-02】RocketMq的架构解析和高性能设计

    RocketMq系列整体栏目 内容 链接地址 【一】RocketMq安装和基本概念 https://zhenghuisheng.blog.csdn.net/article/details/134486709 【二】RocketMq的架构解析和高性能设计/font https://zhenghuisheng.blog.csdn.net/article/details/134559514 在rocketMq中,其整体架构如下,在RocketMqServer中,主要有NameServer,Broker,

    2024年02月05日
    浏览(50)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包