消息队列高手课
李玥
美团高级技术专家
52199 人已学习
新⼈⾸单¥59
登录后,你可以任选4讲全文学习
课程目录
已完结/共 42 讲
进阶篇 (21讲)
消息队列高手课
15
15
1.0x
00:00/00:00
登录|注册

07 | 消息积压了该如何处理?

检查消费实例,分析消费变慢的原因
检查消费失败导致的消息反复消费
降级系统以减少发送数据量
扩容消费端的实例数
发送变快或消费变慢
避免使用内存队列来解决消费慢的问题
注意同步扩容主题中的分区数量
通过水平扩容增加消费端的并发数
保证消费端的消费性能高于发送端的发送性能
根据业务性质选择批量发送或增加并发
设置合适的并发和批量大小
这种方法的局限性
适合使用这种方法的场景
处理方法
突然积压的原因
消费端性能优化
发送端性能优化
消费端是否可以通过批量消费的方式来提升消费性能
消息积压的处理
优化性能来避免消息积压
思考题
消息积压问题

该思维导图由 AI 生成,仅供参考

你好,我是李玥。这节课我们来聊一聊关于消息积压的问题。
据我了解,在使用消息队列遇到的问题中,消息积压这个问题,应该是最常遇到的问题了,并且,这个问题还不太好解决。
我们都知道,消息积压的直接原因,一定是系统中的某个部分出现了性能问题,来不及处理上游发送的消息,才会导致消息积压。
所以,我们先来分析下,在使用消息队列时,如何来优化代码的性能,避免出现消息积压。然后再来看看,如果你的线上系统出现了消息积压,该如何进行紧急处理,最大程度地避免消息积压对业务的影响。

优化性能来避免消息积压

在使用消息队列的系统中,对于性能的优化,主要体现在生产者和消费者这一收一发两部分的业务逻辑中。对于消息队列本身的性能,你作为使用者,不需要太关注。为什么这么说呢?
主要原因是,对于绝大多数使用消息队列的业务来说,消息队列本身的处理能力要远大于业务系统的处理能力。主流消息队列的单个节点,消息收发的性能可以达到每秒钟处理几万至几十万条消息的水平,还可以通过水平扩展 Broker 的实例数成倍地提升处理能力。
而一般的业务系统需要处理的业务逻辑远比消息队列要复杂,单个节点每秒钟可以处理几百到几千次请求,已经可以算是性能非常好的了。所以,对于消息队列的性能优化,我们更关注的是,在消息的收发两端,我们的业务代码怎么和消息队列配合,达到一个最佳的性能。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

消息积压是使用消息队列时常见的问题,而本文从优化性能和处理消息积压两方面进行了详细讲解。在优化性能方面,文章提到了发送端和消费端的性能优化策略,包括设置合适的并发和批量大小、增加并发、水平扩容等方法。另外,文章还强调了消费端的消费性能应高于发送端的发送性能,以确保系统健康运行。在处理消息积压方面,文章指出了突然积压的原因可能是发送变快或消费变慢,提供了相应的排查方法和解决方案。总的来说,本文通过技术角度深入探讨了消息积压问题,并提供了实用的解决方案,对于使用消息队列的开发人员具有一定的参考价值。 文章主要讨论了两个问题,一个是如何在消息队列的收发两端优化系统性能,提前预防消息积压。另一个问题是,当系统发生消息积压后,该如何处理。优化消息收发性能,预防消息积压的方法有两种,增加批量或者是增加并发。在消费端,可以通过批量消费的方式来提升消费性能,特别适合处理大量消息的场景。然而,需要注意的是,批量消费也存在一定的局限性,需要根据具体情况进行权衡和选择。当系统发生消息积压时,需要先解决积压,再分析原因,确保系统的可用性。快速解决积压的方法是通过水平扩容增加Consumer的实例数量。 总的来说,本文深入探讨了消息队列中的性能优化和消息积压处理方法,为开发人员提供了有益的技术参考。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《消息队列高手课》
新⼈⾸单¥59
立即购买
登录 后留言

