• 【rabbitmq的消息堆积问题】



    RabbitMQ一直以来都有一个缺点,就是对于消息堆积问题的处理不好。当RabbitMQ中有大量消息堆积时,整体性能会严重下降。而目前新推出的Quorum队列以及Stream队列,目的就在于解决这个核心问题。但是这两种队列的稳定性和周边生态都还不够完善,因此,在使用RabbitMQ时,还是要非常注意消息堆积的问题。尽量让消息的消费速度和生产速度保持一致。

    而如果确实出现了消息堆积比较严重的场景,就需要从数据流转的各个环节综合考虑,设计适合的解决方案。

    消息生产者端:

    对于生产者端,最明显的方式自然是降低消息生产的速度。但是,生产者端产生消息的速度通常是跟业务息息相关的,一般情况下不太好直接优化。但是可以选择尽量多采用批量消息的方式,降低IO频率。

    RabbitMQ服务端

    RabbitMQ本身其实也在着力于提高服务端的消息堆积能力。对于消息堆积严重的队列,可以预先添加懒加载机制,或者创建Sharding分片队列,这些措施都有助于优化服务端的消息堆积能力。另外,尝试使用Stream队列,也能很好的提高服务端的消息堆积能力。

    消息消费者端:

    要提升消费速度最直接的方式,就是增加消费者数量了。尤其当消费端的服务出现问题,已经有大量消息堆积时。这时,可以尽量多的申请机器,部署消费端应用,争取在最短的时间内消费掉积压的消息。但是这种方式需要注意对其他组件的性能压力。

    对于单个消费者端,可以通过配置提升消费者端的吞吐量。

    # 单次推送消息数量 
    spring.rabbitmq.listener.simple.prefetch=1 
    # 消费者的消费线程数量 
    spring.rabbitmq.listener.simple.concurrency=5
    

    灵活配置这几个参数,能够在一定程度上调整每个消费者实例的吞吐量,减少消息堆积数量。

    当确实遇到紧急状况,来不及调整消费者端时,可以紧急上线一个消费者组,专门用来将消息快速转录。保存到数据库或者Redis,然后再慢慢进行处理。

  • 相关阅读:
    3d可视化设备产品场景展示更加直观形象
    TypeScript环境配置详解
    2023亚太杯数学建模思路 - 案例:异常检测
    C++ ++ 和 -- 运算符重载
    STM32F103 CubeMX 使用USB生成鼠标设备
    Servlet
    Spark 【Spark SQL(一)DataFrame的创建、保存与基本操作】
    MyBatis-Plus用法 真的很强大啊
    Typescript 严格模式有多严格?
    【斗破年番】彩鳞遭捆绑,萧炎单手抱彩鳞,有谁注意到小医仙流泪
  • 原文地址:https://blog.csdn.net/m0_50116974/article/details/139757491