[转帖]RocketMQ - nameSrv和Broker

rocketmq,namesrv,broker · 浏览次数 : 0

小编点评

**RocketMQ 消息存储架构** **核心模块:** * **Remoting Module:** 处理来自客户端的请求。 * **Client Manager:** 管理客户端 (Producer/Consumer) 和维护 Consumer 的 Topic 订阅信息。 * **Store Service:** 提供简单的 API 接口处理消息存储到物理硬盘和查询功能。 * **HA Service:** 高可用服务,提供 Master Broker 和 Slave Broker 之间的数据同步功能。 * **Index Service:** 根据特定的 Message key 对投递到 Broker 的消息进行索引服务,以提供消息的快速查询。 **消息存储机制:** * **CommitLog:** 消息主体以及元数据的存储主体,存储Producer端写入的消息主体内容,消息内容不是定长的,单个文件大小默认 1G,文件名长度 20 位,左边补 0,剩余为实际偏移量。 * **ConsumeQueue:** 消息消费队列,引入的目的主要是提高消费消息的性能,由于 RocketMQ 是基于主题 topic 的订阅模式,消息消费是针对主题进行的,如果要遍历 commitlog 文件中根据 topic 搜索消息非常低效,因此消费者即可根据 ConsumeQueue 来查找待消费的消息,其中,ConsumeQueue(逻辑消费队列)作为消费消息的索引,保存指定 Topic 下的队列消息在 CommitLog 中的起始物理偏移量 offset,消息大小和消息 Tag 的 hashCode 值。 * **IndexFile:** 提供一种可以通过 key 或时间区间来查询消息的方法。 **消息刷盘同步:** * **同步刷盘:** 在消息真正持久化至磁盘后 RocketMQ 的 Broker 端才会真正返回给 Producer 端一个成功的 ACK响应。 * **异步刷盘:** 可以充分利用 OS 的 PageCache 优势,只要消息写入 Page Cache 即可将成功的 ACK 返回给 Producer 端。 **模式配置:** * **ASYNC_MASTER (异步主机):** 对信息可靠性要求比较严格。 * **SYNC_MASTER (同步主机):** 对消息可靠性要求高。 * **SLAVE (从机):** 从机模式下,只用于从 broker 中获取数据。

正文

RocketMQ

RocketMQ是一个统一的消息传递引擎,轻量级的数据处理平台。

Name Server

Name Server充当路由消息的提供者,生产者(Producer)或消费者(Customer)可以通过Name Server查找各主题对应的Broker IP列表,多个Name Server实例组成集群,但相互独立,没有信息交换。支持Broker的动态注册与发现。主要包括两个功能:
Broker管理:Name Server接收Broker集群的注册信息并且保存下来作为路由信息的基本数据,然后提供心跳检测机制,检查Broker是否存活;
路由信息管理:每个Name Server将保存关于Broker集群的整个路由信息和用于客户端查询的队列信息,然后生产者(Producer)和消费者(Conumser)通过Name Server就可以知道整个Broker集群的整个路由信息和用于客户端查询的队列信息,从而进行消息的投递和消费。

Broker Server

负责存储消息、转发消息。Broker Server在RocketMQ系统中负责接收从生产者(Producer)发送来的消息并存储、同事为消费者的拉取请求做准备。Borker Server也存储消息相关的元数据,包括消费者组、消费进度偏移、主题和队列信息等。
Broker启动后需要完成一次将自己注册至NameServer的操作;随后每隔30s时间定时向NameServer上报Topic路由信息。
为了实现Broker中消息的存储、投递、查询以及服务高可用的保证,囊括一下几个重要的子模块信息:
Remoting Module:整个borker的实体,负责处理来自客户端的请求;
Client Manager:负责管理客户端(Producer/Consumer)和维护Consumer的Topic订阅信息;
Store Service:提供简单的API接口处理消息存储到物理硬盘和查询功能;
HA Service:高可用服务,提供Master Broker和Slaver Broker之间的数据同步功能;
Index Service:根据特定的Message key对投递到Broker的消息进行索引服务,以提供消息的快速查询。

