顾名思义，就是要保证需要按顺序消费的消息集发送到同一消息队列，同时消费消息成功后给予回执。

消息生产端发送消息的时候实现指定消息队列方法[把订单号取了做了一个取模运算再丢到 selector 中，selector 保证同一个模的都会投递到同一条  queue。

即：相同订单号的 --> 有相同的模 --> 有相同的 queue。

重复消息主要靠业务端实现。消费端处理消息的业务逻辑保持幂等性，保证每条消息都有唯一编号且保证消息处理成功与去重表的日志同时出现。

事务消息，要分别在发送端和订阅端配合处理。发送端：

• 第一阶段发送Prepared消息时，会拿到消息的地址

• 第二阶段执行本地事物

• 第三阶段通过第一阶段拿到的地址去访问消息，并修改消息的状态。定期扫描消息集群中的事物消息，处理Prepared消息向发送端确认并根据发送端策略处理消息

订阅端：业务在事务里实现消息处理，通过重试解决处理失败的消息问题，一直失败人工解决。

RocketMQ 的消息存储是由 consume queue 和 commit log 配合完成的。

consume queue 是消息的逻辑队列，相当于字典的目录，用来指定消息在物理文件 commit log 上的位置。

根据 topic 和 queueId 来组织文件，图中TopicA有两个队列0,1，那么TopicA和QueueId=0组成一个ConsumeQueue，TopicA和QueueId=1组成另一个ConsumeQueue。

ConsumeQueue 存储：CommitLog Offset是指这条消息在 Commit Log 文件中的实际偏移量，Size 存储中消息的大小。

Message Tag HashCode 存储消息的 Tag 的哈希值：主要用于订阅时消息过滤（订阅时如果指定了 Tag，会根据 HashCode 来快速查找到订阅的消息）。

按照消费端的 GroupName 来分组重试队列，如果消费端消费失败，消息将被发往重试队列中。

按照消费端的 GroupName 来分组死信队列，如果消费端消费失败，并重试指定次数后，仍然失败，则发往死信队列。

Commit Log：消息存放的物理文件，每台 broker 上的 commit log 被本机所有的 queue 共享，不做任何区分。