在企业项目中,利用RocketMQ接收数据,存库. 由于是第一次在项目中具体的使用RocketMQ,一直采坑. 1.发现问题:在最终的联调过程中,并发压测,订单数据丢失,同一时刻,oms推送900+的数据,结果消费者只获取并入库了20几条,绝大部分消息丢失. 自己手写了一个生产者测试类,用最原始的循环的方式快速存入多条数据(此处为了测试方便,并不是重复消费问题,实际项目中消费端要加幂等去重).一次就存5条但是每次都丢两条,好像最后两条数据永远消费不到的样子. 但在,RocketMQ在控制台上明显

1.生产者: package com.ebways.mq.test.mq; import com.alibaba.rocketmq.client.exception.MQClientException; import com.alibaba.rocketmq.client.producer.DefaultMQProducer; import com.alibaba.rocketmq.client.producer.SendResult; import com.alibaba.rocketmq.c

参考: 开源社区:https://github.com/alibaba/RocketMQ rocketmq入门: http://www.cnblogs.com/LifeOnCode/p/4805953.html 考拉哥的博客: http://lifestack.cn/archives/tag/rocketmq [简书]rocketmq原理和实践:http://www.jianshu.com/p/453c6e7ff81c 一.ROCKETMQ简介 11 月 28 日,阿里巴巴宣布将开源分布式消息中

1 在resources目录下创建config目录,新建文件rocketmq.properties文件 # 指定namesrv地址 suning.rocketmq.namesrvAddr=localhost:9876 #生产者group名称 suning.rocketmq.producerGroupName=user_group #事务生产者group名称 suning.rocketmq.transactionProducerGroupName=order_transaction #消费者gro

本文探讨如何使用 RocketMQ Binder 完成 Spring Cloud 应用消息的订阅和发布. 介绍 RocketMQ 是一款开源的分布式消息系统,基于高可用分布式集群技术,提供低延时的.高可靠的消息发布与订阅服务,广泛应用于多个领域,包括异步通信解耦.企业解决方案.金融支付.电信.电子商务.快递物流.广告营销.社交.即时通信.移动应用.手游.视频.物联网.车联网等. RocketMQ 是阿里巴巴在2012年开源的分布式消息中间件,目前已经捐赠给 Apache 软件基金会,并于2017

目录 1.案情回顾 1.1 集群现状 1.2.RocketMQ 在线扩容队列 1.3 消息发送 2.问题暴露 3.问题分析 4.问题复盘 消息组接到某项目组反馈,topic 在扩容后出现部分队列无法被消费者,导致消息积压,影响线上业务? 考虑到该问题是发送在真实的线上环境,为了避免泄密,本文先在笔者的虚拟机中来重现问题. @(本节目录) 1.案情回顾 1.1 集群现状 集群信息如下: 例如业务主体名 topic_dw_test_by_order_01 的路由信息如图所示: 当前的消费者信息: b

本文整理自李样兵在北京站 RocketMQ meetup分享美菜网使用 RocketMQ 过程中的一些心得和经验,偏重于实践. 嘉宾李样兵,现就职于美菜网基础服务平台组,负责 MQ ,配置中心和任务调度等基础组件开发工作. 今天主要从三个方面进行分享: 美菜网消息队列的历史 基于 RocketMQ 我们做了那些事情 同城双活的选型和思考 美菜网消息队列的历史 美菜网历史上是多套 MQ 并存,Kafka 用于大数据团队:NSQ 和 RocketMQ 用于线上业务. 多套集群存在的问题:1.维护和资

一.重试机制 由于MQ经常处于复杂的分布式系统中,考虑网络波动,服务宕机,程序异常因素,很有可能出现消息发送或者消费失败的问题.因此,消息的重试就是所有MQ中间件必须考虑到的一个关键点.如果没有消息重试,就可能产生消息丢失的问题,可能对系统产生很大的影响.所以,秉承宁可多发消息,也不可丢失消息的原则,大部分MQ都对消息重试提供了很好的支持. MQ 消费者的消费逻辑失败时,可以通过设置返回状态达到消息重试的结果. MQ 消息重试只针对集群消费方式生效:广播方式不提供失败重试特性,即消费失败后,失败

消息队列 基本概述 MQ,Message Queue,基于TCP协议构建的简单协议,区别于具体的通信协议. 基于通信协议定义和抽象的更高层次的通信模型,一般都是生产者和消费者模型,又或者说服务端和客户端模型. 生产者/消费者模型:一般通过定义生产者和消费者实现消息通信从而屏蔽复杂的底层通信协议.应用于分布式应用系统,而且为之提供异步解耦和削峰填谷的能力,同时也具备互联网应用所需的海量堆积,高吞吐和可靠性重试机制的特性. 核心概念 消息主题:Message Topic,一级消息类型,生产者向其发送

本篇博客主要参考: <浅入浅出>-RocketMQ 敖丙 APACHE-RocketMQ Gitee RocketMQ官方文档 RocketMQ 实战与进阶 GitChat 又是好久没有写博客了,虽然可以找出无数个没有写的博客的理由,但是说到底,还是一个字"懒".今天我终于吃了一颗治疗懒癌的药丸,决定写一篇博客.介绍什么好呢,思来想去,还是介绍下RocketMQ吧,毕竟写了30多篇博客,还没有好好写过关于MQ的博客呢.本篇博客比较基础,不涉及到源码分析,只是扫盲. MQ有什

