前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >深入研究RocketMQ生产者发送消息的底层原理

深入研究RocketMQ生产者发送消息的底层原理

作者头像
HUC思梦
发布2020-09-24 15:56:00
9110
发布2020-09-24 15:56:00
举报

前言

hello,小伙伴们,王子又来和大家研究RocketMQ的原理了,之前的文章RocketMQ生产部署架构如何设计中,我们已经简单的聊过了生产者是如何发送消息给Broker的。

我们简单回顾一下这个过程。

生产者首先声明一个Topic,然后为了把消息存到对应的Topic中,先从NameServer拉取注册信息获取到Topic存放在哪个Broker中,然后就可以访问对应的Broker发送消息了。

大体流程就是这样,那么这个过程中具体都发生了什么呢,王子今天就和大家深入的探讨一下这其中的奥秘。

什么是MessageQueue

要弄明白生产者发送消息的原理,先要理解什么是MessageQueue。

在生产者声明Topic的时候,是要指定一个关键的参数的,就是MessageQueue,就是指定了你的Topic里面包含几个MessageQueue。

那么这个MessageQueue是做什么用的呢?

直接翻译过来就是消息队列,那么就可以理解成一个Topic对应多个MessageQueue,然后把消息存放到Topic下的消息队列中。

其实Topic、MessageQueue、Broker之间是有关联的。

现在假设我们有一个Topic,指定了它有4个MessageQueue,那么这个Topic在分布式的Broker中是如何存储的呢?

前面的文章我们就聊过,Topic的数据是分布式存储在多个Broker中的,如下图:

那么Topic中的一部分数据是通过什么渠道存储在不同的Broker集群中的呢?

相信小伙伴们都猜到了,就是通过MessageQueue,本质上来讲就是一个数据分片的机制。

假设我们的Topic中有1万条数据,那么可能会平均分布到4个MessageQueue中分片存储(这里不是绝对的,可以根据消息写入的策略来定)。

那么这4个MessageQueue又是怎么存储在Broker上的呢?

很有可能就是每个Broker上存放两个MessageQueue。所以MessageQueue是RocketMQ中非常关键的数据分片机制,实现了Topic数据的分布式存储。

生产者发送消息存入哪个MessageQueue

接下来我们思考一下,生产者发送消息的时候是如何确定存入哪个MessageQueue呢?

我们之前说过,存放消息之前,首先会从NameServer中拉取元数据,在元数据中生产者可以知道Topic有几个MessageQueue,每个MessageQueue存放在哪个Broker集群上。

然后呢,既然生产者知道了这些信息,我们暂时就认为生产者会把消息均匀的发送给当前Topic下的所有MessageQueue中。

比如一共20条消息,4个MessageQueue,那么每个MessageQueue中就存放5条消息。

至于其他的存放策略,我们之后的文章再仔细探讨。

通过这样的方式,生产者发送消息的请求就可以分布在多台的Broker上,那假设我们的每台Broker都可以抗下10万并发,两个Broker就可以抗下20万的并发。

同时,因为我们的消息数据是分片式存储在多个MessageQueue中的,MessageQueue又分布在多个Broker集群中,这样就可以保证RocketMQ存储海量消息了。

如果Broker发生故障怎么办

对于Broker发生故障这一问题,我们之前的文章已经讲过了,小伙伴们可以回顾一下:Broker的主从架构是怎么实现的?

主要使用的是4.5版本后的Dledger自动化切换主从的集群,当MasterBroker挂掉后是可以自动实现Slave到Master的转变的。

那么这里为什么我们还要谈这个问题呢?

小伙伴们想一下,如果MasterBroker挂掉了,要实现主从切换这一过程是需要时间的。

那么在切换的过程中,如果我们的生产者仍然发送消息过来,并且定位到了这台挂掉的MasterBroker,不就无法正常的写入数据了吗。

如果我们还是按照之前说的平均分发消息到MessageQueue,那么就会导致一段时间内访问到故障Broker上时全部是失败的。

对于这个问题,我们可以在生产者中开启一个开关:sendLatencyFaultEnable=true

一旦开启这个开关,它有个自动容错机制。

比如访问Broker时发现Broker响应超时或返回错误,那么在之后的一段时间里,就不会再去访问这个Broker集群了。

这样的话,当Broker发生故障,一段时间内生产者就不会频繁的访问这个发生异常的Broker集群了,过段时间后再去访问。

可能这个时候我们的主从切换已经结束了,这样再次访问的时候就正常了。

总结

今天我们主要聊了聊什么是MessageQueue,MessageQueue在RocketMQ中扮演什么角色,生产者是如何写消息到MessageQueue的,Broker发生故障生产者是如何保证自动容错的。

相信小伙伴们应该会有一些收获,那我们下期的消息中间件系列再见。

往期文章推荐:

什么是消息中间件?主要作用是什么?

常见的消息中间件有哪些?你们是怎么进行技术选型的?

你懂RocketMQ 的架构原理吗?

聊一聊RocketMQ的注册中心NameServer

Broker的主从架构是怎么实现的?

RocketMQ生产部署架构如何设计

RabbitMQ和Kafka的高可用集群原理

RocketMQ的发送模式和消费模式

讨论一下秒杀系统的技术难点与解决方案

秒杀系统中的扣减库存和流量削峰

本文参与 腾讯云自媒体分享计划,分享自作者个人站点/博客。
原始发表:2020-09-23 ,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 作者个人站点/博客 前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体分享计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • 前言
  • 什么是MessageQueue
  • 生产者发送消息存入哪个MessageQueue
  • 如果Broker发生故障怎么办
  • 总结
相关产品与服务
消息队列 CMQ 版
消息队列 CMQ 版(TDMQ for CMQ,简称 TDMQ CMQ 版)是一款分布式高可用的消息队列服务,它能够提供可靠的,基于消息的异步通信机制,能够将分布式部署的不同应用(或同一应用的不同组件)中的信息传递,存储在可靠有效的 CMQ 队列中,防止消息丢失。TDMQ CMQ 版支持多进程同时读写,收发互不干扰,无需各应用或组件始终处于运行状态。
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档