RocketMQ 常见问题总结

 

RocketMQ 常见问题总结

 

 

1、如何保证RocketMQ不丢失消息？

1、生产者发送消息到MQ:

1. 使用同步发送方式。

2、Brocker收到消息消息并不丢失：

1. Brocker收到消息写入Pagecache后，同步刷盘。
2. 搭建Dledger集群。

3、消费者消费消息不丢失：

同步处理消息，业务逻辑执行完再提交offset。

 

2、如何保证消息的顺序性？

1. Producer将⼀组有序的消息写⼊到同⼀个MessageQueue中。
2. Consumer每次集中从⼀个MessageQueue中拿取消息。

在Producer端，RocketMQ和Kafka都提供了分区计算机制，可以让应⽤程序⾃⼰决定消息写⼊到哪⼀个分 区。所以这⼀块，是由业务⾃⼰决定的。只要通过定制数据分⽚算法，把⼀组局部有序的消息发到同⼀个对列 当中，就可以通过对列的FIFO特性，保证消息的处理顺序。

在Consumer端每次只能从一个messageQueue中拿消息，并且拿消息的时候会加锁。

 

3、如何保证消息消费的冥等性？

要保证1条消息只被消费1次，最好的做法是通过唯一的业务属性+状态来判断。

 

4、如何处理消息积压？

1、消息积压带来的问题

 对RocketMQ和Kafka来说，他们的消息积压能⼒本来就是很强的，因此，短时间的消息积压，是没有太多问题 的。但是需要注意，如果消息积压问题⼀直得不到解决，RocketMQ和Kafka在⽇志⽂件过期后，就会直接删除 过期的⽇志⽂件。⽽这些⽇志⽂件上未消费的消息，就会直接丢失。

2、怎么解决?

产⽣消息积压的根本原因还是Consumer处理消息的效率太低，所以最核⼼的⽬标还是要提升Consumer消费 消息的效率。如果不能从业务上提升Consumer消费消息的性能，那么最直接的办法就是针对处理消息⽐较慢 的消费者组，增加更多的Consumer实例。但是这⾥需要注意⼀下，增加Consumer实例是不是会有上限。

对于RocketMQ，因为同⼀个消费者组下的多个Cosumer需要和对应Topic下的MessageQueue建⽴对应关 系，⽽⼀个MessageQueue最多只能被⼀个Consumer消费，因此，增加的Consumer实例最多也只能和Topic 下的MessageQueue个数相同。如果此时再继续增加Consumer的实例，那么就会有些Consumer实例是没有 MessageQueue去消费的，因此也就没有⽤了。

这时，如果Topic下的MessageQueue配置本来就不够多的话，那就⽆法⼀直增加Consumer节点个数了。这时 怎么处理呢？如果要快速处理积压的消息，可以创建⼀个新的Topic，配置⾜够多的MessageQueue。然后把 Consumer实例的Topic转向新的Topic，并紧急上线⼀组新的消费者，只负责消费旧Topic中的消息，并转存到 新的Topic中。这个速度明显会⽐普通Consumer处理业务逻辑要快很多。然后在新的Topic上，就可以通过添 加消费者个数来提⾼消费速度了。之后再根据情况考虑是否要恢复成正常情况。