在高并发的场景下，由于消息产生速度超过消费速度，可能会导致消息积压的问题。本文将介绍 RocketMQ 消息积压的原因和如何处理积压问题。
什么是消息积压
消息积压是使用 MQ 消息队列系统中，最常见的一种性能问题。如下图所示，当生产端的生产效率大于消费端的消费效率就会造成消息处理不完的情况，也就叫 “消息积压”。
消息积压原因
消息积压的原因可以归结为以下几点：
- 消费者处理速度慢：当消息消费者的处理能力跟不上消息产生的速度时，消息将积压在消息队列中。
- 消息消费失败：当消息消费者由于某种原因无法正确消费消息时，消息会一直留在消息队列中，导致积压。
- 配置不合理：如果消息队列的容量设置过小或者消费者的线程数设置过少，都可能导致消息积压。
处理消息积压的方法
当发生了消息积压，这时就得想办法赶紧把积压的消息消费完，就得考虑提高消费能力，一般有两种办法：
消费者扩容
Consume 实例数量小于 MessageQueue 的数量时，增加 Consume 实例可以对消费者进行扩容，来提高消费能力。比如一个 Topic 有 4 个 MessageQueue，2 个消费者进行消费，如果增加一个消费者，明细可以加快拉取消息的频率。
消息迁移Queue扩容
Consume 实例数量大于等于 MessageQueue 的数量时，这种情况再扩容 Consume 实例就没什么用，就得考虑扩容 MessageQueue。
可以新建一个临时的 Topic，临时的 Topic 多设置一些 MessageQueue，然后先用一些消费者把消费的数据丢到临时的 Topic，因为不用业务处理，只是转发一下消息，还是很快的。接下来用扩容的消费者去消费新的 Topic 里的数据，消费完了之后，恢复原状。比如一个 Topic 有 4 个 MessageQueue，并且有 4 个消费者进行消费。
通过前期设置提高消费能力
虽然通过扩容可以在一定程度上解决消息积压问题，但在一些特殊情况下还是会出现消息积压的问题。
消费者消息拉取的速度也取决于本地消息的消费速度，如果本地消息消费的慢，就会延迟一段时间后再去拉取。又是在什么情况下消费者会延迟一段时间后后再去拉取呢?
增加消息队列的容量
如果消息队列的容量设置过小，也有可能会导致消息积压。
可以通过增加消息队列的容量来缓解积压问题。但需要注意，过大的消息队列容量可能会增加消息处理的延迟。
消费者拉取的消息存在 ProcessQueue，消费者是有流量控制的，如果出现下面三种情况，就不会主动去拉取：
- ProcessQueue 保存的消息数量超过阈值（默认 1000）；
- ProcessQueue 保存的消息大小超过阈值（默认 100M）；
- 对于非顺序消费的场景，ProcessQueue 中保存的最后一条和第一条消息偏移量之差超过阈值（默认 2000）。
优化消息消费的逻辑
检查消息消费逻辑是否存在性能瓶颈或者不必要的复杂计算。优化消息消费的逻辑可以提高消费速度，减少消息积压。
对于顺序消费的场景，ProcessQueue 加锁失败，也会延迟拉取，这个延迟时间是 3s。
设置消息消费失败的处理机制
当消息消费失败时，可以根据业务需求选择合适的处理方式。可以将失败的消息记录下来，后续再次消费；或者将失败的消息发送到死信队列进行处理。
监控和报警机制
建立监控和报警机制，及时发现消息积压的情况并采取相应的措施。可以通过监控指标、日志或者专业的监控工具来实现。
消息批量处理
消费者每次一条一条消费会很慢，如果再有事务的情况下会更慢。此时可能通过批量的方式获取数据，再对数据批量操作，
RocketMQ消息积压是在高并发场景下常见的问题，需要合理的处理策略来保证消息系统的稳定性和性能。
