TiDB 在 U-Next ARM 平台上的应用与实践

U-Next 是日本领先的视频点播服务公司，类似于国内的爱奇艺、国外的 Netflix。近几年 U-Next 的整体业务保持高速成长的势头，原先的基础架构已经无法应对业务的高速增长，对 IT 基础架构的改造迫在眉睫。

为什么选择 TiDB

上图是大部分场景采用的架构，属于典型的 MySQL 读写分离方案，采用一个几年前 360 基于 MySQL-Proxy 修改的开源中间件服务 Atlas，从 2015 年使用至今，一直很稳定，也很容易上手，但是这个开源项目已经好久没有人维护了，如果后续的新业务继续采用这个方案，肯定要自己踩这个大坑。这个方案随着服务器并发增大延迟会升高，虽然可以水平扩展读写，但是后端的 MySQL 很容易达到单机的性能瓶颈，一旦达到瓶颈，扩容起来非常痛苦，所以需要寻找一个新的方案来解决。

我们需要一个什么样的数据库？这里简单列一下需求：

综上几点，比较了市面上主流的几款 SQL 产品之后，TiDB 成为我们最好的选择。

为什么选择 ARM

x86 它不香吗？x86 是挺香的，但我们主要考虑的还是三点，成本、兼容性和运维。

ARM 平台的成本相较于 x86 会有一部分优势，对于小体量的用户来说是一个不错的选择。兼容性方面，TiDB 官方也有对 ARM 做过测试和验证，运行起来没有任何问题。运维层面，ARM 的可靠性到底如何？可能没有用过的用户，会担心宕机和崩溃，作为一个视频点播公司，U-Next 的分布式存储平台早在几年前已经全部替换成 ARM 平台，目前为止运行都比较稳定。

当然在和 ARM 磨合的过程中，也遇到过问题，硬件厂商都及时帮助解决了。现在大部分在非必须使用 x86 的情况下，我们都会尝试着使用 ARM，鉴于以往的这些经历，我们决定选用 ARM 来上线核心生产的数据库系统。

TiDB 在 ARM 与 x86 平台的性能测试对比

基于两种架构的服务器平台，我们进行了一次 TiDB 的性能对比测试。

TiDB 官方已有这两个平台的性能测试对比，采用了 Sysbench 这个工具，具有很重要的参考意义。我们从自身业务出发，使用 locus 模拟访问线上业务，一个客户端每秒发送一次请求，单表 3 亿行的测试数据，进行先 Get、再 Post、最后 Put 为一次的操作，总共对 API 请求 20 万次。

上图是 RPS 的结果，客户端数量在 50、100、150、200 的情况下，ARM 的表现略逊于 x86，在可接受的范围。从这个业务的需求来看，RPS 50 就已经满足了。

从响应时间来看，单个 API 服务器的瓶颈出现在 150 个客户端附近，再增加客户端数量，RPS 也提升不了多少，反而响应时间变得更大。测试也许有不太严谨的地方，我们通过测试看到了基于业务模型， ARM 和 x86 在 TiDB 上的性能差距并不明显。

前面提到的有一个 10 亿行表的数据库，经常被访问，性能已经跟不上业务发展，庆幸的是 TiDB 完全兼容这个业务使用的 MySQL 方法，在 ARM 平台的性能表现也很好，于是我们采用了 TiDB 替换了原来的数据库。

我们在 2019 年 12 月 10 日凌晨做了数据库的迁移，来看看替换前和替换后的效果对比：上面一张截图是替换前 9 晚上高峰响应时间超过 500 毫秒请求的数量，下面一张截图是更换后 10 晚上高峰时间超过 500 毫秒请求的数量。我们可以看一下，Y 轴会有惊喜，上图是四位数，下图是三位数，提升了一个数量级。

我们还做了数据中心的迁移，迁移 TiDB 后，API 和 TiDB 在不同的数据中心，通过专线互连，在 络延迟比迁移前多 1-2 ms 的情况下，依靠 TiDB 优异的性能提升了服务品质，这个太令人兴奋了。

基于 ARM 的优化

关于 ARM 的优化，需要特别感谢 PingCAP 的研发同事，帮我找出了 THP 的差异。我们在测试导入数据的时候，发现大概在 100G 数据的时候，x86 没有关闭 THP 的情况下，所有的状态也都正常。在 ARM 平台上没有关闭 THP 的状态下，TiKV 很容易造成负载过重 OOM。所以使用 ARM 的话，强烈建议一定要关闭 THP。

关于 Numa 的绑定，我们使用的平台中 ARM 有四个 Numa 节点，而 x86 只有两个，ARM 的内存处理需要 CPU 去参与，默认在不绑定内核的情况下，Numa 的节点越多，内部延迟就会越大。所以建议把进程绑定到相应 Numa 节点的内核上， 卡对应也得做绑定，会减少延迟。TiDB 非常优秀，除了海量数据场景以外，甚至可以不考虑如何去调优。上图是 Numa 调整后的测试结果，可以看到在 ARM 和 x86 平台运行 TiDB ，几乎不存在差异。

以上就是我今天的分享，谢谢大家。