这是一个创建于 1139 天前的主题，其中的信息可能已经有所发展或是发生改变。
随着微服务的大规模应用，跨微服务的分布式事务也越来越多，那么分布式事务的性能究竟怎么样？性能会下降多少？能否满足业务需求？这些指标关系到分布式事务能否顺利的引入到生产应用，是大家非常关心的问题。
本文尝试深入分析分布式事务带来的额外开销，应用中的哪些因素会影响最终的性能，瓶颈点在哪里，如何提升性能。本文以支持多语言的分布式事务管理器https://github.com/yedf/dtm的 saga 事务作为性能测试的样本，对性能测试的结果，进行深度剖析。
测试环境
| 机型 | CPU/内存 | 存储 | 系统 | Mysql |
|---|---|---|---|---|
| 阿里云 ecs.c7.xlarge | 4 核 8G | 500G ESSD IOPS 26800 | Ubuntu 20.04 | Docker mysql:5.7 |
测试过程
# 在 dtm 目录下
docker-compose -f helper/compose.mysql.yml up -d # 启动 Mysql
# 运行 sysbench 对 mysql 进行测试
sysbench oltp_write_only.lua --time=60 --mysql-host=127.0.0.1 --mysql-port=3306 --mysql-user=root --mysql-password= --mysql-db=sbtest --table-size=1000000 --tables=10 --threads=10 --events=999999999 --report-interval=10 prepare
sysbench oltp_write_only.lua --time=60 --mysql-host=127.0.0.1 --mysql-port=3306 --mysql-user=root --mysql-password= --mysql-db=sbtest --table-size=1000000 --tables=10 --threads=10 --events=999999999 --report-interval=10 run
go run app/main.go bench > /dev/nul # 启动 dtm 的 bench 服务，日志较多，重定向到 nul 设备
bench/run-dtm.sh # 新启动命令行，运行 dtm 相关的各项测试
PS：如果您需要动手进行测试，建议您购买香港或国外的主机，这样相关的 github 、docker 访问会快很多，能够快速搭建好环境。我在国内购买的主机，访问 github 和 docker，非常慢，有时连接不上，无法顺畅进行测试。
测试指标
我们会对以下几个指标进行对比：
- Global-TPS：用户视角下，完成了多少个全局事务。
- DB-TPS：各项测试中，在 DB 层面完成的事务数量
- OPS：各项测试中，完成了多少个 SQL 语句
结果对比
| Mysql | 无 DTM-2SQL | DTM-2SQL | DTM-2SQL-Barrier | 无 DTM-10SQL | DTM-10SQL | DTM-10SQL-Barrier | |
|---|---|---|---|---|---|---|---|
| Global-TPS | - | 1232 | 575 | 531 | 551 | 357 | 341 |
| DB-TPS | 2006 | 2464 | 2300 | 2124 | 1102 | 1428 | 1364 |
| OPS | 12039 | 4928 | 5750 | 6372 | 10620 | 9282 | 9548 |
Mysql 性能
我们首先用测试了 Mysql 自身的性能。在 DTM 的这次性能测试中，写操作较多，因此我们这次主要对 Mysql 的写进行了性能测试。
我们采用了 sysbench 中的 oltp_write_only 基准，在这个基准中，每个事务包含 6 个写 SQL （有 insert/update/delete ）。
在这个基准下，每秒完成的事务数量大约为 2006，完成 SQL 数量大约为为 12039 。这两项结果，会在后续的 DTM 相关测试中引用。
DTM 测试
分布式事务中涉及的事务模式有多种，我们选取一个有代表性的简单 Saga 模式作为代表，分析分布式事务 DTM 的性能。
我们选取的 Saga 事务，包含两个子事务，一个是 TransOut 转出余额，一个是 TransIn 转入余额。转入转出各包含两个 Sql，分别是更新余额和记录流水。
无 DTM-2SQL
我们首先测试不采用 DTM 的情况，也就是直接调用 TransOut 和 TransIn，测试结果是每秒完成了 1232 个全局事务。每个全局事务包含转出和转入两个子事务，因此 DB-TPS 为 2464，然后每个子事务又包含两个 SQL，因此总的 SQL 操作为 4928 。
这个结果对比 MYSQL，DB-TPS 更高，而 DB-SQL 只有一半，主要原因为每个事务都需要将数据同步到磁盘，需要额外消耗性能，此时瓶颈主要在系统数据库的事务能力
DTM-2SQL
我们接着测试采用 DTM 的情况，采用了 DTM 之后，一个 SAGA 事务的时序图如下：
全局事务会包括 4 个事务：TransIn 、TransOut 、保存全局事务+事务分支、修改全局事务为已完成。将每个子事务分支修改为已完成也各需要一个事务，但 DTM 采用异步写进行了合并，减少了事务。
每个全局事务包括的 SQL 数量为：1 个保存全局事务、1 个保存分支、1 个读所有分支、2 个修改分支为完成、1 个修改全局事务为完成，一共 6 个额外的 SQL，加上原本子事务的 4 个 SQL 是 10 个。
测试结果中，每秒完成全局事务数为 575，那么 DB-TPS 为 2300，OPS 为 5750，对比前面不采用 DTM 的方案，DB-TPS 略有下降，OPS 有一定的上升，瓶颈还是在系统数据库
DTM-2SQL-Barrier
加入了子事务屏障后，每个子事务分支会多一个 insert 语句，每个全局事务对应的 SQL 数量为 12.
测试结果中，每秒完成全局事务数为 531，那么 DB-TPS 为 2124，OPS 为 6372，对比前面 DTM 的方案，DB-TPS 略有下降，OPS 略有上升，符合预期
无 DTM-10SQL
我们对压测的数据做调整，将每个子事务里的 SQL 数量，从 2 调整为 10，将子事务中的 SQL 循环执行 5 次。
无 DTM 的压测结果中，每秒完成的全局事务数为 551，DB-TPS 为 1102，OPS 为 10620 。这个结果中，OPS 与 MYSQL 的接近，瓶颈主要在数据库的 OPS 。
DTM-10SQL
这个压测结果中，每秒完成的全局事务数为 357，DB-TPS 为 1428，OPS 为 9282，其中 OPS 比无 DTM 的情况下降了百分之十几，主要原因为 DTM 的表，有较多的字段及索引，每个 SQL 的执行开销会大一些，因此总 OPS 会更低。
DTM-10SQL-Barrier
测试结果中，每秒完成全局事务数为 341，那么 DB-TPS 为 1364，OPS 为 9548，对比前面 DTM 的方案，DB-TPS 略有下降，OPS 略有上升，符合预期
小结
由于分布式事务需要保存全局事务和分支事务的状态，会产生额外的写，大约是每个全局事务产生额外 4+n(子事务数量)个 SQL 操作，2 个数据库事务。当业务很简单，SQL 少，使用分布式事务会导致事务吞吐量下降 50%；如果业务较复杂，SQL 多，性能大约下降 35%。下降的原因主要为全局 /分支事务状态的保存，产生了额外的 SQL 操作。
从 DTM 的压测结果与 MYSQL 的压测数据对比来看，DTM 产生的额外开销很小，已经最大化的利用了数据库的能力。
一台 ecs.c7.xlarge+500G 磁盘的阿里云服务器，安装 mysql 后，大约能够提供 300~600 的 Global-TPS，每月费用为 900 元（ 2021 年 10 月价格），这个成本对比提供的业务能力来说，已经很低了。
如果您需要更强劲的性能，可以购买更高配的配置，也可以在应用层部署多组 DTM，两种方案的代价并不大，足以满足绝大部分公司的需求。
欢迎大家访问https://github.com/yedf/dtm项目，给颗星星支持我们的工作！
Select Language