Broker 架构

消息存储是RocketMQ中至关重要的一部分,想对其他来说会比较复杂。

消息存储架构

  • CommitLog:消息主体以及元数据的存储主体,存储Producer端写入的消息主体内容,消息内容不是定长的,单个文件大小默认1G,文件名长度20位,左边补0,剩余为其实偏移量,比如00000000000000000000代表了第一个文件,其实偏移量为0,文件大小为1G=1073741824;当第一个文件写满了,第二个文件为00000000001073741824,起始偏移量为1073741824,以此类推,消息主要是顺序写入日志文件,当文件满了,写入下一个文件;
  • ConsumeQueue:消息消费队列,引入的目的主要是提高消费消息的性能,由于RocketMQ是基于主题topic的订阅模式,消息消费是针对主题进行的,如果要遍历commitlog文件中根据topic检索消息非常低效的,Consumer即可根据ConsumeQueue来查找待消费的消息,其中,ConsumeQueue(逻辑消费队列)作为消费消息的索引,保存指定Topic下的队列消息在CommitLog中的起始物理偏移量offset,消息大小size和消息Tag的hashCode值,consumequeue文件可以看成是基于topic的commitLog索引文件,所以consumequeue文件夹组织方式如下:topic/queue/file三层组织结构,具体存储路径为:$HOME/store/consumequeue/{topic}/{queueId}/{fileName},同样consumequeue文件采用定长设计,每一个条目共20个字节,分别为8字节的commitlog物理偏移量,4字节消息长度,8字节tag hashcode,单个文件由30W个条目组成,可以像数组一样随机访问每一个条目,每个ConsumeQueue文件大小约为5.72M;
  • IndexFile:IndexFile(索引文件)提供了一种可以通过key或时间区间来查询消息的方法。Index文件的存储位置是:$HOME/store/index/{fileName},文件名fileName是以创建时的时间戳命名的,固定的单个IndexFile文件大小约为400M,一个IndexFile可以保存 2000W个索引,IndexFile的底层存储设计为在文件系统中实现HashMap结构,故rocketmq的索引文件其底层实现为hash索引。

消息刷盘

  • 同步刷盘:只有在消息真正持久化至磁盘后RocketMQ的Broker端才会真正返回给Producer端一个成功的ACK响应。同步刷盘对MQ消息可靠性来说是一种不错的保障,但是性能上会有较大影响,一般适用于金融业务应用该模式较多。
  • 异步刷盘:能够充分利用OS的PageCache的优势,只要消息写入PageCache即可将成功的ACK返回给Producer端。消息刷盘采用后台异步线程提交的方式进行,降低了读写延迟,提高了MQ的性能和吞吐量。

Broker 角色

Broker角色分为ASYNC_MASTER(异步主机)、SYNC_MASTER(同步主机)以及SLAVE(从机)。
SYNC_MASTER(同步主机):对信息的可靠性要求比较严格;
ASYNC_MASTER(异步主机):对消息可靠性要求不高;

Broker 配置

参数名默认值说明
listenPort10911接受客户端连接的监听端口
namesrvAddrNullnameServer地址
brokerIP1网卡的InetAddress当前broker监听的IP
brokerIP2跟brokerIP1一样存在主从broker时,如果在broker主节点上配置了brokerIP2属性,broker从节点会连接主节点配置的brokerIP2进行同步
brokerNamenullbroker的名称
brokerClusterNameDefaultClusterbroker的名称
brokerId00表示master,其他的正整数表示slave
storePathCommitLog$HOME/store/commitlog/存储 commit log 的路径
storePathConsumerQueue$HOME/store/consumequeue/存储 consume queue 的路径
mappedFileSizeCommitLog1024 * 1024 * 1024(1G)commit log 的映射文件大小
deleteWhen04在每天的什么时间删除已经超过文件保留时间的 commit log
fileReservedTime72以小时计算的文件保留时间
brokerRoleASYNC_MASTERSYNC_MASTER/ASYNC_MASTER/SLAVE
flushDiskTypeASYNC_FLUSHSYNC_FLUSH/ASYNC_FLUSH SYNC_FLUSH 模式下的 broker 保证在收到确认生产者之前将消息刷盘。ASYNC_FLUSH 模式下的 broker 则利用刷盘一组消息的模式,可以取得更好的性能。

