1 启动消费者等待传入的订阅消息 import org.apache.rocketmq.client.consumer.DefaultMQPushConsumer; import org.apache.rocketmq.client.consumer.listener.ConsumeConcurrentlyContext; import org.apache.rocketmq.client.consumer.listener.ConsumeConcurrentlyStatus; import o

RocketMQ简介 RocketMQ是一款开源的分布式消息系统,基于高可用分布式集群技术,提供低延时的.高可靠.万亿级容量.灵活可伸缩的消息发布与订阅服务. 它前身是MetaQ,是阿里基于Kafka的设计使用Java进行自主研发的.在2012年,阿里将其开源, 在2016年,阿里将其捐献给Apache软件基金会(Apache Software Foundation,简称为ASF),正式成为孵化项目.2017 年,Apache软件基金会宣布RocketMQ已孵化成为 Apache顶级项目(Top

痛点背景 业务场景 假设有这么一个需求,用户下单后如果30分钟未支付,则该订单需要被关闭.你会怎么做? 之前方案 最简单的做法,可以服务端启动个定时器,隔个几秒扫描数据库中待支付的订单,如果(当前时间-订单创建时间)>30分钟,则关闭订单. 方案评估 优点:是实现简单,缺点呢? 缺点:定时扫描意味着隔个几秒就得查一次数据库,频率高的情况下,如果数据库中订单总量特别大,这种高频扫描会对数据库带来一定压力,待付款订单特别多时(做个爆品秒杀活动,或者啥促销活动),若一次性查到内存中,容易引起宕机,需要

概述 在上文中,我们讨论了消费者对于消息拉取的实现,对于 RocketMQ 这个黑盒的心脏部分,我们顺着消息的发送流程已经将其剖析了大半部分.本章我们不妨乘胜追击,接着讨论各种不同的消息的原理与实现. 事务消息 概念 RocketMQ 中的事务消息功能,实际上是 分布式事务中的本地事务表 的实现,只不过,在这里用消息中间件来代替了数据库,同时也帮我们做好了回查的操作. 在这点上,RocketMQ 和 Kafka 是截然不同的,kafka 的事务是用来实现 Exacltly Once 语义,且该语

前言篇: 为了节约成本,决定通过自研来改造rocketmq,添加任意时间延迟的延时队列,开源版本的rocketmq只有支持18个等级的延迟时间, 其实对于大部分的功能是够用了的,但是以前的项目,全部都是使用了阿里云的rocketmq,原因是不同的供应商的订单的延时时间是不同的 (部分供应商的订单未支付30分钟取消,有些1个半小时取消,各种时间都有), 所以使用了大量的延时队列,但是开源版本不支持任意时间延时(希望官方支持这个功能) 为了实现这个功能,网上查询了不少资料,查询到不少相关的文章,主要

什么是定时消息和延迟消息? 定时消息:Producer 将消息发送到 MQ 服务端,但并不期望这条消息立马投递,而是推迟到在当前时间点之后的某一个时间投递到 Consumer 进行消费,该消息即定时消息. 延迟消息:Producer 将消息发送到 MQ 服务端,但并不期望这条消息立马投递,而是延迟一定时间后才投递到 Consumer 进行消费,该消息即延时消息. 定时消息与延迟消息在代码配置上存在一些差异,但是最终达到的效果相同:消息在发送到 MQ 服务端后并不会立马投递,而是根据消息中的属性延

rocketmq提供一种延时消息的解决方案,就是在特定的时间到了,消息才会被投递出去供consumer消费. 总体来是简单的场景是满足了,但是需要注意的是延时的时间是需要按照默认配置的延时级别去配置的,而不是随意设置消息的延时时间. 如果想不受延时级别的约束 可以参考之前的一遍文章http://blog.seoui.com/2017/08/19/delayqueue/ 默认的延迟级别 messageDelayLevel=1s 5s 10s 30s 1m 2m 3m 4m 5m 6m 7m 8m

1.架构 RocketMQ的master broker与master broker没有任何消息通讯,nameserver之间也同样没有消息通信 MQ历史 由数据结构队列发展而来 MQ使用场景    异步处理 解耦 削峰填谷 数据同步 2.队列 rocketMQ一个主题(topic)包含多个队列 3.使用 生产 同步(sync) 默认重试2次总共3次 默认等待超时时间为3s 异步(async) 总共重试2次 单向(oneway) Message topic:主题名称 tag:消息TAG,用于消息过

最近正在研究rocketmq,简单记录下设计的不同 互联网系统中Rpc.服务治理.消息中间件基本都是标配,消息中间件能解耦,削峰,高可用并能间接提供达到最终一致性 消息中间件中,消息消费分为最多一次,至少一次和刚好一次,如果需要实现刚好一次,则系统设计难度增大,系统性能损失增加,权衡利弊,rocket实现的是最少一次,消费端可能会重复接收消息(ACK模式下,ACK消息可能丢失),由消费端幂等消费 为什么不用zk,还是从实际需求出发,Topic路由信息无需在集群之间保持强一致性,最终一致即可,从而

一个topic有多个队列,分散在不同的broker.producer在发送消息的时候,需要选择一个队列 producer发送消息全局时序图: 队列选择与容错策略结论: 在不开启容错的情况下,轮询队列进行发送,如果失败了,重试的时候过滤失败的Broker 如果开启了容错策略,会通过RocketMQ的预测机制来预测一个Broker是否可用 如果上次失败的Broker可用那么还是会选择该Broker的队列 如果上述情况失败,则随机选择一个进行发送 在发送消息的时候会记录一下调用的时间与是否报错,根据该

rocketmq总结(消息的高可用.中间件选型) 参考: https://blog.csdn.net/meilong_whpu/article/details/76922456 http://blog.51cto.com/sofar/1540874 https://blog.csdn.net/lunaqi/article/details/78517200 https://mp.weixin.qq.com/s?__biz=MzIwMzg1ODcwMw==&mid=2247487688&idx

在讨论这个问题之前,我们先看一下Client的整体架构. Producer与Consumer类体系 从下图可以看出以下几点:(1)Producer与Consumer的共同逻辑,封装在MQClientInstance,MQClientAPIImpl, MQAdminImpl这3个蓝色的类里面.所谓共同的逻辑,比如定期更新NameServer地址列表,定期更新TopicRoute,发送网络请求等.(2)Consumer有2种,Pull和Push.下面会详细讲述这2者的区别. 下面将主要从Defaul

Broker差异 主从差异: kafka的master/slave是基于partition维度的,而rocketmq是基于broker维度的:kafka的master/slave是可以切换的,而rocketmq不行,当rocketmq的master宕机时,读能被路由到slave上,但写会被路由到此topic的其他broker上.刷盘: rocketmq支持同步刷盘,也就是每次消息都等刷入磁盘后再返回,保证消息不丢失,但对吞吐量稍有影响.一般在主从结构下,选择异步双写策略是比较可靠的选择.消息查询

1.概述 Producer 发送消息.主要是同步发送消息源码,涉及到 异步/Oneway发送消息,事务消息会跳过. Broker 接收消息.(存储消息在<RocketMQ 源码分析 —— Message 存储>解析) 2.Producer 发送消息 DefaultMQProducer#send(Message) 1: @Override 2: public SendResult send(Message msg) throws MQClientException, RemotingExcept

RocketMQ消息支持的模式: 消息支持的模式分为三种:NormalProducer(普通同步),消息异步发送,OneWay. 消息同步发送: 普通消息的发送和接收在前面已经演示过了,在前面的案例中是基于同步消息发送模式.也就是说消息发送出去后,producer会等到broker回应后才能继续发送下一个消息. 消息异步发送: 异步发送是指发送方发出数据后,不等接收方发回响应,接着发送下个数据包的通讯方式. MQ 的异步发送,需要用户实现异步发送回调接口(SendCallback).消息发送方在

1:特点 比较吃内存 内存至少1g 默认8g 1:支持集群模型,强调集群无单点,负载均衡以及水平扩展能力2:亿级别的消息堆积能力3:采用零拷贝原理Consumer 消费消息过程,使用了零拷贝 顺序写盘随机读 4:丰富的api 同步消息,异步消息 顺序消息,延迟消息,事务消息 5:底层通信框架采用netty nio 6: nameserver 代替zookpeer 7:消息消费失败重试机制,消息可查询 灵活可扩展性RocketMQ 天然支持集群,其核心四组件(Name Server.Broker.

一.发展历程 早期淘宝内部有两套消息中间件系统:Notify和Napoli. 先有的Notify(至今12历史),后来因有序场景需求,且恰好当时Kafka开源(2011年),所以参照Kafka的设计理念自研了RocketMQ. 目前Notify和RocketMQ二者的定位如下: RocketQ 主要面向消息有序的场景,能够提供更大的消息堆积能力,拉模式,消息持久化在磁盘 Notify主要面向更加安全可靠地交易类场景,无序.推模式.消息持久化在mysql RocketMQ发展历程如下: Metaq

本文主要描述使用Idea获取rocketMQ源码及源码的读取. 在演示搭建源码环境前,先简要描述一下RocketMQ的设计目标. 1.架构模式 和大多数消息中间件一样,采用的是发布订阅模式,基本组件包括:消息发送者.消息服务器(消息存储).消息消费和路由发现 2.顺序消息 rocketMQ保证严格的顺序消息(消息到达服务器的时间) 3.消息过滤 rocketMQ既支持在broker端的消息过滤,也支持在消费端的消息过滤 4.消息存储 rocketMQ引入了内存机制,保证消息存储的高性能:同时将所

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

目录 1.MappedFile类属性说明 1.1.MappedFile类属性如下 1.2.MappedFile构造器说明 2.MappedFileQueue类说明 2.1.属性说明 2.2.MappedFileQueue构造器说明 2.2.1.对于commitlog 2.2.2.对于consumequeue 3.commitlog文件与MappedFileQueue MappedFile关系 3.1.broker启动创建commitlog对象,即创建MappedFileQueue对象 3.2.b