解决性能测试问题之事务为什么这么慢？

在做系统的整体性能测试时发现经常会卡在一个较低的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的方式保证消息发送成功。

再次测试，性能明显提高。

最后： 下方这份完整的软件测试视频学习教程已经整理上传完成，朋友们如果需要可以自行免费领取 【保证100%免费】

这些资料，对于【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴上万个测试工程师们走过最艰难的路程，希望也能帮助到你！

软件测试技术交流群社：746506216（里面还有工作内推机会，毕竟我们是关系社会。）

软件测试面试文档

我们学习必然是为了找到高薪的工作，下面这些面试题是来自阿里、腾讯、字节等一线互联网大厂最新的面试资料，并且有字节大佬给出了权威的解答，刷完这一套面试资料相信大家都能找到满意的工作。

面试文档获取方式：

​