随着微服务的大规模利用，跨微服务的分布式事务也越来越多，那么分布式事务的性能到底怎么样？性能会降落多少？是否满足业务需要？这些指标关系到分布式事务是否顺利的引入到生产利用，是大家十分关怀的问题。
本文尝试深入分析分布式事务带来的额定开销，利用中的哪些因素会影响最终的性能，瓶颈点在哪里，如何晋升性能。本文以反对多语言的分布式事务管理器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 preparesysbench 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 rungo 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我的项目，给颗星星反对咱们的工作！