nameSrv和Broker简单的架构图

在这里插入图片描述

</article>
复制

与[转帖]RocketMQ - nameSrv和Broker相似的内容:

[转帖]RocketMQ - nameSrv和Broker

RocketMQ RocketMQ是一个统一的消息传递引擎,轻量级的数据处理平台。 Name Server Name Server充当路由消息的提供者,生产者(Producer)或消费者(Customer)可以通过Name Server查找各主题对应的Broker IP列表,多个Name Serve

[转帖]Kafka 与RocketMQ 落盘机制比较

https://www.jianshu.com/p/fd50befccfdd 引言 前几期的评测中,我们对比了Kafka和RocketMQ的吞吐量和稳定性,本期我们要引入一个新的评测标准——软件可靠性。 何为“可靠性”? 先看下面这种情况:有A,B两辆越野汽车,在城市的周边地区均能很好应对泥泞的路况

[转帖]看一遍就理解:零拷贝原理详解

https://juejin.cn/post/7043948967729561607 前言 大家好,我是程序员田螺。 零拷贝是老生常谈的问题啦,大厂非常喜欢问。比如Kafka为什么快,RocketMQ为什么快等,都涉及到零拷贝知识点。最近技术讨论群几个伙伴分享了阿里、虾皮的面试真题,也都涉及到零拷贝

[转帖]消息队列与快递柜之间妙不可言的关系

https://xie.infoq.cn/article/8085241414e8959323ecd7811 一、消息队列是一个快递柜 我们来将快递柜与消息队列做一个对比 消息队列比作快递柜:有很多厂家生产快递柜,如:丰巢(apache kafka),速递易(alibaba RocketMQ),近邻

[转帖]

Linux ubuntu20.04 网络配置(图文教程) 因为我是刚装好的最小系统,所以很多东西都没有,在开始配置之前需要做下准备 环境准备 系统:ubuntu20.04网卡:双网卡 网卡一:供连接互联网使用网卡二:供连接内网使用(看情况,如果一张网卡足够,没必要做第二张网卡) 工具: net-to

[转帖]

https://cloud.tencent.com/developer/article/2168105?areaSource=104001.13&traceId=zcVNsKTUApF9rNJSkcCbB 前言 Redis作为高性能的内存数据库,在大数据量的情况下也会遇到性能瓶颈,日常开发中只有时刻

[转帖]ISV 、OSV、 SIG 概念

ISV 、OSV、 SIG 概念 2022-10-14 12:29530原创大杂烩 本文链接:https://www.cndba.cn/dave/article/108699 1. ISV: Independent Software Vendors “独立软件开发商”,特指专门从事软件的开发、生产、

[转帖]Redis 7 参数 修改 说明

2022-06-16 14:491800原创Redis 本文链接:https://www.cndba.cn/dave/article/108066 在之前的博客我们介绍了Redis 7 的安装和配置,如下: Linux 7.8 平台 Redis 7 安装并配置开机自启动 操作手册https://ww

[转帖]HTTPS中间人攻击原理

https://www.zhihu.com/people/bei-ji-85/posts 背景 前一段时间,公司北京地区上线了一个HTTPS防火墙,用来监听HTTPS流量。防火墙上线之前,邮件通知给管理层,我从我老大那里听说这个事情的时候,说这个有风险,然后意外地发现,很多人原来都不知道HTTPS防

[转帖]关于字节序(大小端)的一点想法

https://www.zhihu.com/people/bei-ji-85/posts 今天在一个技术群里有人问起来了,当时有一些讨论(不完全都是我个人的观点),整理一下: 为什么网络字节序(多数情况下)是大端? 早年设备的缓存很小,先接收高字节能快速的判断报文信息:包长度(需要准备多大缓存)、地