世界上并没有完美的程序，但是我们并不因此而沮丧，因为写程序就是一个不断追求完美的过程。

该异常会造成 消息丢失。该异常不会造成消息丢失。

RocketMQ定位于非日志的可靠消息传输（日志场景也OK），目前RocketMQ在阿里集团被广泛应用在订单，交易，充值，流计算，消息推送，日志流式处理，binglog分发等场景。RocketMQ的同步刷盘在单机可靠性上比Kafka更高，不会因为操作系统Crash，导致数据丢失。同时同步Replication也比Kafka异步Replication更可靠，数据完全无单点。

将有超过60%的新型数字商业解决方案会使用"事件驱动"模式。为了适应此趋势，Messaing正在演变为Eventing，诸如EventBridge（EventBroker）的产品形态便应运而生。在EventBridge中，“事件”概念成为一等公民，事件的发布者和订阅者无需依赖任何具体的消息队列SDK和实现。

函数将返回result，表示下一步应该消费的消息的offset，如果没有可消费的消息，则返回-1。msgs是需要消费的消息列表，这里使用了Collections.unmodifiableList方法来创建一个不可修改的消息列表，这是为了保证消息的安全性，防止消息在消费过程中被意外或恶意修改。如果消息列表为空，说明当前的 ProcessQueue 中没有更多的消息，结束当前的循环，并退出 synchronized 块，释放了 objLock 的锁，等待下一次的消费请求。消费结果会影响消息处理的下一步流程。

DefaultMQPushConsumer使用长轮训技术，让consumer不断向broker端请求消息，如果没有可消费的消息，则阻塞一段时间，等待broker推送消息给consumer。具体实现过程为，先每隔一段时间从broker获取消息进行消费，如果没有需要消费的消息，则调用poll函数向远程broker获取最新的消息，最长等待时间为Consumer的maxTimeConsumeConitnusly属性，如果超时时间到达还没有新的消息，则返回null。

针对之前的两篇文章中所出现的 [XXX - broker busy] 问题主要是由于Broker在追加消息时持有的锁时间超过了阈值（默认为1s），Broker为了自我保护，会实现快速失败->抛出错误，客户端会选择其他Broker服务器进行重试。综上所述，可以看出来在broker还没有发生“严重”的PageCache的broker busy问题，也就是消息追加以及加锁的最大时延没有超过阈值1s。

修改上述参数，都不可取，原因是出现system busy、broker busy这个错误，其本质是系统的PageCache繁忙，通俗一点讲就是向PageCache追加消息时，单个消息发送占用的时间超过1s了，如果继续往该Broker服务器发送消息并等待，其TPS根本无法满足，哪还是高性能的消息中间了呀。

首先，我们限定为源码的未知，这样子才可以方便我们去分析问题，以及探究根本的因素所在，源码方法太长，只好截图了，如下图所示。可以看到话红框的地方就是报错和打印的地方，大家可以使用自己的IDE进行搜索，这块的代码在。从上图可以看出，抛出上述错误的关键原因是：pair.getObject1().rejectRequest()返回了true所引起的错误。如果想要看清楚这个地方的代码，需要先认识一下NettyRequestProcessor、Pair、RequestCode。

承接上一章节的内容，下面我们看继续看拉取的调度模式，PULL与PUSH模式相比，PULL模式需要应用层不间断地进行拉取消息然后再执行消费处理，提高了应用层的编码复杂度，为了Pull方式的编程复杂度，RocketMQ提供了调度消费服务（MQPullConsumerScheduleService），在topic的订阅发送变化（初次订阅或距上次拉取消息超时）就触发PULL方式拉取消息。在 doPullTask() 完成自己的拉取消息逻辑，和DefaultMQPullConsumer是一样的。否则继续下面的处理；

调用NettyRemotingAbstract.invokeSyncImpl(Channel channel, RemotingCommand request, long timeoutMillis)方法，该方法的逻辑如下：使用请求的序列号（opaue）、超时时间初始化ResponseFuture对象；并将该ResponseFuture对象存入NettyRemotingAbstract.responseTable: ConcurrentHashMap变量中；

与PUSH模式相比，PULL模式需要应用层不间断地进行拉取消息然后再执行消费处理，提高了应用层的编码复杂度，为了Pull方式的编程复杂度，RocketMQ提供了调度消费服务（MQPullConsumerScheduleService），在topic的订阅发送变化（初次订阅或距上次拉取消息超时）就触发PULL方式拉取消息。在RocketMQ中有两种Pull方式，一种是比较原始Pull Consumer，它不提供相关的订阅方法，需要调用pull方法时指定队列进行拉取，并需要自己更新位点。

上面的逻辑是先会判断和校验PullRequest对象中的ProcessQueue对象的dropped是否为true（在RebalanceService线程中为topic下的MessageQueue创建拉取消息请求时要维护对应的ProcessQueue对象，若Consumer不再订阅该topic则会将该对象的dropped置为true）；消息通过生产者发送到某一个Topic，如果需要订阅该Topic并消费里面的消息的话，就要创建对应的消费者进行消费，而本文主要会进行介绍对应的消息队列的消费者。

RocketMQ目前在国内应该是比较流行的MQ 了，目前本人也在公司的项目中进行使用和研究，借着这个机会，分析一下RocketMQ 发送一条消息到存储一条消息的过程，这样会对以后大家分析和研究RocketMQ相关的问题有一定的帮助。

事务消息（Transactional Message）是指应用本地事务和发送消息操作可以被定义到全局事务中，要么同时成功，要么同时失败。RocketMQ的事务消息提供类似 X/Open XA 的分布事务功能，通过事务消息能达到分布式事务的最终一致。对没有Commit/Rollback的事务消息（pending状态的消息），Broker服务端会发起一次“回查”。生产者Producer收到回查消息，检查回查消息对应的本地事务的状态。生产者根据本地事务状态，重新Commit或者Rollback。

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

使用RocketMQ进行发消息时，一般我们是必须要指定topic，此外topic必须要提前建立，但是topic的创建（自动或者手动方式）的设置有一个开关autoCreateTopicEnable，此部分主要会在broker节点的配置文件的时候进行设置，运行环境中会使用默认设置autoCreateTopicEnable = true，但是这样就会导致topic的设置不容易规范管理，所以在生产环境中会在Broker设置参数autoCreateTopicEnable = false。

RocketMQ作为一款基于磁盘存储的中间件，具有无限积压能力，并提供高吞吐、低延迟的服务能力，其最核心的部分必然是它优雅的存储设计。本系列文章主要针对于RocketMQ的多个关键特性的实现原理进行深入介绍，并对消息中间件遇到的各种问题进行总结，阐述 RocketMQ如何解决这些问题。