RocketMQ

随着业务的持续增长，消息体量随之增大，对消息中间件平台提出了更高的要求，此外在运维过程中也遇到了高可用难以保障，功能特性不足等诸多问题。基于遇到的这些问题，决定引入RocketMQ进行替换。本文将介绍基于RocketMQ建设消息中间件平台并实现在线业务无感知的平滑迁移。

一个服务发送一个消息给MQ，即消息中间件，比如RocketMQ、RabbitMQ、Kafka、ActiveMQ等等。

本文主要讲解了 RocketMQ 广播消息的实现机制，理解广播消息。

正常情况下生产者组是没有作用的，但是在发送事务消息时，如果producer中途意外宕机，broker会主动回调producer group 内的任意一台机器来确认事务的状态。

本文主要讲解了 RocketMQ 的轨迹消息实现机制。轨迹消息分为生产端和消费端的轨迹消息，生产端和消费端 RocketMQ 都提供了构造函数来指定是否开启轨迹消息。通过钩子函数，把轨迹消息加入队列，也就是变量 traceContextQueue，而 traceDispatcher 则以 100 条为单位不停地从队列中拉取消息进行组装并发送到 Broker。

本文主要介绍了RocketMQ的消费者启动流程，结合官方源码和示例，一步步讲述消费者在启动和消息消费中的的工作原理及内容，并结合平时业务工作中，对我们所熟悉的顺序、push/pull模式等进行详细分析，以及对于消息消费失败和重投带来问题去进行分析。

RocketMQ 的事务消息实现机制非常简洁。使用事务消息时自己定义 TransactionListener，实现执行本地事务 executeLocalTransaction 和检查本地事务状态 checkLocalTransaction 这两个方法，然后使用 TransactionMQProducer 进行发送。

RocketMQ 顺序消息的原理是在 Producer 端把一批需要保证顺序的消息发送到同一个 MessageQueue，Consumer 端则通过加锁的机制来保证消息消费的顺序性，Broker 端通过对 MessageQueue 进行加锁，保证同一个 MessageQueue 只能被同一个 Consumer 进行消费。

延时消息的延时时间并不精确，这个时间是 Broker 调度线程把消息重新投递到原始的 MessageQueue 的时间，如果发生消息积压或者 RocketMQ 客户端发生流量管控，客户端拉取到消息后进行处理的时间可能会超出预设的延时时间。​

Broker 收到消息后，会把消息重新发送到 CommitLog，发送到 CommitLog 之前，首先会修改 Topic 为 SCHEDULE_TOPIC_XXXX，这样就发送到了延时队列，延时队列再根据延时级别把消息投递到原始的队列，这样消费者就能再次拉取到。

RocketMQ是阿里开源的消息中间件，目前是Apache下的顶级项目。正式在项目中接入RocketMQ之前，我们需要搭建RocketMQ的环境。

RocketMQ并发消费的消费者，在客户端消费失败后会向服务端发送ACK，根据重试次数进入到SCHEDULE_TOPIC_XXXX主题不同的队列中，每一个队列代表的延迟时间不一样，经过一定延迟时间后再次调度到消费组的重试主题，被消费者再次消费，实现时间间隔的重试，提高重试成功率。

RocketMQ一个纯java、分布式、队列模型的开源消息中间件，前身是MetaQ，是阿里研发的一个队列模型的消息中间件，后开源给apache基金会成为了apache的顶级开源项目，具有高性能、高可靠、高实时、分布式特点。

PULL 模式是从 Broker 拉取消息后放入缓存，然后消费端不停地从缓存取出消息来执行客户端定义的处理逻辑，而 PUSH 模式是在死循环中不停的从 Broker 拉取消息，拉取到后调用回调函数进行处理，回调函数中调用客户端定义的处理逻辑。

本文通过源码分析讲解了 RocketMQ 中 PULL 模式下的消费者启动过程，在生产上使用比较多的还是 PUSH 模式，PULL 模式拉取消息的方法跟 PUSH 模式一样，不同的是 PULL 模式需要应用程序进行拉取动作，可以通过 PULL 模式的学习更容易的理解 PUSH 模式。