关于golang:深度剖析分布式事务性能

随着微服务的大规模利用，跨微服务的分布式事务也越来越多，那么分布式事务的性能到底怎么样？性能会降落多少？是否满足业务需要？这些指标关系到分布式事务是否顺利的引入到生产利用，是大家十分关怀的问题。

本文尝试深入分析分布式事务带来的额定开销，利用中的哪些因素会影响最终的性能，瓶颈点在哪里，如何晋升性能。本文以反对多语言的分布式事务管理器 https://github.com/yedf/dtm 的 saga 事务作为性能测试的样本，对性能测试的后果，进行深度分析。

测试环境

测试过程

# 在 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 性能

咱们首先用测试了 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 我的项目，给颗星星反对咱们的工作！