在做系统的整体性能测试时发现经常会卡在一个较低的QPS(单机低于100)数值,而且应用服务器的负载不高,检查MQ消费速率只有40左右。
经过一番排查,发现消息发送端发现消息速率很低,大约40条/s。
于是让开发帮忙搭建一个最小化工程单测Rabbitmq发送性能,发现在启用发送端事务后性能下降非常明显。
测试机SSD硬盘测试结果1,0w条消息未开启事务,大约10s发送完毕;但开启了事务后,需要将近320s,差了30多倍。
接着翻阅Rabbitmq官网,发现开启事务性能最大损失超过250倍。
事务为什么会慢?
该标志位开启后表示Rabbitmq的发送统一被spring事务管理。当一段代码被@Transactional包裹,那么只有当事务结束后,消息才会正在的发送到Rabbitmq的exchange中。
是否可以去掉事务呢?
实践证明,不行。
因为某些消息,特别是实体的新增或者更新消息发出后,消费者有可能会通过API反查,这时如果生产者本地事务未提交。消费者就有可能消费到空数据或者旧数据。所以生产者必须将发送消息的事务包裹在本地数据库事务当中。
在过去的实践中,有一种解法可以在不开启事务的情况下解决这个问题,就是利用本地消息表,即生产者调用后不发送,而是将消息写入到本地消息表,当事务失败那么此次写入操作也会回滚。
真正发送消息到MQ就开启另一个定时线程轮询该本地消息表异步发送消息。
这种方法理论上可行,但实际操作非常复杂,当有多个生产者实例时,定时发送线程也会有多个,那么就会遇到各种并发问题。
最大限度改善性能
既然无法去除事务,并且也不希望代码异常复杂。那么可以将消息分为两类,一类是changlog即实体的变化,一类是command,即通知消费者可以开始做某事,通常用在同步转异步的场景。
对于第一类消息仍然保留事务,对于第二类消息关闭发送事务,采用PublisherConfirm的方式保证消息发送成功。
再次测试,性能明显提高。
感谢每一个认真阅读我文章的人,礼尚往来总是要有的,虽然不是什么很值钱的东西,如果你用得到的话可以直接拿走:
这些资料,对于【软件测试】的朋友来说应该是最全面最完整的备战仓库,这个仓库也陪伴上万个测试工程师们走过最艰难的路程,希望也能帮助到你!有需要的小伙伴可以点击下方小卡片领取