LoveSummer

1 技术架构RocketMQ架构上主要分为四部分，如上图所示:Producer：消息发布的角色，支持分布式集群方式部署。Producer通过MQ的负载均衡模块选择相应的Broker集群队列进行消息投递，投递的过程支持快速失败并且低延迟。Consumer：消息消费的角色，支持分布式集群方式部署。支持以push推，pull拉两种模式对消息进行消费。同时也支持集群方式和广播方式的消费，它提供实时消息订阅机制，可以满足大多数用户的需求。NameServer：NameServer是一个非常简单的Topic

明明服务器有32GB内存，可JVM却只能使用4GB，剩下的内存成了"摆设"。又或者，你是否好奇为什么Kafka、RocketMQ这样的高性能消息队列系统能轻松处理TB级的数据而不会引起频繁的GC？今天，让我们一起揭开堆外内存的神秘面纱。公司有一个中心仓库（JVM堆内存），所有的包裹都要经过这个仓库的处理。这时你会想：如果能在公司周边设立一些小型中转站（堆外内存），直接处理一些大件包裹，是不是就能解决这些问题？它像一个"管家"，虽然自己住在JVM堆里（很小的对象），但管理的是堆外的"领地"（直接内存）。

在传统 IO 中，如果想将用户缓存区的数据放到内核缓冲区，需要经过 CPU 拷贝而基于零拷贝技术可以减少 CPU 拷贝次数，常见的有两种：mmap()sendfile()mmap() 是将用户缓冲区和内核缓冲区共享，操作用户缓冲区就好像直接操作内核缓冲区，读写数据时不需要 CPU 拷贝Java 中可以使用 MappedByteBuffer 这个 API 来达到操作内核缓冲区的效果。

RocketMQ 5.0 把客户端的部分功能下沉到 Proxy，Proxy 承接了之前 客户端的计算能力，客户端变得更加轻量级。LOCAL 模式更适合对延迟敏感、期望运维成本低、网络接入类型单一的场景。CLUSTER 模式更适合对延迟要求低、网络接入类型多样的场景。RocketMQ 5.0 跟之前的版本相比，改动很大，更加地拥抱云原生。学习 RocketMQ 5.0，首先要理解 Proxy，希望本文能对您理解 Proxy 有所帮助。

本文介绍了 RocketMQ 灰度消息的使用方法，场景比较简单。对于全链路的复杂灰度场景，可以参考使用阿里的微服引擎 MSE。

对于 Master-Slave 架构的升级，RocketMQ 5.0 引入了 BrokerContainer 的概念，一个 BrokerContainer 中可以部署多个 Broker，这些 Broker 拥有独立的端口，功能完全独立，可以通过 admin 来增加或减少 Broker。RocketMQ 5.0 专门增加了轻量级的 DLedgerControlller 选主组件，将选主的切换能力上移，这个组件是可拔插的，既可以部署在 NameServer 中，也可以部署在本地。

RocketMQ 的延时消息是指 Producer 发送消息后，Consumer 不会立即消费，而是需要等待固定的时间才能消费。在一些场景下，延时消息是很有用的，比如电商场景下关闭 30 分钟内未支付的订单。使用延时消息非常简单，只需要给消息的 delayTimeLevel 属性赋值就可以。//第 3 个级别，10s.build())//定义消息投递时间.build()).build()),RocketMQ 4.x 版本只支持延时消息，有一些局限性。

本文作者：金吉祥， Apache RocketMQ PMC Member，阿里云智能高级技术专家。

所以从以上的分析可以看出，RocketMQ对于push的消费方式的实现是基于长轮询机制来实现的，同时平衡了实时和压力，这其实就很nice了。最后我想说一句，其实不论是pull还是push，又或是轮询和长轮询，其实都是一种理论或者说是一种思想，不单单是MQ的东西，就比如在Nacos中，也使用了push和长轮询机制。但是这些理论在不同产品的具体实现，实现方式可能不太一样，但都是大同小异，所以当你懂了这些思想，再看其它框架的源码，其实就很容易了。...

