每一个mq都有的问题。
顺序消费问题
RocketMQ 在主题上是无序的、它只有在队列层面才是保证有序 的。
普通顺序（推荐）：消费者通过 同一个消费队列收到的消息是有顺序的 ，不同消息队列收到的消息则可能是无顺序的。普通顺序消息在 Broker 重启情况下不会保证消息顺序性 (短暂时间) 。
严格顺序（实现代价太大）： 消费者收到的 所有消息 均是有顺序的。严格顺序消息 即使在异常情况下也会保证消息的顺序性 。
我们使用普通顺序模式，比如订单的创建，支付，发货三个消息不被分配在topic的同一个队列，就无法保证有序？
们需要处理的仅仅是将同一语义下的消息放入同一个队列(比如这里是同一个订单)，那我们就可以使用 Hash取模法 来保证同一个订单在同一个队列中就行了。
重复消费
幂等：幂等 操作的特点是其任意多次执行所产生的影响均与一次执行的影响相同。
实现幂等即可（对同一个消息的处理结果，执行多少次都不变。）
你可以使用 写入 Redis 来保证，因为 Redis 的 key 和 value 就是天然支持幂等的。当然还有使用 数据库插入法 ，基于数据库的唯一键来保证重复数据不会被插入多条。
mq的分布式事务？
在 RocketMQ 中使用的是 事务消息加上事务反查机制 来解决分布式事务问题的。
如果没有从第5步开始的 事务反查机制 ，如果出现网路波动第4步没有发送成功，这样就会产生 MQ 不知道是不是需要给消费者消费的问题，他就像一个无头苍蝇一样。在 RocketMQ 中就是使用的上述的事务反查来解决的，而在 Kafka 中通常是直接抛出一个异常让用户来自行解决。
在消息队列中的分布式事务是——本地事务和存储消息到消息队列才是同一个事务。这样也就产生了事务的最终一致性，因为整个过程是异步的，每个系统只要保证它自己那一部分的事务就行了。
消息堆积问题
限流降级，减速生产者。检查是不是出现大量消费者消费错误，或者消费线程错误，
可以增加消费者，同时要增加topic中的队列，因为在 RocketMQ 中，一个队列只会被一个消费者消费。
回溯消费
回溯消费是指 Consumer 已经消费成功的消息，由于业务上需求需要重新消费，在RocketMQ中， Broker 在向Consumer 投递成功消息后，消息仍然需要保留 。RocketMQ 支持按照时间回溯消费，时间维度精确到毫秒。