概述 **本人博客网站 **IT小神 www.itxiaoshen.com 定义 Apache RocketMQ官网地址 https://rocketmq.apache.org/ Latest release v4.9.2 Apache RocketMQ GitHub源码地址 https://github.com/apache/rocketmq Apache RocketMQ是一个分布式消息传递和流媒体平台.统一的消息传递引擎,轻量级的数据处理平台:具有低延迟.高性能和可靠性.万亿级容量和灵活的

设计背景 消息中间件的本身定义来考虑,应该尽量减少对于外部第三方中间件的依赖.一般来说依赖的外部系统越多,也会使得本身的设计越复杂,采用文件系统作为消息存储的方式. RocketMQ存储机制 消息中间件的存储一般都是利用磁盘,一般是使用机械硬盘,但机械硬盘的速度比访问内存慢了n个数量级,一款优秀的消息中间件必然会将硬件资源压榨到极致,接下来看看rocketMq是如何做到高效存储的. RocketMQ存储模型 CommitLog 消息主体以及元数据的存储媒介,存储Producer端写入的消息主体内

修改rocketmq官方代码测试: package com.alibaba.middleware.race.rocketmq; import java.util.Scanner; import com.alibaba.rocketmq.client.exception.MQClientException; import com.alibaba.rocketmq.client.producer.DefaultMQProducer; import com.alibaba.rocketmq.clien

一.什么是消息中间件 两个系统或两个客户端之间进行消息传送,利用高效可靠的消息传递机制进行平台无关的数据交流,并基于数据通信来进行分布式系统的集成.通过提供消息传递和消息排队模型,它可以在分布式环境下扩展进程间的通信. 消息中间件,总结起来作用有三个:异步化提升性能.降低耦合度.流量削峰. 系统A发送消息给中间件后,自己的工作已经完成了,不用再去管系统B什么时候完成操作.而系统B拉去消息后,执行自己的操作也不用告诉系统A执行结果,所以整个的通信过程是异步调用的. 二.消息中间件的应用场景 2.1

什么是JMS MQ 全称:Java MessageService 中文:Java 消息服务. JMS 是 Java 的一套 API 标准,最初的目的是为了使应用程序能够访问现有的 MOM 系 统(MOM 是 MessageOriented Middleware 的英文缩写,指的是利用高效可靠的消息传递机 制进行平台无关的数据交流,并基于数据通信来进行分布式系统的集成.) : 后来被许多现有 的 MOM 供应商采用,并实现为 MOM 系统.[常见 MOM 系统包括 Apache 的 ActiveM

转载请注明出处:http://www.cnblogs.com/xiaodf/ 本博客实现了一个简单的RocketMQ消费者的示例,MQ里存储的是经过Avro序列化的消息数据,程序读取数据并反序列化后,将消息从控制台打印出来. 程序通过stdin.xml配置文件获取主要参数值,stdin.xml文件内容如下: <?xml version="1.0" encoding="UTF-8"?> <operator> <parameters>

消费者角色: 1. 推式(一般建议用推式) 2. 拉式 消费模式: 1. 集群(cluster)                --均衡负载消费 2. 广播(broadcasting) --发布和订阅者模式 MQ的消费不会清除broker中的数据,broker数据一直存在队列中,队列offset会一直递增,因此可以通过回查来获取到丢失数据.这个时候我们可以采用pull形式较好. push形式,MQ会记录访问的偏移量,即使宕机下次重启也会按照顺序继续消费,不会出现重复消费. 在RocketMQ入门

[不同类型的消费者] DefaultMQPushConsumer 由系统控制读取操作,收到消息后自动调用传入的处理方法来处理. DefaultMQPullConsumer 读取操作中的大部分功能由使用者自动控制. [DefaultMQPushConsumer的使用] [特点] 1.系统收到消息后自动调用处理方法来处理消息,自动保存Offset. 2.加入的新的DefaultMQPushConsumer会自动做负载均衡. public class QuickStart { /** * Defaul

最近工作中用到了RocketMQ,现记录下,如何正确实现消费~ 消费者需要注意的问题 防止重复消费 如何快速消费 消费失败如何处理 Consumer具体实现 防止重复消费 重复消费会造成数据不一致等问题.所以,消费者要做到消费幂等. 1)每次消费,记录messageId:如果再次消费该message,查询messageId是否已存在,已存在,就跳过消费: 2)使用具体业务状态来防止重复消费,例如如果状态已经被变更,说明已有消息被消费: 如何快速消费 消费过程缓慢,势必会造成消息积压,如何提高消费

一.问题答案 是不可以的 而且后注册的会替换前注册的,MqConsumer2会替换MqConsumer,并且只结束tag-2的消息 /** * @date 2019/05/28 */ @Component @Slf4j public class MqConsumer implements MessageConsumer { @Override @Transactional(rollbackFor = Throwable.class, propagation = Propagation.REQUI

1.遇到的问题:上测试环境,上次描述的鸟问题又出现了,就是生产者发3条数据,我这边只能收到1条数据. 2.问题解决: (1)去控制台看我的消费者启动情况,貌似没什么问题 , (2)去测试服务器里看日志信息:只有入库的那条是真的接收到了,其余压根就没有接收到,排除入库过程的代码问题.到此,问题只锁定在我的consumer根本没有接收到丢失的那两条消息. (3)仔细思考一下,发现了问题的根源,看图一的控制台信息,可以发现,生产者默认给我分配了四个队列,但是我的消费者只用了两个队列,这就是和那天的问题