rocketmq系统
文章平均质量分 91
rocketmq消息堆积,生产失败,topic自动创建等
qian_348840260
这个作者很懒,什么都没留下…
展开
-
7张图揭晓RocketMQ存储设计的奥妙
1、存储概述RocketMQ存储的文件主要包括Commitlog文件、ConsumeQueue文件、Index文件。RocketMQ将所有主题的消息存储在同一个文件中,确保消息发送时按顺序写文件,尽最大能力确保消息发送的高可用性与高吞吐量。但消息中间件一般都是基于主题的订阅与发布模式,消息消费时必须按照主题进行帅选消息,显然从Commitlog文件中按照topic去筛选消息会变得及其低效,为了提高根据主题检索消息的效率,RocketMQ引入了ConsumeQueue文件,俗成消费队列文件。关系转载 2021-11-03 11:10:44 · 161 阅读 · 0 评论 -
RocketMQ之消息查询IndexFile
原作:RocketMQ之消息查询IndexFile(四) - 红发-的个人空间 - OSCHINA - 中文开源技术交流社区首先我们先看看indexfile的流程是怎么样的,然后对其一步步分析源码调试,MessageStore中存储的消息除了通过ConsumeQueue提供给consumer消费之外,还支持通过MessageID或者MessageKey来查询消息;使用ID查询时,因为ID就是用broker+offset生成的(这里msgId指的是服务端的),所以很容易就找到对应的commitLog文件.转载 2021-11-02 20:39:30 · 512 阅读 · 0 评论 -
使用canal同步MySQL数据到ES的有序性保证
原著地址:https://www.jianshu.com/p/2144250176d9最近在做的项目中有用到canal实时同步MySQL的数据,并且写入es的场景,总结了一些心得,以备后查。总体同步的流程图如下:MySQL-es process.png链路中的环节稍微解释下: binlogMySQL的自身的操作日志,用来记录数据的变更操作及变更后的数据。需要开启并配置 binlog-format 为 ROW 模式。具体可查看canal文档。 canalali...转载 2021-04-21 20:44:39 · 700 阅读 · 0 评论 -
rocketmq消息积压一例
1、面试场景与面试技巧金三银四招聘季,一位粉丝朋友最近在蚂蚁金服第二轮面试时遇到这样一个问题:如果MQ消费遇到瓶颈时该如何处理?。横向扩容,相比很多读者与我这位朋友一样会脱口而出,面试官显然不会满意这样的回答,然后追问道:横向扩容是堆机器,还有没有其他办法呢?在面试过程中,个人建议大家在听到问题后稍作思考,不要立马给出太直接的答案,而是应该与面试官进行探讨,一方面可更深刻的理解面试官的出题初衷,同时可以给自己梳理一下思路。消费端遇到瓶颈,这是一个结果,但引起这个结果的原因是什么呢?在没有弄清转载 2021-03-19 10:05:48 · 2418 阅读 · 0 评论 -
RocketMQ集群中某台主broker宕机后,consumer端发生了什么
首先,我们明确下从broker在rocketmq集群中到底扮演着什么角色?1. 当主服务器宕机时,从服务器会接管消息消费,但不会接管消息发送(持有异议)2. 主服务器压力过大时,从服务器接管拉取服务。参阅: https://blog.csdn.net/qian_348840260/article/details/109628130在哪里选择拉取的broker?DefaultMQPushConsumerImpl#pullMessage 拉取回调中决定下一次拉取选择主broker还是从...原创 2020-11-11 19:39:19 · 2600 阅读 · 0 评论 -
RocketMQ HA机制(主从同步)
原创:https://mp.weixin.qq.com/s/QnFDFBOoI6pDZf8L2KpBDg温馨提示:建议参考代码RocketMQ4.4版本,4.5版本引入了多副本机制,实现了主从自动切换,本文并不关心主从切换功能。本节目录 1、初识主从同步 2、提出问题 3、原理探究 3.1 RocketMQ主从读写分离机制 3.2 消息消费进度同步机制 3.2.1 从服务定时同步主服务器进度 3.2.2 主服务器消息拉取时更...转载 2020-11-11 18:36:58 · 886 阅读 · 0 评论 -
Rocketmq 消息消费监控
比较通用的消息监控方式: 累加consumer负载的consumer queue的消息延迟量,消息延迟量= brokerOffset-consumerOffset.这个统计并不严谨:1. consumer queue中存储的消息是全量消息,而consumer客户端订阅的往往是过滤消息 ( by tag)2. consumerOffset并非实时更新,可能异步更新,也可能是下次拉取消息的时候更新的,也可能因为此条消息消费卡顿导致一直无法正常更新进度,因此存在一定的更新延迟。推荐的监控方式:原创 2020-11-09 16:41:19 · 1372 阅读 · 0 评论 -
Rocketmq 发送成功是指? (同步发送 异步发送 & 同步刷盘 异步刷盘)
同开始接触Rocketmq的童鞋总容易把同步发送(异步发送)和同步刷盘(异步刷盘)混淆在一起,纠缠同步发送是不是和异步刷盘相矛盾,发送成功是指消息commit.log成功,还是追加到映射文件中成功又或者是发送到sendThreadPoolQueue就算成功,直接返回。在这里需要明确的是,发送是指客户端的行为,同步发送是客户等待结果返回才继续向下运行程序,而异步发送是指客户端另启一线程,执行发送消息,成功后执行回调。而同步刷盘和异步刷盘是broker端的行为,异同点在于何时将映射文件中的消息flush到硬盘上原创 2020-10-29 11:27:49 · 814 阅读 · 0 评论 -
Rocketmq 部署架构
1、主,从服务器都在运行过程中,消息消费者是从主拉取消息还是从从拉取?答:默认情况下,RocketMQ消息消费者从主服务器拉取,当主服务器积压的消息超过了物理内存的40%,则建议从从服务器拉取。但如果slaveReadEnable为false,表示从服务器不可读,从服务器也不会接管消息拉取。2、当消息消费者向从服务器拉取消息后,会一直从从服务器拉取?答:不是的。分如下情况:1)如果从服务器的slaveReadEnable设置为false,则下次拉取,从主服务器拉取。2)如果从服务器允许读取并且从原创 2020-10-28 17:51:36 · 406 阅读 · 1 评论 -
Rocketmq TIMEOUT_CLEAN_QUEUE源码追踪
1、问题现象首先接到项目反馈使用 RocketMQ 会出现如下错误:错误信息关键点:MQBrokerException:CODE:2 DESC:[TIMEOUT_CLEAN_QUEUE]broker busy,start flow control for a while,period in queue:205ms,size of queue:880。由于项目组并没有对消息发送失败做任何补偿,导致丢失消息发送失败,故需要对这个问题进行深层次的探讨,并加以解决。2、问题分析首先我们根据关键字:转载 2020-10-27 11:27:20 · 1828 阅读 · 1 评论 -
RocketMQ顺序消费加锁机制
Rocketmq在顺序消费时,为了保证消息消费的有序性,使用了加锁机制,即对messageQueue进行全局加锁,其实现原理可参考源码分析RocketMQ顺序消息消费实现原理,本节不作源码分析,重点在解答为什么要全局加锁。不少文章给出的原因是:当topic的队列个数小于消费组中消费者的个数,会导致多个消费者消费同一个queue,存在竞争。但是查看AllocateMessageQueueStrategy的实现源码,发现topic的队列个数小于消费组中消费者的个数时,会导致超出个数的消费者无队列可消费,即负载不原创 2020-10-22 14:11:33 · 2220 阅读 · 7 评论 -
RocketMQ 同步刷盘&异步刷盘
刷盘的入口方法在CommitLog#putMessagehandleDiskFlush(result, putMessageResult, msg); public void handleDiskFlush(AppendMessageResult result, PutMessageResult putMessageResult, MessageExt messageExt) { // Synchronization flush if (FlushDiskTy原创 2020-10-21 16:26:28 · 1166 阅读 · 0 评论 -
Rocketmq broker写入能力查看
如何证明 RocketMQ 集群本身没有问题呢?其实也很简单,我们通常一个常用的技巧是查看 RocketMQ 消息写入的性能,执行如下命令:cd ~/logs/rocketmqlogs/grep 'PAGECACHERT' store.log | more其输出的结果如下图所示:在 RocketMQ Broker 中会每隔 1 分钟打印出上一分钟消息写入的耗时分布,例如 [<=0ms] 表示在这一秒钟写入消息在 Broker 端的延时小于 0ms 的消息条数,其他的依次类推,通转载 2020-10-20 11:21:13 · 693 阅读 · 0 评论 -
RocketMQ 消费端限流机制
RocketMQ 消息消费端会从 3 个维度进行限流:消息消费端队列中积压的消息超过 1000 条 消息处理队列中尽管积压没有超过 1000 条,但最大偏移量与最小偏移量的差值超过 2000 消息处理队列中积压的消息总大小超过 100M为了方便理解上述三条规则的设计理念,我们首先来看一下消费端的数据结构,如下图所示:PullMessageService 线程会按照队列向 Broker 拉取一批消息,然后会存入到 ProcessQueue 队列中,即所谓的处理队列,然后再提交到消费端线程池中转载 2020-10-20 11:15:32 · 5341 阅读 · 1 评论 -
rocketmq 查找消息堆积原因的一种思路(jstack)
rocketmq发生消息堆积时,我们可以通过jstack打印出线程的堆栈信息(可连续打印多次观察变化)。重点搜索 ConsumeMessageThread_ 开头的线程状态,例如下图所示:如果发现大量的线程总是处于runnable状态,且堆栈信息中包含类似HttpClientUtil.doGet的信息,且有可能是因为http请求处理慢,导致大量线程被占用,消费能力不足导致消息堆积。解决思路,优优http请求,如设置较短的过期时间等。如果发现大量的消费线程处于WAITING(parking)状态,原创 2020-10-20 10:58:41 · 2065 阅读 · 2 评论 -
源码分析RocketMQ之消息消费重试机制
主要关注业务方在消息消费失败后,返回 ConsumeConcurrentlyStatus.RECONSUME_LATER ,专业术语:业务方每条消息消费后要告诉 MQ 消费者一个结果(ack,message back),触发 MQ 消息消费重试机制,然后 MQ 消费者需要反馈给 MQ(Broker)。备注:主要针对的还是非顺序消息,顺序消息在后续专题详细分析。1、消息消费处理代码入口:ConsumeMessageConcurrentlyService ConsumeRequest run方法转载 2020-10-19 17:36:24 · 593 阅读 · 0 评论 -
Rocketmq offset进度管理
下文以DefaultMQPushConsumerImpl集群模式消费消息为例。概述消息消费完成后,需要将消费进度存储起来,即前面提到的offset。广播模式下,同消费组的消费者相互独立,消费进度要单独存储;集群模式下,同一条消息只会被同一个消费组消费一次,消费进度会参与到负载均衡中,故消费进度是需要共享的。消费者端提交offset入口入口在org.apache.rocketmq.client.impl.consumer.ConsumeMessageConcurrentlyService#原创 2020-10-19 17:24:48 · 1670 阅读 · 1 评论 -
Rocketmq 顺序消费的几点建议
为了保证消息消费的有序性,Rocketmq在发送消息时需要通过MessageQueueSelector指定具体发送的consumerQueue。顺序消费的事件监听器为 MessageListenerOrderly,表示顺序消费。在使用时,需求注意以下几点:1. 消费端为了保证有序消费,在拉取消费和消费消息时,都会在broker端获取queue的锁。如果topic的队列个数小于消费组中消费者的个数,会导致多个消费者消费同一个queue,会频繁的获取queue的锁,释放锁,产生竞争 。因此在使用顺序原创 2020-10-16 17:31:28 · 1422 阅读 · 0 评论 -
Rocketmq中的DefaultMQPushConsumer是如何拉取消息的?
1 假设关系图如下:图12 启动流程如下:3 一切美好的事情都从PullMessageService的run方法开始了: 3.1 run方法会不断的从LinkedBlockingQueue中获取PullRequest对象,然后根据PullRequest进行消息拉取。 问题1:是谁把PullRequest放到LinkedBlockingQueue中呢? 答:第一次加入是在consumer的rebalance流程中,rebalance完毕会将PullReques...原创 2020-10-14 17:17:32 · 931 阅读 · 0 评论 -
从Rocketmq的事务消息来看数据的强一致性
在分布式系统中经常遇到类似的场景: 本地执行DB业务操作,并通知微服务执行其他的业务操作。这里就涉及到数据一致性的问题,如何保证两个系统的操作同时成功或者同时失败?Rocketmq事务消息可以保证业务与消息发送这两个操作的强一致性,为大家提供了一种思路。传统的操作:事物{ 1.调用接口 2.业务逻辑处理}上述传统操作存在如下问题: 调用接口成功但业务逻辑处理失败,有可能导致数据不一致。调用接口后,正好kill -9,必然导致数据不一致。Rocketmq是如...原创 2020-10-10 17:59:40 · 397 阅读 · 1 评论 -
rocketmq中的读写队列
在创建或更改topic时,需要配置writeQueueNums和readQueueNums数,这里的读写队列有什么作用?初识rocketmq的童鞋,很容易把读写队列和读写分离混淆在一起。其实在rocketmq里是完全不同的两个概念。读写分离,是用HA机制,将一个节点的数据同步到另外一个节点,主节点多用于写(也可读),从节点只用于读。往往一主多从,通过读写分离减轻系统压力。读写队列,则是在做路由信息时使用。在消息发送时,使用写队列个数返回路由信息,而消息消费时按照读队列个数返回路由信息。在物理文件层面原创 2020-10-09 11:33:13 · 7208 阅读 · 9 评论 -
RocketMQ 如何基于mmap+page cache实现磁盘文件的高性能读写?
1、mmap:Broker读写磁盘文件的核心技术今天我们要给大家介绍一个非常关键的黑科技,很多人可能都不太熟悉,这个技术就是mmap技术,而Broker中就是大量的使用mmap技术去实现CommitLog这种大磁盘文件的高性能读写优化的。通过之前的学习,我们知道了一点,就是Broker对磁盘文件的写入主要是借助直接写入os cache来实现性能优化的,因为直接写入os cache,相当于就是写入内存一样的性能,后续等os内核中的线程异步把cache中的数据刷入磁盘文件即可。那么今天我们就要对这个转载 2020-09-27 16:19:51 · 463 阅读 · 0 评论 -
RocketMq product 故障规避机制
消息发送高可用设计与故障规避机制熟悉 RocketMQ 的小伙伴应该都知道,RocketMQ Topic 路由注册中心 NameServer 采用的是最终一致性模型,而且客户端是定时向 NameServer 拉取 Topic 的路由信息,即客户端(Producer、Consumer)是无法实时感知 Broker 宕机的,这样消息发送者会继续向已宕机的 Broker 发送消息,造成消息发送异常。那 RocketMQ 是如何保证消息发送的高可用性呢?RocketMQ 为了保证消息发送的高可用性,在内部引原创 2020-09-22 16:36:49 · 969 阅读 · 2 评论 -
RocketMQ 中 clientId的使用陷阱
试验环境部署架构部署了两套 RocketMQ 集群,在 DefaultCluster 集群上创建 Topic——dw_test_01,并在 DefaultClusterb 上创建 Topic——dw_test_02,现在的需求是 order-service-app 要向 dw_test_01、dw_test_02 上发送消息。给出的示例代码如下:public static void main(String[] args) throws Exception{ // 创建第一...原创 2020-09-22 16:20:16 · 3652 阅读 · 1 评论 -
roceketmq自动创建topic那点事
broker端设置autoCreateTopicEnable=true,表明支持自动创建topic (本文讨论的前提)broker在启动时,检测到autoCreateTopicEnable=true 并且topic:TBW102不存在时,会自动创建名为TBW102的默认主题,主题创建的队列数为broker.properties中的defaultTopicQueueNums,在向nameServer发送心跳包时(默认每30s发送一次)会把主题信息通知到nameServer,另外会有一定时任务,将topi.原创 2020-05-18 16:08:41 · 1319 阅读 · 0 评论 -
一次JVM GC排查过程及解决方案
背景介绍:dispatcher-queue-consumer主要负责订阅rocketmq的topic,消费消息进行业务逻辑处理。目前一共有14个消费组,其中轨迹类消费组(3组,其他11类消费组tps量级较低)tps峰值高达10000,均值5000,单机 tps约为5000/8.prod环境堆内存为2G,垃圾回收算法组合使用Parallel Scavenge+Parallel Old.统计时段: 所有数据统计均以15-18点为准优化前fgc 1次/24小时,ygc 6-7次/1分钟, ygc平原创 2020-09-02 19:21:27 · 2857 阅读 · 3 评论 -
RocketMQ 如何基于mmap+page cache实现磁盘文件的高性能读写?
转载:http://www.imooc.com/article/3016241、mmap:Broker读写磁盘文件的核心技术今天我们要给大家介绍一个非常关键的黑科技,很多人可能都不太熟悉,这个技术就是mmap技术,而Broker中就是大量的使用mmap技术去实现CommitLog这种大磁盘文件的高性能读写优化的。通过之前的学习,我们知道了一点,就是Broker对磁盘文件的写入主要是借助直接写入os cache来实现性能优化的,因为直接写入os cache,相当于就是写入内存一样的性能,后续等o.转载 2020-06-12 17:41:23 · 643 阅读 · 0 评论 -
rocketmq最佳实践
http://www.360doc.com/document/17/0706/15/41344223_669340008.shtml转载 2020-02-20 11:39:47 · 182 阅读 · 0 评论 -
一图入门rocketmq
原创 2020-02-19 17:13:26 · 146 阅读 · 0 评论 -
rocketmq的instanceName参数何时该设置
以下只针对集群模式:1producer默认情况下不需要设置instanceName,rocketmq会使用ip@pid(pid代表jvm名字)作为唯一标示如果同一个jvm中,不同的producer需要往不同的rocketmq集群发送消息,需要设置不同的instanceName原因如下:如果不设置instanceName,那么会使用ip@pid作为producer唯一标识,那么会导致多个p...转载 2020-02-18 17:50:35 · 2204 阅读 · 0 评论 -
rocketmq快速失败机制导致生产消息失败
原创:https://www.sohu.com/a/396792314_115128问题现象首先接到项目反馈使用 RocketMQ 会出现如下错误:错误信息关键点:MQBrokerException:CODE:2DESC:[TIMEOUT_CLEAN_QUEUE]broker busy,start flow control for a while,period in queue:205ms,size of queue:880。由于项目组并没有对消息发送失败做任何补偿,导致丢失消息发送失败转载 2020-06-17 11:14:56 · 1082 阅读 · 0 评论 -
RocketMq消息生产消费简图
1.**********原创 2020-06-16 11:32:09 · 459 阅读 · 0 评论 -
消息中间件—RocketMQ消息存储
消息中间件—RocketMQ消息存储(一)https://www.jianshu.com/p/b73fdd893f98消息中间件—RocketMQ消息存储(二)https://www.jianshu.com/p/6d0c118c17de转载 2020-06-12 16:03:52 · 181 阅读 · 0 评论 -
rocketMQ消息堆积监控的java实现
前言:最近搭框架用到了rocketMQ队列,需要实现java代码中实现队列中rocketMQ消息堆积的监控,即在先队列中放入消息时,获取当前队列中未消费消息的堆积量,用来判断是否将当前消息立马放入还是等待一段时间在放入,建立和队列的心跳连接,以避免生产者生产大量消息,而消费者未能及时消费,而引起的消息的大面积堆积。1、rocketMQ部署,创建和使用网上有大量资料,就不在赘述,请自行百度。2、rocketMQ消息堆积监控的java实现本人做此监控前在网上找了许多资料关于rocketMQ消息堆积转载 2020-05-11 16:04:47 · 1734 阅读 · 2 评论