RocketMQ设计架构以及工作流程

RocketMQ架构图

消息生产者

发送消息方式：

• 同步发送，消息发送至Broker后，需得到Broker的成功响应后才可进行下一个数据包发送。常用于重要消息业务场景，如通知邮件、营销短信等。
• 异步发送，消息发送至Broker后，响应以异步方式返回，无需得到成功响应信息即可进行下一个数据包发送，失败后会进行重试发送、持久化信息，常用于对响应时间敏感场景，如批量发货等。
• 单向发送，仅发送消息，并不关注发送结果的场景，失败后消息丢失。常用于对可靠性要求不高的场景，如日志收集。

消息消费类型

• 集群消费：消息仅被消费一次，消息重投不保证消费到同一台服务上。
• 广播消费：每条消息需要被集群下的每个消费者处理。

消息消费方式

• Pull模式：拉取待消费列表消息
• Push模式：基于Pull模式封装，线程拉取拉取到消息后，提交到消息消费线程池，再次向服务器尝试拉取消息。

Producer负载均衡

Producer端在发送消息时，会先根据Topic找到指定的TopicPublishInfo，根据TopicPublishInfo使用随机递增取模算法获取一个MessageQueue发送消息。

Consumer负载均衡

RocketMQ官方文档解释：

在RocketMQ中，Consumer端的两种消费模式（Push/Pull）都是基于拉模式来获取消息的，而在Push模式只是对pull模式的一种封装，其本质实现为消息拉取线程在从服务器拉取到一批消息后，然后提交到消息消费线程池后，又“马不停蹄”的继续向服务器再次尝试拉取消息。如果未拉取到消息，则延迟一下又继续拉取。在两种基于拉模式的消费方式（Push/Pull）中，均需要Consumer端知道从Broker端的哪一个消息队列中去获取消息。因此，有必要在Consumer端来做负载均衡，即Broker端中多个MessageQueue分配给同一个ConsumerGroup中的哪些Consumer消费。

RocketMQ消费端负载均衡主要是RebalanceImpl类实现的。

以rebalanceByTopic(final String topic, final boolean isOrder)方法的集群模式为例：

1. 根据topic获取消息消费队列
2. 所有topic对应的所有消费者Id
3. 对消费消息排序、对消费者id排序
4. 获取负载均衡策略，默认平均分配算法，返回分配后的mqSet
5. 更新消息处理队列
6. 移除在processQueueTable 并且不存在于mqSet中的消息队列
7. 把mqSet放入processQueueTable中
8. 发起Pull请求