赞
踩
记得有次公司搞促销活动,流量增加,但是系统一直很平稳(我们开发的系统真牛),大家很开心的去聚餐,谈笑风声,气氛融洽,突然电话响起…
运维:小李,你们系统使用的rabbitmq的消息大量堆积,导致服务器cpu飙升,赶紧回来看看,服务器要顶不住了
小李:好的
我们使用rabbitmq主要是为了系统解耦、异步提高系统的性能
前端售卖系统,生成订单后,推送订单消息到rabbitmq,订单履约系统作为消费者,消费订单消息落库,做后续操作
第一我们想到的原因,流量激增,生成的订单速度远远大于消费者消费消息的速度,目前我们只部署了三个节点,那我们是否增加消费者,就可以解决这个问题,让消费者消费消息的速度远远大于生成者生成消息的速度,那消息就不存在堆积的问题,自然服务器压力也就下来了
通知运维,再部署三个点,也是就增加三个消费者,由原来的三个消费者变为6个消费者,信心满满的部署完成后,等待一段时间,不出意外还是出了意外,消息还是在持续堆积,没有任何改善,我心里那个急啊,为什么增加了消费者?一点改善没有呢
持续分析,是不是消费者的逻辑有问题,处理速度还是慢?在消费逻辑分析中,发现在处理订单消息的逻辑里,调用了库存系统的一个接口,有可能是这个接口响应慢,导致消费的速度慢,跟不上生产消息的速度。
查看库存系统的运行情况,发现系统压力非常大,接口请求存在大量超时的情况,系统也在崩溃的边缘,因为我们上面的解决方案,增加了三个节点,间接的增大了并发。告知负责库存系统的同学,进行处理排查解决,但一时解决不了,如果持续这样,整体链路有可能全部崩掉,这怎么办呢?
消费者逻辑优化,屏蔽掉调用库存的接口,直接处理消息,但这种我们的逻辑是不完成,虽然能减少服务器的压力,后续处理起来也非常的麻烦,这种方式不可取
为了减少消息的堆积,减轻服务器的压力,我们是否可以把mq里面的消息拿出来,先存储,等服务恢复后,再把存储的消息推送到mq,再处理呢?
这方案上线后,过了一段时间观察,消息不再堆积,服务器的负载也下来了,我内心也不再慌了,那存储的那些消息,还处理吗?当然处理,怎么处理呢?
至此,问题就完美的解决了,悬着的心也放下了
整个链路服务一直都是很稳定的,因为流量的激增,库存服务的服务能力跟不上,导致整个链路出了问题,如果平台要搞促销这种活动,我们还是要提前评估下系统的性能,对整个链路做一次压测,找出瓶颈,该优化的要优化,资源不足的加资源
问题虽然解决了,但我很好奇,消息堆积为什么会导致cpu飙升呢?
RabbitMQ 是一种消息中间件,用于在应用程序之间传递消息。当消息堆积过多时,可能会导致 CPU 飙升的原因有以下几点:
需要根据具体情况综合考虑以上因素,并结合实际情况进行调试和优化,以解决消息堆积导致 CPU 飙升的问题,不能照葫芦画瓢,像我第一次直接增加消费者,差点把这个链路都干挂了
写作不易,刚好你看到,刚好对你有帮助,麻烦点点赞,有问题的留言讨论。
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。