我们的服务器从单机发展到拥有多台机器的分布式系统，各个系统之前需要借助于网络进行通信，原有单机中相对可靠的方法调用以及进程间通信方式已经没有办法使用，同时网络环境也是不稳定的，造成了我们多个机器之间的数据同步问题，这就是典型的分布式事务问题。在分布式事务中事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上。分布式事务就是要保证不同节点之间的数据一致性。1、2PC(二阶段提交)方案 - 强一致性2、3PC(三阶段提交)方案3、TCC （Try-Confirm-Can

RocketMQ 实现了灵活的多分区和多副本机制，有效的避免了集群内单点故障对于整体服务可用性的影响。存储机制和高可用策略是 RocketMQ 稳定性的核心，社区上关于 RocketMQ 目前存储实现的分析与讨论一直是一个热议的话题。本文想从一个不一样的视角，着重于谈谈我眼中的这种存储实现是在解决哪些复杂的问题，因此我从本文最初的版本中删去了冗杂的代码细节分析，由浅入深的分析存储机制的缺陷与优化方向。先来简单介绍下 RocketMQ 的架构模型。RocketMQ 是一个典型的发布订阅系统，通过 Broker

Producer对于消息的发送方式也有多种选择，不同的方式会产生不同的系统效果。同步发送消息是指，Producer发出⼀条消息后，会在收到MQ返回的ACK之后才发下⼀条消息。该方式的消息可靠性最高，但消息发送效率太低。异步发送消息异步发送消息是指，Producer发出消息后无需等待MQ返回ACK，直接发送下⼀条消息。该方式的消息可靠性可以得到保障，消息发送效率也可以。单向发送消息单向发送消息是指，Producer仅负责发送消息，不等待、不处理MQ的ACK。该发送方式时MQ也不返回ACK。该方式的

延时消息是指发送到 RocketMQ 后不会马上被消费者拉取到，而是等待固定的时间，才能被消费者拉取到，而不是立刻被消费。延时消息的使用场景很多，比如电商场景下关闭超时未支付的订单，某些场景下需要在固定时间后发送提示消息。首先看一个生产者发送延时消息的官方示例代码：从上面的代码可以看到，跟普通消息不一样的是，消息设置 setDelayTimeLevel 属性值，这里设置为 3，这里最终将 3 这个延时级别复制给了 DELAY 属性。关于延时级别，可以看下面这个定义：这里延时级别有 18 个，上面的示例代

你们为什么使用mq？具体的使用场景是什么？mq的作用很简单，削峰填谷。以电商交易下单的场景来说，正向交易的过程可能涉及到创建订单、扣减库存、扣减活动预算、扣减积分等等。每个接口的耗时如果是100ms，那么理论上整个下单的链路就需要耗费400ms，这个时间显然是太长了。如果这些操作全部同步处理的话，首先调用链路太长影响接口性能，其次分布式事务的问题很难处理，这时候像扣减预算和积分这种对实时一致性要求没有那么高的请求，完全就可以通过mq异步的方式去处理了。同时，考虑到异步带来的不一致的问题，我们可以通过j

前言MQ的主要特点为解耦、异步、削峰，该文章主要记录与分享个人在实际项目中的RocketMQ削峰用法，用于减少数据库压力的业务场景，其中RocketMQ的核心组件概念如下：Producer：生产发送消息Broker：存储Producer发送过来的消息Consumer：从Broker拉取消息并进行消费NameServer：为Producer或Consumer路由到Broker其中消费流程有以下几点是必须注意的：RocketMQ的Consumer获取消息是通过向Broker

