版权声明:本文由神州数码云基地团队整理撰写，若转载请注明出处。

为什么使用混合部署架构

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集群的拓扑结构如下图所示，PD、TiDB、TiKV服务分别横跨双架构：

具体的配置清单为：

• 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型业务有了更多发展空间。