TiDB5.0异步事务特性体验——基于X86和ARM混合部署架构

作者：alexshen

原文来源：https://tidb.net/blog/71bb4db7

【是否原创】是\
【首发渠道】TiDB 社区\
【正文】

业务背景

神州数码是国内领先的企业数字化服务商，从2018年开始，我们使用v2.0.5搭建了第一套TiDB数据库集群，之后便与TiDB结下不解之缘，在集团内多个业务场景下使用TiDB， 其中一个比较有意思的场景是员工考勤。

神州数码拥有三家上市公司，平台遍布全国各地，员工数量众多，早上九点左右打卡，打卡途径包括但不限于门禁、指纹、人脸识别和移动签到，并且各地的考勤规则也略有差异。各地的打卡机不同，对接的数据库也不同，比如mysql、oracle、SQL Server等。过去，员工只能在下午四点半以后才能查询当天早上的打卡情况。随着业务规模和人员数量的增长，服务器需要不停的升级以应对高峰期打卡时的并发数据量，有时会出现打卡异常情况。上下班高峰期对考勤系统是一个不小的挑战，并且这是一个典型的写多读少的场景，为了能及时反馈打卡结果，对数据写入的延迟要求比较高。

而TiDB在5.0版本中提供了异步事务提交特性，这一点对写入频繁的场景非常有用，它可以有效地降低请求延时提高吞吐量。 考虑到这非常适用于考勤系统的场景，我们在同等配置下测试TiDB 5.0对事务读写性能的提升情况。

为什么使用混合部署架构

ARM架构的处理器以其优异的性能、低廉的成本和功耗被越来越多地使用在各种设备之上，对比X86的机器，ARM机器在性能功耗比（Performance per watt）方面是具有天然优势的，众多服务器厂商也早已经把ARM架构应用在CPU设计中，华为鲲鹏920便是比较典型的一款产品。

TiDB可以完美运行在ARM架构之上，这一点已经有实际案例可以说明。

基于TiDB的多平台兼容特性，我们同时使用ARM和X86的机器搭建混合架构的TiDB集群，来测试一下在混合部署架构下TiDB 5.0的异步事务提交特性到底有多少性能提升。

本次测试使用ARM物理机是神州鲲泰多路服务器，它搭载了4颗鲲鹏920CPU，核心数达到96核。

资源配置

本次测试所有的节点都运行在Centos 7.6系统，ARM节点和X86节点分别运行在两台物理机，使用千兆网络通信。

TiDB集群的拓扑结构如下图所示：

具体说明为：

• 3台相同配置的TiDB节点，其中2台ARM+1台X86


• 3台相同配置的PD节点，其中2台ARM+1台X86


• 6台相同配置的TiKV节点，其中3台ARM+3台X86


• 1台监控节点，ARM架构


• 1台HAProxy节点，X86架构


• 1台Sysbench节点，X86架构

测试工具使用Sysbench基准测试，版本是1.0.20，用oltp_read_write场景模拟复杂的事务提交，最后对比TiDB 4.0版本和5.0版本在不同并发量下事务的吞吐量和延时情况。

TiDB集群配置项：

```
global:
user: "tidb"
ssh_port: 22
deploy_dir: "/tidb-deploy"
data_dir: "/tidb-data"
arch: "arm64"

monitored:
node_exporter_port: 9100
blackbox_exporter_port: 9115

server_configs:
tidb:
log.level: "error"
prepared-plan-cache.enabled: true
tikv:
log.level: "error"

pd_servers:
- host: 10.3.65.xxx
- host: 10.3.65.xxx
- host: 10.3.70.xxx
arch: "amd64"

tidb_servers:
- host: 10.3.65.xxx
- host: 10.3.65.xxx
- host: 10.3.70.xxx
arch: "amd64"

tikv_servers:
- host: 10.3.65.xxx
- host: 10.3.65.xxx
- host: 10.3.65.xxx
- host: 10.3.70.xxx
arch: "amd64"
- host: 10.3.70.xxx
arch: "amd64"
- host: 10.3.70.xxx
arch: "amd64"

• host: 10.3.65.xxx

  
  



• host: 10.3.65.xxx

  
  

alertmanager_servers:
- host: 10.3.65.xxx
```

测试方法

• 使用tiup部署4.0.0版本集群


• 使用HAProxy代理3个TiDB节点


• 使用Sysbench准备测试数据，10张表，单表1000万行数据


• 对oltp_read_write场景分别做并发维度50、100、200、400、800的压测


• 销毁集群


• 用相同的配置文件部署5.0.0版本集群，默认开启了异步事务提交


• 使用Sysbench准备相同数据量的测试数据


• 对oltp_read_write场景分别做并发维度50、100、200、400、800的压测


• 数据对比得出结论，对比指标分别是QPS、TPS、延时

Sysbench配置项：

--table_size=10000000
--tables=10
--threads={50、100, 200, 400, 800}
--time=300
--report-interval=10

测试步骤

首先搭建TiDB4.0.0集群，集群信息如下：

HAProxy负载均衡清单：

创建测试库：

create database sbtest;

导入测试数据：