前言金三银四即将来临，整理了十道十分经典的消息队列面试题，看完肯定对面试有帮助的，大家一起加油哈~什么是消息队列消息队列的应用场景消息队列如何解决消息丢失问题消息队列如何保证消息的顺序性。消息有可能发生重复消费吗？如何幂等处理？如何处理消息队列的消息积压问题消息队列技术选型，Kafka还是RocketMQ，还是RabbitMQ消息中间件如何做到高可用？如何保证数据一致性，事务消息如何实现如果让你写一个消息队列，该如何进行架构设计？1. 什么是消息队列你可以把消息队列理解为一个使

ConsumeTimeout最长的消费时间，如果超过了这个时间就认为消息消费失败了；主要目的 是为了能尽早的将 offset 确认，避免消息重复，例如对于并发消息有 100 条 0~99 ， 第 0 条长时间消费没成功，后面的 99 条消费成功了，如果不将第 0 条失败掉，那么 offset 一直不能后移到 100，假如此时进行 rebalance 后面的 99 条就有可能进行重 新消费。 设置方式：默认 15 分钟。作用域：无序集群消费。原理：对于并发消费 ConsumerMessageConc

众所周知，在分布式领域有两大经典理论：CAP 和 BASE。一般情况下，我们将CAP中的数据一致性称为“强一致性”，将BASE中的数据一致性称为“最终一致性”。基于BASE理论实现最终一致性有几种常见做法：基于可靠队列实现，TCC，SAGA。本篇文章我们主要基于RocketMQ来实现最终一致性，希望对你有所帮助！RocketMQ事务消息Apache RocketMQ在4.3.0版中已经支持分布式事务消息，这里RocketMQ采用了2PC的思想来实现了提交事务消息，同时增加一个补偿逻辑来处理二阶段超时

本期带来的内容是 RocketMQ 核心知识点。建议收藏起来慢慢看~Windows安装部署下载地址：https://www.apache.org/dyn/closer.cgi?path=rocketmq/4.5.2/rocketmq-all-4.5.2-bin-release.zip选择‘Binary’进行下载解压已下载工程配置新增系统变量 ROCKETMQ_HOME -> F:\RocketMQ\rocketmq-4.5.2JAVA_HOME ->

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

1. 高级功能1.1 消息存储分布式队列因为有高可靠性的要求，所以数据要进行持久化存储。消息生成者发送消息MQ收到消息，将消息进行持久化，在存储中新增一条记录返回ACK给生产者MQ push 消息给对应的消费者，然后等待消费者返回ACK如果消息消费者在指定时间内成功返回ack，那么MQ认为消息消费成功，在存储中删除消息，即执行第6步；如果MQ在指定时间内没有收到ACK，则认为消息消费失败，会尝试重新push消息,重复执行4、5、6步骤MQ删除消息(定时删除)1.1.1 存储介质关

1.1 消息存储分布式队列因为有高可靠性的要求，所以数据要进行持久化存储。消息生成者发送消息MQ收到消息，将消息进行持久化，在存储中新增一条记录返回ACK给生产者MQ push 消息给对应的消费者，然后等待消费者返回ACK如果消息消费者在指定时间内成功返回ack，那么MQ认为消息消费成功，在存储中删除消息，即执行第6步；如果MQ在指定时间内没有收到ACK，则认为消息消费失败，会尝试重新push消息,重复执行4、5、6步骤MQ删除消息(定时删除)1.1.1 存储介质关系型数据库DB

1. 案例介绍1.1 业务分析模拟电商网站购物场景中的【下单】和【支付】业务1）下单用户请求订单系统下单订单系统通过RPC调用订单服务下单订单服务调用优惠券服务，扣减优惠券订单服务调用调用库存服务，校验并扣减库存订单服务调用用户服务，扣减用户余额订单服务完成确认订单2）支付用户请求支付系统支付系统调用第三方支付平台API进行发起支付流程用户通过第三方支付平台支付成功后，第三方支付平台回调通知支付系统支付系统调用订单服务修改订单状态支付系统调用积分服务添加积分支付系

