消息队列技术解析(5)-消息大量积压怎么办？（下）

消息积压，如何处理

还有种消息积压，日常系统正常运转时，没有积压或只有少量积压很快就消费了，但某个时刻，突然开始积压消息且积压持续上涨。

这种情况下需要你在短时间内找到消息积压原因，迅速解决问题才不至于影响业务。

突然积压原因多种多样，不能一概而论。但排查消息积压原因，有相对固定且有效方法。

积压突然增加，最粗粒度的原因，只有两种

• 要么发送变快
• 要么是消费变慢

大部分消息队列都内置了监控的功能，只要通过监控数据，很容易确定是哪种原因。如果是单位时间发送消息增多，比如说是赶上抢购，短时间内不太可能优化消费端代码提升性能，唯一方法通过扩容消费端实例数提升总体消费能力。

如果短时间没足够服务器资源扩容，将系统降级，通过关闭一些不重要业务，减少发送方发送数据量，最低限度让系统还能正常运转，服务一些重要业务。

kafka不仅是扩容时候，只要是consumer和partition有一方的数量变化，都会触发reblance。

还有种不太常见的，通过监控发现，无论是发送消息速度还是消费消息速度和原来都没什么变化，这时需检查消费端，是不是消费失败导致的一条消息反复消费，也会拖慢整个系统消费速度。

如果监控到消费变慢，你需要检查消费实例，分析一下是什么原因导致消费变慢。优先检查一下日志是否有大量消费错误，如果没有错误，可通过打印堆栈信息，看消费线程是不是卡在什么地方不动，比如触发死锁或卡在等待某些资源。

如果消费者消费异常，即使多次消费也无法成功处理（如消息格式异常），导致一直无法成功ack此条消息，这种场景一般要怎么处理？

有的MQ提供了“死信队列”的功能，它会自动把这种反复消费都失败的消息丢到一个特殊的死信队列中，避免一条消息卡主队列情况。

总结

消息积压处理：

1、发送端优化，增加批量和线程并发两种方式处理

2、消费端优化，优化业务逻辑代码、水平扩容增加并发并同步扩容分区数量

查看消息积压的方法：

1、消息队列内置监控，查看发送端发送消息与消费端消费消息的速度变化

2、查看日志是否有大量的消费错误

3、打印堆栈信息，查看消费线程卡点信息

1.无法提升消费业务效率（仅受消费业务自身逻辑影响），但可以提高mq中堆积消息消费的整体吞吐量（批推比单推mq耗时较短）。

2.数据增量同步，监控信息采集。（非核心业务的稳定大数据流操作）。

3.批处理意味数据积累和大数据传输，这会让单次消费的最长时延变长。同时批量操作为了保证当前批量操作一致性，在个别失败的情况下会引发批量操作重试。

消费端是否可以通过同步消费提升消费性能呢？

消费端进行批量操作，感觉和上面的先将消息放在内存队列中，然后在并发消费消息，如果机器宕机，这些批量消息都会丢失，如果在数据库层面，批量操作在大事务，会导致锁的竞争，并且也会导致主备的不一致。如果是一些不重要的消息如对日志进行备份，就可以使用批量操作之类的提高消费性能，因为一些日志消息丢失也是可以接受的。