背景
记得有次公司搞促销活动,流量增加,但是系统一直很平稳(我们开发的系统真牛),大家很开心的去聚餐,谈笑风声,气氛融洽,突然电话响起....
运维:小李,你们系统使用的rabbitmq的消息大量堆积,导致服务器cpu飙升,赶紧回来看看,服务器要顶不住了小李:好的
系统架构描述
我们使用rabbitmq主要是为了系统解耦、异步提高系统的性能
前端售卖系统,生成订单后,推送订单消息到rabbitmq,订单履约系统作为消费者,消费订单消息落库,做后续操作
排查以及解决
方案一 增加消费者
第一我们想到的原因,流量激增,生成的订单速度远远大于消费者消费消息的速度,目前我们只部署了三个节点,那我们是否增加消费者,就可以解决这个问题,让消费者消费消息的速度远远大于生成者生成消息的速度,那消息就不存在堆积的问题,自然服务器压力也就下来了
通知运维,再部署三个点,也是就增加三个消费者,由原来的三个消费者变为6个消费者,信心满满的部署完成后,等待一段时间,不出意外还是出了意外,消息还是在持续堆积,没有任何改善,我心里那个急啊,为什么增加了消费者?一点改善没有呢
方案二 优化消费者的处理逻辑
持续分析,是不是消费者的逻辑有问题,处理速度还是慢?在消费逻辑分析中,发现在处理订单消息的逻辑里,调用了库存系统的一个接口,有可能是这个接口响应慢,导致消费的速度慢,跟不上生产消息的速度。
查看库存系统的运行情况,发现系统压力非常大,接口请求存在大量超时的情况,系统也在崩溃的边缘,因为我们上面的解决方案,增加了三个节点,间接的增大了并发。告知负责库存系统的同学,进行处理排查解决,但一时解决不了,如果持续这样,整体链路有可能全部崩掉,这怎么办呢?
消费者逻辑优化,屏蔽掉调用库存的接口,直接处理消息,但这种我们的逻辑是不完成,虽然能减少服务器的压力,后续处理起来也非常的麻烦,这种方式不可取
方案三 清空堆积的消息
为了减少消息的堆积,减轻服务器的压力,我们是否可以把mq里面的消息拿出来,先存储,等服务恢复后,再把存储的消息推送到mq,再处理呢?
通用的解决方案
需要根据具体情况综合考虑以上因素,并结合实际情况进行调试和优化,以解决消息堆积导致 CPU 飙升的问题,不能照葫芦画瓢,像我第一次直接增加消费者,差点把这个链路都干挂了
- 新建消费者,消费rabbitmq的消息,不做任何业务逻辑处理,直接快速消费消息,把消息存在一张表里,这样就没消息的堆积,服务器压力自然就下来了。
- 这方案上线后,过了一段时间观察,消息不再堆积,服务器的负载也下来了,我内心也不再慌了,那存储的那些消息,还处理吗?当然处理,怎么处理呢?
- 后续等库存服务问题解决后,停掉新的消费者,新建一个生产者,再把表里的订单数据推送到rabbitmq,进行业务逻辑的处理 ### 问题产生的原因分析整个链路服务一直都是很稳定的,因为流量的激增,库存服务的服务能力跟不上,导致整个链路出了问题,如果平台要搞促销这种活动,我们还是要提前评估下系统的性能,对整个链路做一次压测,找出瓶颈,该优化的要优化,资源不足的加资源### 消息堆积为什么会导致cpu飙升呢?问题虽然解决了,但我很好奇,消息堆积为什么会导致cpu飙升呢?RabbitMQ 是一种消息中间件,用于在应用程序之间传递消息。当消息堆积过多时,可能会导致 CPU 飙升的原因有以下几点:
- 消息过多导致消息队列堆积:当消息的产生速度大于消费者的处理速度时,消息会积累在消息队列中。如果消息堆积过多,RabbitMQ 需要不断地进行消息的存储、检索和传递操作,这会导致 CPU 使用率升高。
- 消费者无法及时处理消息:消费者处理消息的速度不足以追赶消息的产生速度,导致消息不断积累在队列中。这可能是由于消费者出现瓶颈,无法处理足够多的消息,或者消费者的处理逻辑复杂,导致消费过程耗费过多的 CPU 资源。
- 消息重试导致额外的 CPU 开销:当消息处理失败时,消费者可能会进行消息的重试操作,尝试再次处理消息。如果重试频率较高,会导致消息在队列中频繁流转、被重复消费,这会增加额外的 CPU 开销。
- 过多的连接以及网络IO:当消息堆积过多时,可能会引发大量的连接请求和网络数据传输。这会增加网络 IO 的负载,并占用 CPU 资源。
- 增加消费者:通过增加消费者的数量来提升消息的处理能力。增加消费者可以分担消息消费的负载,缓解消息队列的堆积问题。
- 优化消费者的处理逻辑:检查消费者的代码是否存在性能瓶颈或是复杂的处理逻辑。可以通过优化算法、减少消费过程的计算量或是提高代码的效率来减少消费者的 CPU 开销。
- 避免频繁的消息重试:当消息无法处理时,可以根据错误类型进行不同的处理方式,如将无法处理的消息转移到死信队列中或进行日志记录。避免频繁地对同一消息进行重试,以减少额外的 CPU 开销。
- 调整 RabbitMQ 配置:可以调整 RabbitMQ 的参数来适应系统的需求,如增加内存、调整消息堆积的阈值和策略,调整网络连接等配置。
- 扩展硬件资源:如果以上措施无法解决问题,可能需要考虑增加 RabbitMQ 的集群节点或者扩容服务器的硬件资源,以提升整个系统的处理能力。
版权归原作者 海绵宝宝程序猿 所有, 如有侵权,请联系我们删除。