一、普通消息1 消息发送分类Producer对于消息的发送方式也有多种选择，不同的方式会产生不同的系统效果。同步发送消息同步发送消息是指，Producer发出⼀条消息后，会在收到MQ返回的ACK之后才发下⼀条消息。该方式的消息可靠性最高，但消息发送效率太低。异步发送消息异步发送消息是指，Producer发出消息后无需等待MQ返回ACK，直接发送下⼀条消息。该方式的消息可靠性可以得到保障，消息发送效率也可以。单向发送消息单向发送消息是指，Producer仅负责发送消息，不等待、不处理MQ的

消息被消费过后会被清理掉吗？不会的。消息是被顺序存储在commitlog文件的，且消息大小不定长，所以消息的清理是不可能以消息为单位进行清理的，而是以commitlog文件为单位进行清理的。否则会急剧下降清理效率，并实现逻辑复杂。commitlog文件存在一个过期时间，默认为72小时，即三天。除了用户手动清理外，在以下情况下也会被自动清理，无论文件中的消息是否被消费过：文件过期，且到达清理时间点（默认为凌晨4点）后，自动清理过期文件文件过期，且磁盘空间占用率已达过期清理警戒线（默认75%）后，无

概念消息处理流程中，如果Consumer的消费速度跟不上Producer的发送速度，MQ中未处理的消息会越来越多（进的多出的少），这部分消息就被称为堆积消息。消息出现堆积进而会造成消息的消费延迟。以下场景需要重点关注消息堆积和消费延迟问题：业务系统上下游能力不匹配造成的持续堆积，且无法自行恢复。业务系统对消息的消费实时性要求较高，即使是短暂的堆积造成的消费延迟也无法接受。产生原因分析Consumer使用长轮询Pull模式消费消息时，分为以下两个阶段：消息拉取Consumer通过长轮询

什么是消费幂等当出现消费者对某条消息重复消费的情况时，重复消费的结果与消费一次的结果是相同的，并且多次消费并未对业务系统产生任何负面影响，那么这个消费过程就是消费幂等的。幂等：若某操作执行多次与执行一次对系统产生的影响是相同的，则称该操作是幂等的。在互联网应用中，尤其在网络不稳定的情况下，消息很有可能会出现重复发送或重复消费。如果重复的消息可能会影响业务处理，那么就应该对消息做幂等处理。消息重复的场景分析什么情况下可能会出现消息被重复消费呢？最常见的有以下三种情况：发送时消息重复当一条

这里的offset指的是Consumer的消费进度offse消费进度offset是用来记录每个Queue的不同消费组的消费进度的。根据消费进度记录器的不同，可以分为两种模式：本地模式和远程模式。offset本地管理模式当消费模式为广播消费时，offset使用本地模式存储。因为每条消息会被所有的消费者消费，每个消费者管理自己的消费进度，各个消费者之间不存在消费进度的交集。Consumer在广播消费模式下offset相关数据以json的形式持久化到Consumer本地磁盘文件中，默认文件路径为.

订阅关系的一致性指的是，同一个消费者组（Group ID相同）下所有Consumer实例所订阅的Topic与Tag及对消息的处理逻辑必须完全一致。否则，消息消费的逻辑就会混乱，甚至导致消息丢失。1 正确订阅关系多个消费者组订阅了多个Topic，并且每个消费者组里的多个消费者实例的订阅关系保持了一致。2 错误订阅关系一个消费者组订阅了多个Topic，但是该消费者组里的多个Consumer实例的订阅关系并没有保持一致。订阅了不同Topic该例中的错误在于，同一个消费者组中的两个Consumer

