背景

记得有次公司搞促销活动，流量增加，但是系统一直很平稳（我们开发的系统真牛），大家很开心的去聚餐，谈笑风声，气氛融洽，突然电话响起....

运维：小李，你们系统使用的rabbitmq的消息大量堆积，导致服务器cpu飙升，赶紧回来看看，服务器要顶不住了

小李：好的

系统架构描述

我们使用rabbitmq主要是为了系统解耦、异步提高系统的性能

前端售卖系统，生成订单后，推送订单消息到rabbitmq，订单履约系统作为消费者，消费订单消息落库，做后续操作

第一我们想到的原因，流量激增，生成的订单速度远远大于消费者消费消息的速度，目前我们只部署了三个节点，那我们是否增加消费者，就可以解决这个问题，让消费者消费消息的速度远远大于生成者生成消息的速度，那消息就不存在堆积的问题，自然服务器压力也就下来了

通知运维，再部署三个点，也是就增加三个消费者，由原来的三个消费者变为6个消费者，信心满满的部署完成后，等待一段时间，不出意外还是出了意外，消息还是在持续堆积，没有任何改善，我心里那个急啊，为什么增加了消费者？一点改善没有呢

持续分析，是不是消费者的逻辑有问题，处理速度还是慢？在消费逻辑分析中，发现在处理订单消息的逻辑里，调用了库存系统的一个接口，有可能是这个接口响应慢，导致消费的速度慢，跟不上生产消息的速度。

查看库存系统的运行情况，发现系统压力非常大，接口请求存在大量超时的情况，系统也在崩溃的边缘，因为我们上面的解决方案，增加了三个节点，间接的增大了并发。告知负责库存系统的同学，进行处理排查解决，但一时解决不了，如果持续这样，整体链路有可能全部崩掉，这怎么办呢？

消费者逻辑优化，屏蔽掉调用库存的接口，直接处理消息，但这种我们的逻辑是不完成，虽然能减少服务器的压力，后续处理起来也非常的麻烦，这种方式不可取

为了减少消息的堆积，减轻服务器的压力，我们是否可以把mq里面的消息拿出来，先存储，等服务恢复后，再把存储的消息推送到mq，再处理呢？

这方案上线后，过了一段时间观察，消息不再堆积，服务器的负载也下来了，我内心也不再慌了，那存储的那些消息，还处理吗？当然处理，怎么处理呢？

至此，问题就完美的解决了，悬着的心也放下了

整个链路服务一直都是很稳定的，因为流量的激增，库存服务的服务能力跟不上，导致整个链路出了问题，如果平台要搞促销这种活动，我们还是要提前评估下系统的性能，对整个链路做一次压测，找出瓶颈，该优化的要优化，资源不足的加资源

问题虽然解决了，但我很好奇，消息堆积为什么会导致cpu飙升呢？

RabbitMQ 是一种消息中间件，用于在应用程序之间传递消息。当消息堆积过多时，可能会导致 CPU 飙升的原因有以下几点：

消息过多导致消息队列堆积：当消息的产生速度大于消费者的处理速度时，消息会积累在消息队列中。如果消息堆积过多，RabbitMQ 需要不断地进行消息的存储、检索和传递操作，这会导致 CPU 使用率升高。
消费者无法及时处理消息：消费者处理消息的速度不足以追赶消息的产生速度，导致消息不断积累在队列中。这可能是由于消费者出现瓶颈，无法处理足够多的消息，或者消费者的处理逻辑复杂，导致消费过程耗费过多的 CPU 资源。
消息重试导致额外的 CPU 开销：当消息处理失败时，消费者可能会进行消息的重试操作，尝试再次处理消息。如果重试频率较高，会导致消息在队列中频繁流转、被重复消费，这会增加额外的 CPU 开销。
过多的连接以及网络IO：当消息堆积过多时，可能会引发大量的连接请求和网络数据传输。这会增加网络 IO 的负载，并占用 CPU 资源。

增加消费者：通过增加消费者的数量来提升消息的处理能力。增加消费者可以分担消息消费的负载，缓解消息队列的堆积问题。
优化消费者的处理逻辑：检查消费者的代码是否存在性能瓶颈或是复杂的处理逻辑。可以通过优化算法、减少消费过程的计算量或是提高代码的效率来减少消费者的 CPU 开销。
避免频繁的消息重试：当消息无法处理时，可以根据错误类型进行不同的处理方式，如将无法处理的消息转移到死信队列中或进行日志记录。避免频繁地对同一消息进行重试，以减少额外的 CPU 开销。
调整 RabbitMQ 配置：可以调整 RabbitMQ 的参数来适应系统的需求，如增加内存、调整消息堆积的阈值和策略，调整网络连接等配置。
扩展硬件资源：如果以上措施无法解决问题，可能需要考虑增加 RabbitMQ 的集群节点或者扩容服务器的硬件资源，以提升整个系统的处理能力。

需要根据具体情况综合考虑以上因素，并结合实际情况进行调试和优化，以解决消息堆积导致 CPU 飙升的问题，不能照葫芦画瓢，像我第一次直接增加消费者，差点把这个链路都干挂了

写作不易，刚好你看到，刚好对你有帮助，麻烦点点赞，有问题的留言讨论。