RocketMQ

前言 RocketMQ 5.0 引入了新的 Proxy 组件，为了便于多语言客户端 SDK 的开发维护，客户端的很多功能也都下沉到了 Proxy，客户端因此变得更加轻量化了，新版客户端源码简洁易懂。

前言 RocketMQ 4.x 版本之前，一套完整的 MQ 服务包含的组件有：Namesrv、Broker、Consumer、Producer。 RocketMQ 5.0 版本之后，官方引入了一个新的

1. 前言 在RocketMQ体系中，系统预定义了一系列的Topic，开发者自定义的Topic名称不可以和它们重名，否则会抛异常。这些预定义的系统Topic都有它们各自的用途，例如RMQ_SYS_TR

1. 前言 在消息中间件中，消费者对于消费成功的消息，一般是需要返回ACK给Broker的，它的目的是让Broker知道消息已经被成功消费，不必再投递给其它消费者重试了。在RocketMQ中，这一过程

1. 前言 Consumer启动后会立即触发一次「重平衡」操作，给自己分配MessageQueue，对于新分配的MessageQueue会提交拉取请求，开始拉取消息进行消费。应用在消费消息时，返回消费

RocketMQ拥有海量的消息积压能力，主要是因为它支持消息的持久化，Broker接收到消息后，会将消息写入CommitLog文件。但是，磁盘IO的效率较低，为了保证性能和吞吐量，RocketMQ通过

1. 前言 顺序消息是RocketMQ的特性之一，它可以让Consumer消费消息的顺序严格按照消息的发送顺序来进行。例如：一条订单产生的三条消息：订单创建、订单付款、订单完成。消费时要按照这个顺序依

1. 前言 RocketMQ采用2PC的思想，实现了Producer发送「事务消息」。事务消息的提交分为两个阶段，阶段一，Producer发送半事务(Half)消息到Broker，Broker存储消息

1. 前言 定时消息(延迟消息)是RocketMQ比较有用的特性之一，定时消息被发送到Broker后，不会马上投递给Consumer，而是等待特定的时间，然后再投递消费。应用场景举例：用户下单后，系统

1. 前言 之前的文章介绍了Consumer是怎么拉取消息的，但是没有介绍Broker是如何处理Consumer消息拉取请求的，Broker在接收到Consumer的消息拉取请求后，是如何检索消息然后

1. 前言 MQConsumer是RocketMQ提供的消费者接口，从接口定义上可以看到，它主要的功能是订阅感兴趣的Topic、注册消息监听器、启动生产者开始消费消息。 ​ 消费者获取消息的模式有两种

1. 前言 Broker会把Producer发送的消息写入到CommitLog，理论上来说，RocketMQ只要有CommitLog文件就可以正常运行了。构建额外的ConsumeQueue是为了加速消

1. 前言 理论上来说，RocketMQ只要有CommitLog文件就可以正常运行了，那为何还要维护ConsumeQueue文件呢？ ​ ConsumeQueue是消费队列，引入它的目的是为了提高消费

1. 前言 生产者调用MQProducer.send()方法会将消息发送到Broker，Broker是如何处理该请求，以及消息是如何存储的呢？ ​ RocketMQ网络通信协议被封装成Java对象Re

1. 前言 MQProducer是RocketMQ提供的生产者接口，默认实现为DefaultMQProducer，如果要发送事务消息，对应的实现类为TransactionMQProducer。本篇暂不

1. 前言 RocketMQ架构体系里有四个角色：NameServer、Broker、Producer、Consumer。其中，Broker统称为服务端，Producer和Consumer统称为客户端