设计概念

基于topic的发布/订阅

其核心功能包括：

• 消息发送
• 消息存储
• 消息消费

设计目标

• 架构模式
  与大部分消息中间件一样，采用发布订阅模式，基本参与组建：消息发送者，消息服务器（消息存储）、消息消费、路由发现。

• 顺序消息
  消息消费者按照消息到达消息服务器的顺序进行消费

• 消息过滤
  消费者可以对同一主题下按规则过滤
  1. 消息在broker端过滤。broker只将消费者过滤的消息发送给消费者。（tag）
  2. 消息在消息端过滤。缺点是，很多无用的消息会从broker端传输到消费端。

• 消息存储
  核心。对消息存储一版有两个维度的考量
  1. 消息堆积能力
  2. 消息存储性能

• 消息高可用
  通常影响消息可靠性的有以下几种情况

  1. broker正常关机
  2. broker异常crash
  3. os crash
  4. 机器断电，但能立即恢复供电
  5. 机器无法开机（cpu、主板、内存等关键设备损坏）
  6. 磁盘损坏

  1-4：在同步刷盘机制下可以保证消息不丢失，在异步刷盘模式下，会丢失少量。
  5-6：属于单点故障，一旦发生，该节点上的消息全部丢失。如果开启了异步复制功能，大部分不丢失，只丢失少量。在双写机制下，可以保证消息不丢失。

• 消息到达（消息消费）低延迟

• 确保消息必须被消费一次
  通过消息消费确认ack机制来保证消息至少被消费一次。但由于ack有可能丢，所以会存在重复消费的情况，这里就需要消费者做幂等了。

• 回溯消息
  指消费者已经消费成功的消息，由于业务要求需要重新消费消息。可以向前或向后。

• 消息堆积
  消息中间件的主要功能是异步解耦。必须具备对前端的数据洪峰，提高后端系统的可用性，必然要求消息中间件具备一定的消息堆积能力。消息堆积能力依赖消息存储。

• 定时消息
  指消息发送到broker后，不能被消费者立即消费，要到特定的时间点才能消费。
  如果要支持任意精度的定时消息消费，必须在消息服务端对消息进行排序，势必会带来很大的性能损耗，故rocketMq不支持任意进度的定时消息，而只支持特定延迟级别。

• 消息重试机制
  消费机场，消息重新投递。

流程

启动时：

• nameServer 与 broker 建立长连接。把队列路由信息维护到nameServer中。
• nameServer 与 producer 简历长连接。producer获取自己要的topic下的队列路由信息。
• nameServer 与 consumer 简历长连接。根据group和topic，consumer找到自己对应的queue。

发送消息的过程：

• producer 发送消息给所有broker。broker存到commitLog buffer中。
  这里有个策略，是同步刷脏页还是异步刷脏页。如果保证消息不丢失，就使用同步刷脏页策略，消息落到commitlog后返回producer消息发送成功。如果消息发送异常，根据重试次数重试，直到成功。这里保证了发送端的发送一定成功。

• 消息存到了commitLog，会把消息分发到consumerQueue和index索引文件中。
  分发到哪个队列，也是有策略的：轮训、随机、key hash。因为是落了磁盘，所以消息存储过程中，消息不会丢失。

• consumer从对应的queue中根据offset拉取消息，消费成功后，返回ack。标识消费成功。如果消费失败，不返回ack，则broker端的offset不会变化，等consumer的下一次拉取。

顺序消息

两种方式：

1. 队列大小，只开1个，那个消息只在一个队列中，肯定是顺序的。
2. producer在调用send的时候，使用key hash来找queue，把key设置成一个，则会被分发到同一个queue中，在同一个queue中，消息也是顺序的。