性能文章>【全网首发】MQ系列13:消息大量堆积如何为解决>

【全网首发】MQ系列13:消息大量堆积如何为解决原创

10月前
289736

MQ系列1:消息中间件执行原理
MQ系列2:消息中间件的技术选型
MQ系列3:RocketMQ 架构分析
MQ系列4:NameServer 原理解析
MQ系列5:RocketMQ消息的发送模式
MQ系列6:消息的消费
MQ系列7:消息通信,追求极致性能
MQ系列8:数据存储,消息队列的高可用保障
MQ系列9:高可用架构分析
MQ系列10:如何保证消息幂等性消费
MQ系列11:如何保证消息可靠性传输
MQ系列12:如何保证消息顺序性

1 背景

我们在前面两个章节中,介绍了消息组件如何保证可靠性传输和顺序行消费,参考上面系列的11、12章节。

  • 比如在消息生产阶段,如何保证消息发出的稳定性和可靠性;
  • 在消息服务器处理阶段,如何保证消息从生产到发送出去,经过网络传输,再到达Broker服务器并被接收的这整个阶段的可靠性,即如何使用ACK机制来保证消息传递的可靠性;
  • 还有就是消息消费的可靠性,Broker作为消息服务器,消息接收并持久化消息并消费的整个过程的可靠性如何保障。
    对于消息队列组件来说,这几个步骤出现问题,都有可能造成消息队列无法进行正常运行,消息堆积的情况发生。
    另外一种情况可能就是突发的流量峰值,这种一般发生在某种消费促销活动或者各种抢购、竞拍场景中。

2 原因分析

2.1 消息生产(Producer)远超预期

消息的生产的规模远超过原来的预期值,成数倍甚至几十倍的增长,这种产生的原因可能如下:

  1. 比如遇到各种流量冲击的活动:618、双11大促、竞拍、抢购、秒杀业务。(这种需要做好容量预估管理)
  2. 程序缺陷;死循环调用、批量请求、内存泄漏导致的流量飙升问题。(这种需要做好)

image.png

2.2 消息接收和持久化出现故障

Broker服务器接收消息并持久化出现问题:服务故障、网络延迟、持久化失败等,这种情况一般也比较少见…

2.3 消息消费(Consumer)能力下降致消息堆积

出现原因可能有如下几种:

  • 消费失败时大量重试导致消息堆积。
  • 消费者程序的故障:如 程序死锁,io阻塞等。
  • 消费者资源瓶颈:目前的主流消息队列,单个节点消息收发的性能可以达到万级别甚至10万级+的水平。除非容量预估没有做好,一般不会出现这种问题。即使出现这种问题,通过Scale Out Broker 的实例数也是比较轻松可以解决的。

3 消息堆积的解决方案

根据上面的整理,在遇到消息堆积的时候,先检查下导致堆积的原因,看符合上述的三个原因的哪一个。

  • 消息生产(Producer)远超预期
  • 消息接收和持久化出现故障
  • 消息消费(Consumer)能力下降致消息堆积

找到原因之后,把问题处理完成,然后临时扩容,来处理堆积的消息数据。具体操作步骤如下,参考下面的图:

  • 先分析原因,如果是Consumer或者Broker出现故障要先确保恢复故障;如果是消息消费问题,先修复程序问题。
  • 暂停现有Consumer的消费动作。
  • 临时建立好原先10倍(或者N倍)的queue数量,即新建topic,partition分区是原来的10倍。
  • 写一个程序,这个程序只做简单的转发工作,目的就是将消费积压的消息,均匀的消费到临时扩容好的queue里(这里面有10倍的容量)。
  • Consumer也扩容10倍,对应一个Consumer消费一个临时的Queue。相应的被消费者依赖的业务处理服务也需要对应的扩容,包含缓存、数据库、文件服务等等。
  • 快速消费结束之后,记得恢复原来的消费架构,避免大量资源浪费。

image.png

总结

本文介绍了消息堆积可能导致的原因,以及基本的处理步骤。大部分消息中间件的健壮性都是非常好的。
业务的不合理使用和扩展一般是主要诱因,所以平时需要多关注业务服务的变化。

点赞收藏
Pinocao
请先登录,查看3条精彩评论吧
快去登录吧,你将获得
  • 浏览更多精彩评论
  • 和开发者讨论交流,共同进步

为你推荐

实现定时任务的六种策略

实现定时任务的六种策略

6
3