消费者从Broker中获取消息的方式有两种：pull拉取方式和push推动方式。消费者组对于消息消费的模式又分为两种：集群消费Clustering和广播消费Broadcasting。获取消费类型拉取式消费Consumer主动从Broker中拉取消息，主动权由Consumer控制。一旦获取了批量消息，就会启动消费过程。不过，该方式的实时性较弱，即Broker中有了新的消息时消费者并不能及时发现并消费。由于拉取时间间隔是由用户指定的，所以在设置该间隔时需要注意平稳：间隔太短，空请求比例会增加；间

除了通过通常的指定Topic进行消息消费外，RocketMQ还提供了根据key进行消息查询的功能。该查询是通过store目录中的index子目录中的indexFile进行索引实现的快速查询。当然，这个indexFile中的索引数据是在包含了key的消息被发送到Broker时写入的。如果消息中没有包含key，则不会写入。索引条目结构每个Broker中会包含一组indexFile，每个indexFile都是以一个时间戳命名的（这个indexFile被创建时的时间戳）。每个indexFile文件由三部分

RocketMQ中的消息存储在本地文件系统中，这些相关文件默认在当前用户主目录下的store目录中。abort：该文件在Broker启动后会自动创建，正常关闭Broker，该文件会自动消失。若在没有启动Broker的情况下，发现这个文件是存在的，则说明之前Broker的关闭是非正常关闭。checkpoint：其中存储着commitlog、consumequeue、index文件的最后刷盘时间戳commitlog：其中存放着commitlog文件，而消息是写在commitlog文件中的config

1 消息的生产过程Producer可以将消息写入到某Broker中的某Queue中，其经历了如下过程：Producer发送消息之前，会先向NameServer发出获取消息Topic的路由信息的请求NameServer返回该Topic的路由表及Broker列表Producer根据代码中指定的Queue选择策略，从Queue列表中选出一个队列，用于后续存储消息Produer对消息做一些特殊处理，例如，消息本身超过4M，则会对其进行压缩Producer向选择出的Queue所在的Br

本文主要介绍RocketMQ中Topic、Tag、GroupName的概念、设计初衷以及使用方法。一.Topic首先看看官方的定义：Topic是生产者在发送消息和消费者在拉取消息的类别。Topic与生产者和消费者之间的关系非常松散。具体来说，一个Topic可能有0个，一个或多个生产者向它发送消息；相反，一个生产者可以发送不同类型Topic的消息。类似的，消费者组可以订阅一个或多个主题，只要该组的实例保持其订阅一致即可。Topic在Google翻译中解释为话题。我们可以理解为第一级消息类型，类比于

1 生产者1.1 发送消息注意事项1 Tags的使用一个应用尽可能用一个Topic，而消息子类型则可以用tags来标识。tags可以由应用自由设置，只有生产者在发送消息设置了tags，消费方在订阅消息时才可以利用tags通过broker做消息过滤：message.setTags(“TagA”)。2 Keys的使用每个消息在业务层面的唯一标识码要设置到keys字段，方便将来定位消息丢失问题。服务器会为每个消息创建索引（哈希索引），应用可以通过topic、key来查询这条消息内容，以及消息被谁消费。.

消息发送样例导入MQ客户端依赖<dependency> <groupId>org.apache.rocketmq</groupId> <artifactId>rocketmq-client</artifactId> <version>4.4.0</version></dependency>消息发送者步骤分析r1.创建消息生产者producer，并制定生产者组名2.指定

本讲咱们将学习以下三方面内容：介绍消息队列与 Alibaba RocketMQ；掌握 RocketMQ 的部署方式；讲解微服务接入 RocketMQ 的开发技巧；首先咱们先来认识什么是消息队列 MQ 呢？消息队列与 RocketMQ消息队列 MQ消息队列（Message Queue）简称 MQ，是一种跨进程的通信机制，通常用于应用程序间进行数据的异步传输，MQ 产品在架构中通常也被叫作“消息中间件”。它的最主要职责就是保证服务间进行可靠的数据传输，同时实现服务间的解耦。这么说