RocketMQ常见生产问题分析

一.消息丢失

1.1分析消息丢失可能出现的场景有哪些？

1. 生产者将消息发送到mq
2. mq的master收到消息将消息同步到slave
3. 消费者从mq获取消息

以上三种场景是消息正常生产到消费或称中需要网络传输的三个地方。而跨网络就会存在消息丢失。

1.2指针消息丢失场景的消息零丢失方案

1.针对于生产者发送消息丢失的情况，我们可以使用RocketMQ的事务消息来保证零丢失。
事务消息流程图如下：

事务消息可以保证生产者在执行本地操作时，消息发送成功才会执行操作。
2.针对主从同步消息丢失可以配置同步刷盘+Dledger主从架构保证MQ主从同步时不会丢消息

1. 配置同步刷盘方式
   flushDiskType配置成同步刷盘可以保证消息不丢失
2. Dledger的文件同步
   
   Dledger集群类似与zookeeper的集群选举和nacos的cp架构下集群选取，都是采用的两阶段提交+半数以上投票方式保证数据一致性。

Leader Broker上的Dledger收到一条数据后，会标记为uncommitted状态，然后他通过自己的DledgerServer组件把这个uncommitted数据发给Follower Broker的DledgerServer组件。
接着Follower Broker的DledgerServer收到uncommitted消息之后，必须返回一个ack给Leader Broker的Dledger。然后如果Leader Broker收到超过半数的Follower Broker返回的ack之后，就会把消息标记为committed状态。
再接下来， Leader Broker上的DledgerServer就会发送committed消息给Follower Broker上的DledgerServer，让他们把消息也标记为committed状态。这样，就基于Raft协议完成了两阶段的数据同步

两阶段提交，主要是在第一个阶段先写文件，将消息持久化，但是未加载到内存，所以对外不可见。二阶段提交时将磁盘文件加载到内存。同时通过半数以上写完成在提交，保证部分节点挂掉之后数据不会丢失。
3.针对消费者从mq获取消息丢失：费者端不使用异步消费机制来保证
消费者端采用同步消费机制，先处理本地事务，然后再给MQ一个ACK响应，这时MQ就会修改Offset，将消息标记为已消费，从而不再往其他消费者推送消息，而如果处理本地事务过程中超时会有重新推送机制，这样确保消费者一定能消费消息。
4.NameServer挂了之后如何保证消息不丢失？
NameServer是RocketMQ特有的，主要是用来提供broker的路由，一般也是集群部署，只要有一台正常运行就可以正常使用。但是极端情况下，如果集群中所有的NameServer全都挂了呢？
如果所有NameServer全部挂了，那么mq就会处于不可用状态，因为服务中需要考虑降级方案。比如多次尝试发送RocketMQ不成功，那就只能另外找给地方(Redis、文件或者内存等)把订单消息缓存下来，然后起一个线程定时的扫描这些失败的订单消息，尝试往RocketMQ发送。这样等RocketMQ的服务恢复过来后，就能第一时间把这些消息重新发送出去。
5.总结：

• 生产者使用事务消息机制。
• Broker配置同步刷盘+Dledger主从架构
• 消费者不要使用异步消费。
• 整个MQ挂了之后准备降级方案

二.RocketMQ如何保证消息顺序

2.1保证消息顺序性有两种方式：

• 全局一致性
• 局部一致性

2.2怎么理解这两个概念呢？

全局一致性：不同的消息生产者发送的一组消息严格按照先后顺序排序
局部一致性：同一个生产者发送的一组消息按先后顺序排序，但是不同生产者的消息可以是无序的。

2.3怎么保证有序性？

• 而对于局部有序的要求，只需要将有序的一组消息都存入同一个MessageQueue里，这样MessageQueue的FIFO设计天生就可以保证这一组消息的有序。RocketMQ中，可以在发送者发送消息时指定一个MessageSelector对象，让这个对象来决定消息发入哪一个MessageQueue。这样就可以保证一组有序的消息能够发到同一个MessageQueue里。
• 全局消息有序，就是将Topic配置成只有一个MessageQueue队列(默认是4个)。这样天生就能保证消息全局有序了。而这种方式对整个Topic的消息吞吐影响是非常大的，如果这样用，基本上就没有用MQ的必要了

三.RocketMQ如何快速处理积压消息

3.1如何确定有大量消息积压

正常情况下，使用MQ都会要尽量保证他的消息生产速度和消费速度整体上是平衡的，但是如果部分消费者系统出现故障，就会造成大量的消息积累。

对于RocketMQ来说，有个最简单的方式来确定消息是否有积压。那就是使用web控制台，就能直接看到消息的积压情况。

3.2如何处理大量积压的消息

如果Topic下的MessageQueue配置得是足够多的，那每个Consumer实际上会分配多个MessageQueue来进行消费。这个时候，就可以简单的通过增加Consumer的服务节点数量来加快消息的消费，等积压消息消费完了，再恢复成正常情况。最极限的情况是把Consumer的节点个数设置成跟MessageQueue的个数相同。但是如果此时再继续增加Consumer的服务节点就没有用了。

四.RocketMQ的消息轨迹

4.1 RocketMQ消息轨迹数据的关键属性

Producer端	Consumer端	Broker端
生产实例信息	消费实例信息	消息的Topic
发送消息时间	投递时间,投递轮次	消息存储位置
消息是否发送成功	消息是否消费成功	消息的Key值
发送耗时	消费耗时	消息的Tag值

4.2 消息轨迹配置

需要在broker.conf中打开一个关键配置：

traceTopicEnable=true

4.3 消息轨迹数据存储

默认情况下，消息轨迹数据是存于一个系统级别的Topic ,RMQ_SYS_TRACE_TOPIC。这个Topic在Broker节点启动时，会自动创建出来。