RocketMQ消息轨迹-设计篇
RocketMQ 消息轨迹主要包含两篇文章:设计篇与源码分析篇,本节将详细介绍RocketMQ消息轨迹-设计相关。
RocketMQ消息轨迹,主要跟踪消息发送、消息消费的轨迹,即详细记录消息各个处理环节的日志,从设计上至少需要解决如下三个核心问题:
- 消费轨迹数据格式
- 记录消息轨迹(消息日志)
- 消息轨迹数据存储在哪?
1、消息轨迹数据格式
RocketMQ4.5版本消息轨迹主要记录如下信息:
- traceType
跟踪类型,可选值:Pub(消息发送)、SubBefore(消息拉取到客户端,执行业务定义的消费逻辑之前)、SubAfter(消费后)。 - timeStamp
当前时间戳。 - regionId
broker所在的区域ID,取自BrokerConfig#regionId。 - groupName
组名称,traceType为Pub时为生产者组的名称;如果traceType为subBefore或subAfter时为消费组名称。 - requestId
traceType为subBefore、subAfter时使用,消费端的请求Id。 - topic
消息主题。 - msgId
消息唯一ID。 - tags
消息tag。 - keys
消息索引key,根据该key可快速检索消息。 - storeHost
跟踪类型为PUB时为存储该消息的Broker服务器IP;跟踪类型为subBefore、subAfter时为消费者IP。 - bodyLength
消息体的长度。 - costTime
耗时。 - msgType
消息的类型,可选值:Normal_Msg(普通消息),Trans_Msg_Half(预提交消息),Trans_msg_Commit(提交消息),Delay_Msg(延迟消息)。 - offsetMsgId
消息偏移量ID,该ID中包含了broker的ip以及偏移量。 - success
是发送成功。 - contextCode
消费状态码,可选值:SUCCESS,TIME_OUT,EXCEPTION,RETURNNULL,FAILED。
2、记录消息轨迹
消息中间件的两大核心主题:消息发送、消息消费,其核心载体就是消息,消息轨迹(消息的流转)主要是记录消息是何时发送到哪台Broker,发送耗时多少时间,在什么是被哪个消费者消费。记录消息的轨迹主要是集中在消息发送前后、消息消费前后,可以通过RokcetMQ的Hook机制。通过如下两个接口来定义钩子函数。
通过实行上述两个接口,可以实现在消息发送、消息消费前后记录消息轨迹,为了不明显增加消息发送与消息消费的时延,记录消息轨迹最好使用异步发送模式。
3、如何存储消息轨迹数据
消息轨迹需要存储什么消息以及在什么时候记录消息轨迹的问题都以及解决,那接下来就得思考将消息轨迹存储在哪里?存储在数据库中或其他媒介中,都会加重消息中间件,使其依赖外部组件,最佳的选择还是存储在Broker服务器中,将消息轨迹数据也当成一条消息存储到Broker服务器。
既然把消息轨迹当成消息存储在Broker服务器,那存储消息轨迹的Topic如何确定呢?RocketMQ提供了两种方法来定义消息轨迹的Topic。
- 系统默认Topic
如果Broker的traceTopicEnable配置设置为true,表示在该Broker上创建topic名为:RMQ_SYS_TRACE_TOPIC,队列个数为1,默认该值为false,表示该Broker不承载系统自定义用于存储消息轨迹的topic。 - 自定义Topic
在创建消息生产者或消息消费者时,可以通过参数自定义用于记录消息轨迹的Topic名称,不过要注意的是,rokcetmq控制台(rocketmq-console)中只支持配置一个消息轨迹Topic,故自定义Topic,在目前这个阶段或许还不是一个最佳实践,建议使用系统默认的Topic即可。
通常为了避免消息轨迹的数据与正常的业务数据混合在一起,官方建议,在Broker集群中,新增加一台机器,只在这台机器上开启消息轨迹跟踪,这样该集群内的消息轨迹数据只会发送到这一台Broker服务器上,并不会增加集群内原先业务Broker的负载压力。
原文发布时间为:2019-07-14
本文作者:丁威,《RocketMQ技术内幕》作者。
本文来自中间件兴趣圈,了解相关信息可以关注中间件兴趣圈。
低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
MyCat数据库的基础配置及使用
一、为什么需要分布式数据据库 随着计算机和信息技术的迅猛发展,行业应用系统的规模迅速扩大,行业应用所产生的数据量呈爆炸式增长,动辄达到数百TB甚至数百PB的规模,已远远超出传统计算技术和信息系统的处理能力,集中式数据库面对大规模数据处理逐渐表现出其局限性。因此,人们希望寻找一种能快速处理数据和及时响应用户访问的方法,也希望对数据进行集中分析、管理和维护。这已经成为迫切需求。 分布式数据库是在集中式数据库的基础上发展起来的,是计算机技术和网络技术结合的产物。分布式数据库是指数据在物理上分布而在逻辑上集中管理的数据库系统。物理上分布是指数据分布在物理位置不同并由网络连接的节点或站点上;逻辑上集中是指各数据库节点之间的逻辑上是一个整体,并由统一的数据库管理系统管理。不同的节点分布可以跨不同的机房、城市甚至国家。 二、分布式数据库的特点 分布式数据库具有透明性、数据冗余性、易于扩展性、自治性等特点,还具有经济、性能优越、响应速度更快、灵活的体系结构、易于集成现有系统等特点。 分布式数据库尽管有着天生的高贵血统,但它依赖调整网络,对事务的处理远没有传统数据库成熟,在很长一段时间内分布式数据存储将...
- 下一篇
RocketMQ一个新的消费组初次启动时从何处开始消费呢?
1、抛出问题 一个新的消费组订阅一个已存在的Topic主题时,消费组是从该Topic的哪条消息开始消费呢? 首先翻阅DefaultMQPushConsumer的API时,setConsumeFromWhere(ConsumeFromWhere consumeFromWhere)API映入眼帘,从字面意思来看是设置消费者从哪里开始消费,正是解开该问题的”钥匙“。ConsumeFromWhere枚举类图如下: CONSUME_FROM_MAX_OFFSET从消费队列最大的偏移量开始消费。 CONSUME_FROM_FIRST_OFFSET从消费队列最小偏移量开始消费。 CONSUME_FROM_TIMESTAMP从指定的时间戳开始消费,默认为消费者启动之前的30分钟处开始消费。可以通过DefaultMQPushConsumer#setConsumeTimestamp。 是不是点小激动,还不快试试。 需求:新的消费组启动时,从队列最后开始消费,即只消费启动后发送到消息服务器后的最新消息。 1.1 环境准备 本示例所用到的Topic路由信息如下: Broker的配置如下(broker.conf...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- Springboot2将连接池hikari替换为druid,体验最强大的数据库连接池
- CentOS6,CentOS7官方镜像安装Oracle11G
- Jdk安装(Linux,MacOS,Windows),包含三大操作系统的最全安装
- CentOS关闭SELinux安全模块
- CentOS7编译安装Gcc9.2.0,解决mysql等软件编译问题
- Windows10,CentOS7,CentOS8安装MongoDB4.0.16
- Hadoop3单机部署,实现最简伪集群
- SpringBoot2编写第一个Controller,响应你的http请求并返回结果
- Eclipse初始化配置,告别卡顿、闪退、编译时间过长
- SpringBoot2全家桶,快速入门学习开发网站教程