如何解决MQTT消息积压
什么是消息积压？
大量消息被堆积在broker端，没有被消费。
为什么会消息积压？
宏观角度主要原因是：producer端生产速度 > consumer端消费速度。
导致producer端生产速度 > consumer端消费速度的情况有多种：
- 设计的时候就没有考虑消费速度要大于生产速度，这种情况最不应该。
- 某一时刻消息积压上涨
- 比如说抢购，导致生产端一下子并发量飙升，考虑水平扩容或者服务降级。
- 消费端有很多消费失败，导致消费性能下降
消息积压了该怎么办？
这里首先得有一个认识：消息队列本身的处理能力要远大于业务系统的处理能力。因此主要考虑业务逻辑中的性能优化。
紧急处理
问题的根在于consumer端消费速度慢导致的，最直接的方法就是水平扩容，增加消费端的并发数，来提升总体的消费性能。
需要注意的是：在Kafka或RocketMQ中 在扩容 Consumer 的实例数量的同时，必须同步扩容主题中的分区（也叫队列）数量，确保 Consumer 的实例数和分区数量是相等的。 否则水平扩容之后也是没有效果的。
紧急处理之后进行Consumer端优化
只要针对consumer端的业务逻辑进行优化。
我们的业务代码怎么和消息队列配合，达到一个最佳的性能？
producer端
发送端性能上不去，你需要优先检查一下，是不是发消息之前的业务逻辑耗时太多导致的。
提升发送性能的方法：设置合适的并发和批量大小。
Producer 发消息给 Broker，Broker 收到消息后返回确认响应，这是一次完整的交互。
提升发送性能就是为了在单位时间内增加交互的消息量。
并发方式：对于响应时间短的友好
批量方式：对吞吐量大的友好
耗时分析
- 1.准备发送：发送端准备数据、序列化消息、构造请求等逻辑的时间
- 2.消息从producer端网络传输到broker端
- 3.broker端处理消息
- 4.消息响应从broker端网络传输到producer端
broker端
刚才已经提过了，消费队列性能远大于业务系统的处理能力，所以broker端的性能不用考虑，要考虑也可以通过水平扩容broker达到很好的效果。
consumer端
如上，只要针对consumer端的业务逻辑进行优化，或者进行水平扩容，且在broker增加分区。
总结
链接：https://juejin.cn/post/7006553089054507045