全部留言(109)

  • 最新
  • 精选
  • 大白给小白讲故事
    1、要求消费端能够批量处理或者开启多线程进行单条处理 2、批量消费一旦某一条数据消费失败会导致整批数据重复消费 3、对实时性要求不能太高,批量消费需要Broker积累到一定消费数据才会发送到Consumer

    作者回复: 👍👍👍

    2019-08-06
    5
    90
  • iLeGeND
    老师好,我一直理解,消息积压不是一种正常的现象吗?来不及处理的消息先在消息队列中存着,缓解下游系统的压力,让上下游系统在时间上解偶,,听了今天的课,感觉理解的不太一样,希望老师解答一下

    作者回复: 消息积压是正常现象,积压越来越多就需要处理了。 就像一个水库,日常蓄水是正常的,但下游泄洪能力太差,导致水库水位一直不停的上涨,这个就不正常了。

    2019-08-06
    10
    62
  • linqw
    尝试回答下课后习题,老师有空帮忙看下哦 消费端进行批量操作,感觉和上面的先将消息放在内存队列中,然后在并发消费消息,如果机器宕机,这些批量消息都会丢失,如果在数据库层面,批量操作在大事务,会导致锁的竞争,并且也会导致主备的不一致。如果是一些不重要的消息如对日志进行备份,就可以使用批量操作之类的提高消费性能,因为一些日志消息丢失也是可以接受的。

    作者回复: 非常好!

    2019-08-06
    4
    26
  • Jxin
    1.无法提升消费业务效率(仅受消费业务自身逻辑影响),但可以提高mq中堆积消息消费的整体吞吐量(批推比单推mq耗时较短)。 2.数据增量同步,监控信息采集。(非核心业务的稳定大数据流操作)。 3.批处理意味数据积累和大数据传输,这会让单次消费的最长时延变长。同时批量操作为了保证当前批量操作一致性,在个别失败的情况下会引发批量操作重试。

    作者回复: 总结的非常好!

    2019-08-06
    23
  • SunshineBoy
    如何判断增加多少consumer消费实例的个数?

    作者回复: 你可以简单计算一下,消费并行度:单实例平均消费tps * 消费并行度 > 生产消息的总tps 消费并行度 = min(consumer实例数,分区数量)

    2020-03-04
    14
  • lecy_L
    消息积压处理: 1、发送端优化,增加批量和线程并发两种方式处理 2、消费端优化,优化业务逻辑代码、水平扩容增加并发并同步扩容分区数量 查看消息积压的方法: 1、消息队列内置监控,查看发送端发送消息与消费端消费消息的速度变化 2、查看日志是否有大量的消费错误 3、打印堆栈信息,查看消费线程卡点信息

    作者回复: 👍👍👍

    2019-08-16
    3
    13
  • 亚洲舞王.尼古拉斯赵四
    如果使用了批量消费的方式,那么就需要批量确认,如果一次消费十条消息,除了第七条消费失败了,其他的都处理成功了,但是这中情况下broker只能将消费的游标修改成消息7,而之后的消息虽然处理成功了,但是也只能使用类似于拉回重传的方式再次消费,浪费性能,而且这种批量消费对于消费者的并发我觉得不是很友好,可能消费者1来了取走了十条消息在处理,这时候消费者2过来了也想取十条消息,但是他需要等待消费者1进行ack才可以取走消息,不知道说的对不对,请老师指正

    作者回复: 是这样的。

    2019-08-06
    2
    13
  • 长期规划
    老师,如果onMessage方法中,收到消息后不确认,等真正处理完消息再确认,就可以了吧,这样就可以用内存队列了

    作者回复: 理论上是可以的,但你要注意,像RocketMQ,采用默认配置的时候,onMessage方法结束后,如果没抛异常,默认就会自动确认了。

    2019-09-02
    2
    10
  • 涛涛
    临时扩容消息分区,已堆积的消息会转移到新分区上吗?

    作者回复: 不会的。

    2020-04-13
    4
    6
  • 传志
    老师想问下,为什么生产端性能问题怎么会引起消息堆积呀

    作者回复: 生产端发送慢不会引起消息积压的。

    2020-03-09
    6
收起评论
显示
设置
留言
99+
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部