作者： 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 负载均衡清单：
创建测试库：
导入测试数据：
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 有了充足的信心。
评论