除了消息的丢失，另一个消息队列常见的问题就是消息积压了。我们都知道，消息之所以会挤压是由于消费端的性能除了问题，导致消息的消费速度较低来不及处理上游发送的消息。这一章我们就来看一下，如果优化代码的性能，避免出现消息积压。
在使用消息队列的系统中，对于性能的优化，主要体现在生产者和消费者这一收一发两部分的业务逻辑中。对于消息队列本身的性能，不需要太多的关注。一般来说消息队列本身的处理能力要比业务逻辑处理能力高的多。主流消息队列单个节点，消息收发的性能能达到几万至几十万条，还可以通过水平扩展Broker的实例成倍的提升处理能力。而一般的业务系统需要处理的业务逻辑远比消息队列复杂的多，单个节点每秒钟能处理几百到几千次请求，已经算非常好的性能了。所以，对于消息队列的性能优化，我们关注的应该是消息收发的两端，我们的业务代码怎么和消息队列配合，达到要给最佳的性能。
一. 发送端性能优化
发送端业务代码的处理性能和消息队列的关系不大，因为一般发送端都会先执行自己的代码，然后才会发送消息。如果说，你的代码发送消息的性能上不去，就需要先检查优化一下，是不是发送消息之前的业务逻辑是不是太耗时了？
对于发送消息的业务逻辑，只需要注意设置合理的并发和批量大小，就能达到很好的发送性能。
我们之前讲过发送消息的过程，Producer发消息给Broker，Broker收到消息后返回确认响应，这是一次完整的交互，它包含了下面这些操作的耗时：
-
发送端准备数据、序列化消息、构造请求等逻辑的时间，也就是发送端在发送网络请求之前的耗时
-
发送消息、返回响应用到的网络传输的耗时
-
Broker处理消息的耗时
假设一次交互的平均延时是1ms，那么在单线程下1s能发送1000条消息，这种情况下并不能发挥出消息队列的全部实例。无论是增加并发还是批量发送，都能提高发送性能。至于到底是选择并发还是批量发送取决于发送端的业务性质。简单来说，只要能满足你的性能要求，怎么实现方便就怎么实现。
比如说，如果处理的线上业务一般会采用并发发送消息。如果是一个离线分析系统，不注意时延，更注重整个系统的吞吐量，发送端的数据来源也都是来自于数据库，这种情况下我们一般使用批量发送来提升性能。
二. 消息端性能优化
使用消息队列的时候，大部分性能问题都出现在消费端，如果消息的速度跟不上发送的速度就会出现消息积压的情况。如果这种情况只是暂时的，那问题不大，只要消费端性能恢复之后，超过发送端的性能，那积压的消息是可以逐渐被消化掉的。要是消费速度一直比生产速度慢，时间长了，整个系统就会出现问题，要么消息队列的存储被填满无法提供服务，要么消息丢失，这都是很严重的事故。
消费端的性能除了可以优化代码以外，也可以通过水平扩容增加消费端的并发数来提升总体的消费性能。特别需要注意的一点是，在扩容Consumer的实例数量的同时，必须同步扩容主题中的分区（也叫队列）数量，确保Consumer的数量和分区数量相同，因为同一个分区同一时间只能有一个消费者。
三. 消息积压了如何处理？
还有一种消息积压的情况是，日常系统正常运行的时候没有积压或者只有少数积压很快就会被消费掉了，但是某一个时刻，突然就开始积压消息并且消息持续上涨。这种情况下需要你在短时间内找到消息积压的原因，并且快速的解决。
导致突然积压的原因是多样的，不同的系统、不同的情况有不同的原因，不能一概而论。但是，我们排查消息积压的原因，是由一些相对固定而且比较有效的方法的。
能导致积压的突然增加，最粗粒度的原因只有两种：要么消息发送变快了，要么消息消费变慢了。
大部分消息队列内部都由监控功能，只要通过监控数据，很容易确定是哪种原因。如果是单位时间发送的消息增多，比如说赶上活动，短时间可能不太可能优化消费端的代码来提升消费性能，唯一的方法是通过扩容消费端的实例来提升总体的消费能力。
如果短时间内没有办法扩容，没办法的办法是，将系统降级，通过关闭一些不重要的业务，减少发送方发送的数据量，最低限度让系统正常运转，服务一些重要业务。
还有一些不太常见的情况，你通过监控发现，无论是消息发送还是消息消费都没有什么变化，这时候需要检查一下消费端是不是有一些消息消费失败导致一条消息反复消费，这种情况也会拖慢整个系统的消费速度。
如果监控到消费变慢了，你需要检查你的消费实例，分析一下是什么原因导致的消费速度降低。优先检查一下日志是否由大量的消费错误，如果没有的话，可以通过打印堆栈信息，看一下你的消费线程是不是卡在什么地方不动了，比如触发了死锁或者卡在等待资源上。