当我们用RocketMQ发送信息的时候通常都会返回如下信息: SendResult [sendStatus=SEND_OK, msgId=0A42333A0DC818B4AAC246C290FD0000, offsetMsgId=0A42333A00002A9F000000000134F1F5, messageQueue=MessageQueue [topic=topicTest1, brokerName=mac.local, queueId=3], queueOffset=4] 对于客户端来说

最近,在公司的测试环境,遇到个问题,每次重启应用重启后,原来消费过的消息又被重复推送了一遍,消费者和生产者代码如下: package com.tf56.queue.client; import java.util.concurrent.TimeUnit; import com.alibaba.rocketmq.client.exception.MQBrokerException; import com.alibaba.rocketmq.client.exception.MQClientExcep

最近在调试RocketMQ消息发送与消费的Demo时,发现一个问题:只要重启程序,RocketMQ消息就会重复消费. 那么这是什么原因导致的,又该如何解决呢? 经过一番排查,发现程序使用的RocketMQ客户端版本是3.6.2,而测试环境安装的RocketMQ环境的版本是4.1.0.原来是客户端和服务器端版本不一样导致的,消息并没有最终被消费,即没有ACK消息确认,只要程序重启就会重复消费. 解决方案:RocketMQ客户端版本使用与服务器端的同一版本,即4.1.0版本. 划重点:使用Rocke

前言 在之前的MQ专题中,我们已经解决了消息中间件的一大难题,消息丢失问题. 但MQ在实际应用中不是说保证消息不丢失就万无一失了,它还有两个令人头疼的问题:重复消费和乱序. 今天我们就来聊一聊这两个常见的问题,看看RocketMQ是如何解决这两个问题的. 为什么会重复消费 首先我们来聊一聊重复消费的问题,要解决一个问题最开始的一步当然是去查找问题发生的原因了. 那出现重复消费的原因到底是什么呢? 我们先来思考一下生产者发送消息这一过程中是不是有可能重复发送消息到MQ呢? 答案是肯定的,比如生产者

https://blog.csdn.net/jiangyu1013/article/details/81668671 消息中间件的作用 1. 应用解耦 2. 异步处理 比如用户注册场景,注册主流程完成以后,需要调用邮件系统发送邮件通知用户注册成功,可能还需要调用其他系统.这是串行的,如果一个系统依赖很多系统,那么这个主流程会比较长,耦合度高,整个系统维护成本也会越来越高.那么我们就可以使用消息中间件来进行解耦,通过发布订阅模式,完成用户注册之后,向中间件发送消息,这样就可以马上给用户返回,至于后