sysbench /usr/share/sysbench/oltp_read_write.lua --db-driver=mysql --mysql-host={proxy ip} --mysql-port=4000 --mysql-db=sbtest --mysql-user=root --mysql-password= --table_size=10000000 --tables=10 --threads=100 --time=300 --report-interval=10 prepare

执行50线程下的压测：

sysbench /usr/share/sysbench/oltp_read_write.lua --db-driver=mysql --mysql-host={proxy ip} --mysql-port=4000 --mysql-db=sbtest --mysql-user=root --mysql-password= --table_size=10000000 --tables=10 --threads=50 --time=300 --report-interval=10 run

执行100线程下的压测：

sysbench /usr/share/sysbench/oltp_read_write.lua --db-driver=mysql --mysql-host={proxy ip} --mysql-port=4000 --mysql-db=sbtest --mysql-user=root --mysql-password= --table_size=10000000 --tables=10 --threads=100 --time=300 --report-interval=10 run

执行200线程下的压测：

sysbench /usr/share/sysbench/oltp_read_write.lua --db-driver=mysql --mysql-host={proxy ip} --mysql-port=4000 --mysql-db=sbtest --mysql-user=root --mysql-password= --table_size=10000000 --tables=10 --threads=200 --time=300 --report-interval=10 run

执行400线程下的压测：

sysbench /usr/share/sysbench/oltp_read_write.lua --db-driver=mysql --mysql-host={proxy ip} --mysql-port=4000 --mysql-db=sbtest --mysql-user=root --mysql-password= --table_size=10000000 --tables=10 --threads=400 --time=300 --report-interval=10 run

执行800线程下的压测：

sysbench /usr/share/sysbench/oltp_read_write.lua --db-driver=mysql --mysql-host={proxy ip} --mysql-port=4000 --mysql-db=sbtest --mysql-user=root --mysql-password= --table_size=10000000 --tables=10 --threads=800 --time=300 --report-interval=10 run

以上5次压测的事务监控汇总为：

接下来清理掉4.0.0的集群：

tiup cluster destroy tidb-test

重新部署5.0.0的新集群：

我们查看新集群已经开启了异步事务提交：\

同样导入单表1000万行数据后做5次压测。

执行50线程下的压测：

sysbench /usr/share/sysbench/oltp_read_write.lua --db-driver=mysql --mysql-host={proxy ip} --mysql-port=4000 --mysql-db=sbtest --mysql-user=root --mysql-password= --table_size=10000000 --tables=10 --threads=50 --time=300 --report-interval=10 run

执行100线程下的压测：

sysbench /usr/share/sysbench/oltp_read_write.lua --db-driver=mysql --mysql-host={proxy ip} --mysql-port=4000 --mysql-db=sbtest --mysql-user=root --mysql-password= --table_size=10000000 --tables=10 --threads=100 --time=300 --report-interval=10 run

执行200线程下的压测：

sysbench /usr/share/sysbench/oltp_read_write.lua --db-driver=mysql --mysql-host={proxy ip} --mysql-port=4000 --mysql-db=sbtest --mysql-user=root --mysql-password= --table_size=10000000 --tables=10 --threads=200 --time=300 --report-interval=10 run

执行400线程下的压测：

sysbench /usr/share/sysbench/oltp_read_write.lua --db-driver=mysql --mysql-host={proxy ip} --mysql-port=4000 --mysql-db=sbtest --mysql-user=root --mysql-password= --table_size=10000000 --tables=10 --threads=400 --time=300 --report-interval=10 run

执行800线程下的压测：

sysbench /usr/share/sysbench/oltp_read_write.lua --db-driver=mysql --mysql-host={proxy ip} --mysql-port=4000 --mysql-db=sbtest --mysql-user=root --mysql-password= --table_size=10000000 --tables=10 --threads=800 --time=300 --report-interval=10 run

以上5次压测的事务监控汇总为：

测试结果

通过以上对比数据可以看出，在并发量比较小的时候5.0版本性能提升非常明显，到400并发后吞吐量已经到了极限，随着并发量不断加大凸显出了硬件瓶颈，性能提升开始放缓，不过此时各指标依然高于4.0版本。

从各节点IO指标的监控数据来看，性能瓶颈主要是TiKV节点IO近乎打满导致，这一点也说明存储层依然对硬件要求比较高，希望TiDB能在后续版本中继续深度优化。

参考官方给出的TiDB 5.0测试数据，混合部署的测试结果在性能提升上还要高于纯X86机器，这一点还是非常让人惊喜的。

另外一点值得一提的是，从各自5次测试的监控曲线来看，TiDB 5.0在事务提交上的稳定性也有肉眼可见的提升，4.0的事务曲线波动比较大，5.0的事务曲线整体趋于平稳。

总结

• TiDB支持多元架构部署，为各种应用提供架构选择。本次测试的两个TiDB版本都能够非常平稳地运行在混合架构下，整个测试过程没有任何异常问题。


• 单在事务提交优化上，TiDB 5.0版本比4.0版本有大幅的性能提升，QPS、TPS、延时这3个重要指标都明显优于4.0。


• 事务性能的提升，意味着TiDB在面对高并发的TP型业务有了更多发展空间。\
  分析了上面的测试数据，我们对把已有的业务系统升级到TiDB 5.0有了充足的信心。