【转载】rabbitmq消息发送卡顿的排查(spring-amqp)

最新推荐文章于 2023-10-01 20:56:58 发布

小伙很稳健

最新推荐文章于 2023-10-01 20:56:58 发布

阅读量2.1k

点赞数

分类专栏： # rabbitMQ 文章标签： rabbitmq spring java

原文链接：https://www.jianshu.com/p/1c8febd6a1b2

版权

rabbitMQ 专栏收录该内容

11 篇文章 0 订阅

订阅专栏

问题描述

线上系统出现SLOW慢请求告警，经排查，发现为rabbitmq的消息发送卡顿引起，卡顿时间几秒钟~几十秒不等。由于只卡顿了1分钟左右，笔数不多（30笔以内），且后续就没了，所以只是排查了下系统各项指标（JVM、mq状态、磁盘等），都正常。就没有继续深入了排查了。但过了一段时间，又出现问题了~~(果然每个线上问题都要仔细追踪- -#)
发生频率：每次系统重启后，都会出现一次，且每个实例出现一次后，后续就不在出现了，直到下一次系统实例重启。在出现卡顿时，当前实例仍有其他的消息发送是正常的。
单个消息大小：1KB以内。

使用情况描述

rabbitmq：3.7.17， erlang：22.0.7
采用spirng-amqp包进行封装与rabbitmq的交互，版本为1.7.3.RELEASE
使用Spring-amqp的CachingConnectionFactory缓存连接工厂
调整生产者的cache-mode为Connection模式（原先为CHANNEL）
调整生产者的核心连接数量为24个，最大连接数量为48个
设置生产者连接的channelCheckoutTimeoutt为3秒（该参数的旨意是从CachingConnectionFactory获取connection/channel的等待时间，CachingConnectionFactory实际就是个connection或者channel的缓存池子）

排查一: rabbitmq的per-connection连接流控引起的客户端消息发送卡顿

在这里插入图片描述
由于通过日志已经能够确定是消息发送这一步产生了卡顿，那初步怀疑就是由于rabbitmq的流控机制引起的卡顿，但根据监控，当时卡顿时间内，rabbitmq的所有connection/channel的状态都是正常的，没有存在flow/block状态的情况。（rabbitmq的监控API：{rabbitmq-admin管理后台域名}/api/index.html）
所以排除是rabbitmq服务器的流控引起的

排查二: 应用客户端自己的问题

由于出现问题是某次spring-amqp的缓存模式cache-mode从channel改为了connection（PS：此处调整，是因为channel模式为单连接，所有的MQ消息，无论各种业务场景都是共用了这个连接，之前发生了一次per-connection的流控，导致这个连接下的所有消息都发不出去，为了降低业务影响，将单连接改造为多连接模式）
所以把目光转向了spring-amqp的使用上，经过代码排查，果然是spring-amqp的一个BUG。。

在使用CachingConnectionFactory的createConnection()创建rabbitmq连接的时候，会存在一个同步锁（由于该工厂就是个缓存池，所以需要同步锁来确保缓存的个数不超过配置的MAX个数），知道连接创建完毕后，才会释放该锁，那么如果存在某个连接创建速度过慢，就会导致后续的连接创建时间也卡顿，都在等待该同步锁的释放
在这里插入图片描述
如果cache-mode是connection模式，根据源码展示的，只要从连接缓存池没有拿到一个空闲的connection，就直接等待一个checkout-timeout的时间（配置的是3秒）。这就代表，每一个连接的创建，都必须等待3秒钟。。这就解释了为啥线上的卡顿基本都是3、6、9秒左右。(注：刚启动应该是没有空闲链接的)
在这里插入图片描述
这是一个比较明显的BUG，后来在gitgub也找到相关的问题：https://github.com/spring-projects/spring-amqp/issues/1026
修复代码也很简单：

在这里插入图片描述
但升级spring-amqp包到已修复的版本是2.1.x 中间版本跨度太大，且2.1.x需要依赖spring 5，我们spring的基础版本还是4.x，贸然升级风险太大

解决

结合业务场景，此处MQ的消息场景是用于将交易请求做异步化处理，达到一个削峰填谷的目的。改造为多连接模式，是由于之前单连接模式发生了流控后，导致使用该连接的所有业务场景均block。虽然改为了多连接，但实际上还是存在各个业务共享某个连接的情况，隔离性还不是特别高，应该是按重要程度进行分级隔离使用各自的连接。
经过考量，决定使用Spring提供的RoutingConnectionFactory，通过将业务场景码来分隔实际的ConnectionFactory（实际还是CachingConectionFactory，采用单连接channel模式），来达到业务场景隔离连接。
PS：连接并不是越多越好，我们此处只是将业务高等级的区分各个连接，其余实时性要求不是那么高的，单独在共享使用另外一个连接
RoutingConnectionFactory，使用此方式，可根据Expression灵活将连接（connection）分为多个，并根据自己场景定制（例如生产和消费连接分离，生产，消费者又按照不同维度分多个连接），此时，ConnectionFactory的实现仍然使用CachingConnectionFactory的channel模式。这样，可以形成不同场景使用不同的连接（避免相互影响），同一连接又可为多个channel共享（提高性能）

作者：小菜Yang
链接：https://www.jianshu.com/p/1c8febd6a1b2
来源：简书
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。