一.为什么选择RocketMQ消息队列? 首先RocketMQ是阿里巴巴自研出来的,也已开源.其性能和稳定性从双11就能看出来,借用阿里的一句官方介绍:历年双 11 购物狂欢节零点千万级 TPS.万亿级数据洪峰,创造了全球最大的业务消息并发以及流转纪录(日志类消息除外): 在始终保证高性能前提下,支持亿级消息堆积,不影响集群的正常服务,在削峰填谷(蓄洪).微服务解耦的场景下尤为重要:这,就能说明RocketMQ的强大. 二.RocketMQ的特点和优势(可跳过看三的整合代码) 削峰填谷(主要解决

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

一.造成重复消费的原因 在于回馈机制.正常情况下,消费者在消费消息时候,消费完毕后,会发送一个ACK确认信息给消息队列(broker),消息队列(broker)就知道该消息被消费了,就会将该消息从消息队列中删除. 不同的消息队列发送的确认信息形式不同,例如RabbitMQ是发送一个ACK确认消息,RocketMQ是返回一个CONSUME_SUCCESS成功标志,kafka实际上有个offset的概念. 造成重复消费的原因?,就是因为网络原因闪断,ACK返回失败等等故障,确认信息没有传送到消息队列

首先整理这个文章是因为我正好有机会实战了一下rocketmq,阿里巴巴的一个开源消息中间件.所以就与以往中rabbitmq进行小小的比较一下.这里主线的根据常见面试问题进行整理. 一.消息队列常用的场景 1.削峰 例如我们做得考试系统中,用户通过人脸识别登录系统,考虑到考试系统的特殊性,三万名考生参加考试,需要记录人脸识别登录照片.从考试完结果上看,用户最大并发数在4000,于是我们采用rocketMq来进行异步消费用户人脸识别图片,当时统计rocketMq每秒1000消费消息.及时反馈了考生人

与中国移动代码的对应关系. MI::zzzzSMSC返回状态报告的状态值为EXPIREDMJ:zzzzSMSC返回状态报告的状态值为DELETEDMK:zzzzSMSC返回状态报告的状态值为UNDELIVML:zzzzSMSC返回状态报告的状态值为ACCEPTDMM:zzzzSMSC返回状态报告的状态值为UNKNOWNMN:zzzzSMSC返回状态报告的状态值为REJECTD 回页首 CMPP发送失败代码对照表 值(4位,不足4位前面补0) 含义1 消息结构错2 命令字错误3 消息序列号重复4

http://www.163duanxin.com/msg/1753.htm CMPP错误码说明   与中国移动代码的对应关系. MI::zzzzSMSC返回状态报告的状态值为EXPIREDMJ:zzzzSMSC返回状态报告的状态值为DELETEDMK:zzzzSMSC返回状态报告的状态值为UNDELIVML:zzzzSMSC返回状态报告的状态值为ACCEPTDMM:zzzzSMSC返回状态报告的状态值为UNKNOWNMN:zzzzSMSC返回状态报告的状态值为REJECTD 回页首 CMPP发

RocketMQ是阿里巴巴在2012年开源的分布式消息中间件,目前已经捐赠给Apache基金会,已经于2016年11月成为 Apache 孵化项目,相信RocketMQ的未来会发挥着越来越大的作用,将有更多的开发者因此受益. 本文仅对RocketMQ的简单实用做入门性介绍,不对RocketMQ的底层原理进行深入介绍,后续文章将对RocketMQ的原理做详细介绍. RocketMQ的Maven依赖: <!-- https://mvnrepository.com/artifact/com.aliba

rocketmq总结(消息的顺序.重复.事务.消费模式) 参考: http://www.cnblogs.com/wxd0108/p/6038543.html https://www.cnblogs.com/520playboy/p/6750023.html https://blog.csdn.net/chunlongyu/article/details/53977819 https://blog.csdn.net/zhanglianhai555/article/details/77604582?

备注:1.如果您此前未接触过RocketMQ,请先阅读附录部分,以便了解RocketMQ的整体架构和相关术语2.文中的MQServer与Broker表示同一概念 分布式消息系统作为实现分布式系统可扩展.可伸缩性的关键组件,需要具有高吞吐量.高可用等特点.而谈到消息系统的设计,就回避不了三个问题: 消息的顺序问题 消息的重复问题 消息的可靠性 RocketMQ作为阿里开源的一款高性能.高吞吐量的消息中间件,它是怎样来解决这两个问题的?RocketMQ 有哪些关键特性?其实现原理是怎样的? 关键特性

前情 出现了重复消费的问题,同一个消息被重复消费了多次,导致了用户端收到了多条重复的消息,最终排查发现,是因为消费者在处理消息的方法onMessage中有异常没有捕获到,导致异常上抛,被consumeMessage捕获并判定为消费失败,从而放到了重试队列当中进行重试,下面我们就来看看RocketMq中会引起消息重试的两种情况,内部异常和消费超时. 源码 在Consumer中处理消息时,会在消费完消息后判断消费的总时长,如果比超时时间要长则返回TIME_OUT,注意这里的超时是在consumeMe

分布式开放消息系统(RocketMQ)的原理与实践 RocketMQ基础:https://github.com/apache/rocketmq/tree/rocketmq-all-4.5.1/docs/cn 分布式消息系统作为实现分布式系统可扩展.可伸缩性的关键组件,需要具有高吞吐量.高可用等特点.而谈到消息系统的设计,就回避不了两个问题: 消息的顺序问题 消息的重复问题 RocketMQ作为阿里开源的一款高性能.高吞吐量的消息中间件,它是怎样来解决这两个问题的?RocketMQ 有哪些关键特性

消息队列常见问题处理 分布式事务 什么是分布式事务 常见的分布式事务解决方案 基于 MQ 实现的分布式事务 本地消息表-最终一致性 MQ事务-最终一致性 RocketMQ中如何处理事务 Kafka中如何处理事务 RabbitMQ中的事务 消息防丢失 生产阶段防止消息丢失 RabbitMQ 中的防丢失措施 Kafka 中的防丢失措施 RocketMQ 中的防丢失措施 存储阶段 RabbitMQ 中的防丢失措施 Kafka 中的防丢失措施 RocketMQ 中的防丢失措施 消费阶段 消息重复发送 参

1.如何保证消息的顺序 原因:生产者将消息发给topic,topic分发给不同的队列再给多个消费者并发消费,难以保证顺序. 方案:topic和队列之间加入MessageQueueSelector.将一组业务的消息发给同一个队列,并锁住发给某一个消费者消费. 2.如何保证消息不被重复消费 原因:由于网络波动或者消费者本地事务耗时长,让MQ认为失败,从而重复推送消息,但此时消费者的事务是成功了的. 方案:所有MQ都没有提供解决消息重复消费的方案. 需要消费者自行去重,如将RocketMQ给每个消息产

转自:http://www.changeself.net/archives/rocketmq入门(2)最佳实践.html RocketMQ入门(2)最佳实践 一.服务端安装部署 我是在虚拟机中的CentOS6.5中进行部署. 1.下载程序 2.tar -xvf alibaba-rocketmq-3.0.7.tar.gz 解压到适当的目录如/opt/目录 3.启动RocketMQ:进入rocketmq/bin 目录 执行 1 nohup sh mqnamesrv & 4.启动Broker,设置对应

参考: 开源社区: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 日,阿里巴巴宣布将开源分布式消息中