行业：游戏

作者：李文杰(网易游戏计费组高级数据库管理员、TiDB用户组大使)

网易游戏，下属有网易公司。是一家为全球用户提供自主开发的PC客户端和手机游戏的领先供应商。作为中国网络游戏市场最大的玩家之一，我们目前运营着250多款游戏，其中一些游戏保持着数百万的日活跃用户。网易游戏已经连续第五个季度实现了超过10亿美元的营收。

计费团队是为网易游戏产品提供统一登录和支付解决方案的支持部门。我们的计费系统为280多个游戏客户端和服务器以及300多个国内外渠道供应商统一存储。我们还为产品运营团队、战略研究团队等业务单位提供有价值的数据服务。

随着我们业务的蓬勃发展，飙升的数据规模成为了我们的噩梦。每天，我们的计费应用程序处理超过36亿次请求，生成超过5tb的日志数据，并向数据库写入几十gb的数据。这暴露了我们的独立MySQL架构在可伸缩性、数据隔离、性能和其他方面的瓶颈。

在这篇文章中，我将深入探讨我们为什么要这么做TiDB，一个开源的mysql兼容的分布式文件混合事务/分析处理（HTAP）数据库，对一些其他MySQL为基础，NewSQL的存储解决方案。我将介绍我们是如何测试TiDB打击竞争对手，为什么TiDB赢了，我们现在是如何使用它。

我们的痛苦点

在本节中，我将介绍用于账单应用程序的MySQL体系结构以及我们确定的瓶颈。您将看到,数据库的可扩展性和数据隔离是我们的两个主要痛点。

我们的应用程序的MySQL架构

我们部署了10多个计费应用程序，为不同的游戏产品提供服务。一个大产品使用一个专用的计费应用程序，而多个小产品共享同一个应用程序。每个计费应用程序都应用独立的MySQL体系结构，如下所示。(箭头方向表示数据或请求的流向。)

该建筑具有以下特点:

• 负载均衡

  每个账单应用程序通过部署在多台机器上Keepalived，因此流量是负载均衡的。这保证了应用程序服务的高可用性。

• MySQL伯仲结构

  数据库层采用MySQL主从结构。它的半同步复制允许将来自一个MySQL服务器(主实例)的数据自动复制到一个或多个MySQL服务器(辅助实例)。该特性解决了延迟和一致性问题。

• 故障转移

  计费应用通过虚拟IP地址(VIP)访问后端数据库。如果主实例关闭，应用服务将自动通过VIP转移到从实例，以确保该服务不受影响。

• 数据备份

  通过主从半同步复制，辅助从在线计费应用程序收集数据。然后，它通过完全复制和增量复制将数据文件转储到数据仓库。在线和离线计算任务都在那里执行。

像这样的MySQL主从结构有50多个，涉及200~400台服务器。每天都要插入千兆字节的数据。

瓶颈

随着我们应用程序的流量和数据量的快速增长，我们的独立MySQL方法遇到了以下瓶颈:

• 容量

  一个独立的MySQL实例存储空间有限。为了维护现有的架构，我们必须删除和旋转旧数据以释放空间。

  例如，单台存储超过700 GB的数据，因为我们需要坚持游戏用户的购买订单。随着越来越多的用户跳跃，生成的数据激增，而独立的MySQL实例将达到其存储限制。

• 表现

  我们唯一的最大的MySQL表存储1.5十亿行数据。有了这样一个大量的行，读取和写入性能受到严重影响。

  当我们持久化购买订单的数据时，我们还必须确保在线用户能够实时查询数据。独立的MySQL服务器无法提供令人满意的查询性能。

• 可扩展性

  MySQL无法在保持在线的情况下弹性伸缩，因此容量瓶颈无法轻易解决。

• SQL语句的复杂性

  旋转意味着从它较旧的数据移动到一个新创建的子表一大桌。它每天的基础上进行的。这将产生需要多个分表，当我们跑联合查询要加入。SQL语句可能过于复杂和难以维护。出于这个原因，这是不容易分析在独立的MySQL架构的大量数据。

• 数据的障碍

  我们为不同的游戏产品独立部署数据库。数据分散在数据竖井中(即数据孤岛)，这使得从数据分析中获得见解变得困难。在进行跨积计算时，我们需要维护多个异构数据源，访问这些数据源的方法非常复杂。

新的数据库探索

在本节中，我将描述理想的数据库对我们的应用程序，以及我们所做的找到它。

应用程序的理想数据库

考虑到我们的计费应用程序与MySQL高度耦合，为了解决我们的问题，我们需要一个新的存储解决方案，具有以下特性:

• 兼容MySQL协议。
• 对于交易任务支持作为交易执行或回滚在错误的情况下。
• 支持索引—特别是二级索引。
• 水平可伸缩性——系统可以在线弹性伸缩，包括性能伸缩和容量扩展。
• 稳定性和可靠性。
• 备份和恢复。
• 容灾。

我们的选择

为了满足上述要求，我们列出了一些可选的解决方案。这些解决方案可以分为两类：基于MySQL的解决方案和基于NewSQL解决方案（CockroachDB和TiDB）。

解决方案	笔记
MySQL分片	基于MySQL的
MySQL InnoDB集群	基于MySQL的
MySQL +维塔斯	基于MySQL的
MYSQL + MyCAT	基于MySQL的
蟑螂db(简称CRDB)	NewSQL
TiDB	NewSQL

测试

MySQL和NewSQL

在开始的时候，我们最好使用基于MySQL的解决方案，如MySQL的InnoDB的集群或MySQL中间件。我们设计了一些测试，以验证每一个解决方案的实用性。

在两个不同版本(5.7.25和8.0.12)的MySQL集群中，我们使用128个并发线程对10个表(每个表有1000万行)进行写操作。对具有单个节点(即独立架构)、三个节点和五个节点的集群运行相同的测试。结果如下:

试验表明，多节点集群的MySQL比独立的MySQL节点执行约30％更差下的写入工作负载。其他读写测试结果相似。

我们测试了与MySQL的中间件解决方案，而这个建筑没有达到我们的预期。综上所述，我们没有采用这些解决方案，或有两个原因MySQL的分片解决方案：

• 演出没有达到我们的要求。
• 迁移到新的应用程序体系结构是复杂的。我们将需要修改大量的应用程序代码。

事实上，MySQL InnoDB集群和MySQL带中间件等解决方案本质上是MySQL主从结构的扩展。它们不是一个真正的分布式系统，但是通过添加“补丁”的方式实现了水平可伸缩性——这就是为什么它们的许多特性没有达到我们的期望。

CockroachDB与TiDB

在分布式NewSQL世界中，TiDB和CockroachDB(简称CRDB)为许多人所熟知，它们都是谷歌Spanner和F1论文的开源实现。我们的研究表明:

• TiDB支持MySQL协议，CRDB支持PostgreSQL协议。
• 如果应用程序是基于MySQL数据库，TiDB可能是一个更好的选择;如果应用程序是基于PostgreSQL, CRDB可能是首选。

我们还对TiDB和CRDB进行了全面测试。例如，在2018年7月，我们创建了两个集群，每个集群有10台机器。每个集群中有5个节点是专用存储节点。我们在一个集群上部署了CRDB 2.1.0，在另一个集群上部署了TiDB 2.0.5。我们使用160个并发线程在一个2亿行的表上执行读写操作。(CRDB和TiDB集群都使用默认配置，没有进行调优。)

下面是我们运行的一些测试语句:

查询类型	测试语句
范围查询	SELECT c FROM sbtest%u WHERE id BETWEEN ?然后呢? SELECT SUM（K）FROM sbtest％U WHERE BETWEEN ID？然后呢? SELECT c FROM sbtest WHERE id BETWEEN ?然后呢?ORDER BY c SELECT DISTINCT c FROM sbtest%u WHERE id BETWEEN ?然后呢?ORDER BY c
随机的查询	SELECT id, k, c, pad FROM sbtest1 WHERE k IN (?)
随机范围查询	SELECT COUNT（K）FROM sbtest1其中K BETWEEN？然后呢?OR K之间？然后呢?
更新索引列	UPDATE sbtest％U SET K = K + 1 WHERE ID =？
更新非索引列	UPDATE sbtest％U盘C =？WHERE ID =？
混合读写	范围查询+创建/删除/更新查询

下图显示了我们的一个重要测试结果:一般来说，CRDB 2.1.0和TiDB 2.0.5在大多数读和写工作负载中具有相似的性能。

结论：

• CRDB和TiDB是在性能上媲美。

  注:以上是TiDB 2.0.5的测试结果。2019年7月，PingCAP宣布TiDB 3.0达到了通用可用性，实现主要的性能提升。我们最近的测试表明，在大多数情况下，TiDB 3.0的性能要比TiDB 2.1好好几倍。下面对比TiDB 3.0.3和TiDB 2.1.15在峰值区域的测试结果联机事务处理（OLTP）和TPC基准C（TPC-C）：

• CRDB兼容PostgreSQL协议。如果我们将应用程序架构迁移到CRDB，我们必须更改协议，这是复杂和昂贵的。

• TiDB是与MySQL协议，这意味着几个代码的修改和低的迁移成本兼容。

选择TiDB

最后，是时候做决定了。对于讨论中的每个解决方案，我们评估了对我们来说最重要的因素:

解决方案	可扩展性	oltp.	OLAP	开源
MySQL分片	没有	是的	没有	是的
MySQL InnoDB集群	没有	是的	是的	是的
MySQL +维塔斯	没有	是的	没有	是的
MYSQL + MyCAT	是的	是的	没有	是的
CockroachDB (CRDB)	是的	是的	是的	CCL声波测井和
TiDB	是的	是的	是的	是的

TiDB似乎比其他公司有竞争优势。然后，我们列出了TiDB授权我们做的事情:

• MySQL的兼容性将应用程序迁移工作和成本。

  TiDB是与MySQL和支持索引（包括二级指标）和ACID事务高度兼容。它还具有的工具，作为一个生态系统同步和TiDB数据迁移(TiDB DM)从MySQL无缝迁移。

• 横向可扩展性带来了大容量存储和较低的运行成本。

  TiDB通过添加新节点来扩展存储。数据库可以在不使任何节点离线的情况下实时弹性扩展。这使得我们的基础设施容量规划比只能垂直扩展的传统关系数据库更容易，更划算。此外，我们的数据库管理员终于摆脱了经常从MySQL中清除旧数据的苦差事。

• 水平可伸缩性使数据存储在大型数据库池和大数据挖掘成为可能。

  水平可伸缩性，确保在TiDB大容量存储。这使我们不同的游戏产品的数据存储在同一个数据库池。这消除了数据的障碍，是业务分析非常重要。

• 不需要分片。

  TiDB支持对超大表的高效读写。

• 无状态的计算引擎保证每秒（QPS）性能高的查询。

  TiDB服务器作为计算层，是无状态的，支持多节点读写。只要存储层的功率不低，通过添加新的TiDB服务器来增加QPS是很容易的。

• 的筏共识算法确保高可用性和强一致性。

  TiDB采用筏一致性算法，以确保数据在筏组复制到多个副本整个储存。如果一个节点出现故障，筏组会自动为选举失败的成员和自我愈合的TiDB集群新的领导人。因此，一个节点故障不影响应用服务。

• TiDB的工具生态系统简化了数据备份和恢复。

  您可以跨数据中心或跨地区部署TiDB。我们可以使用Mydumper和装载机多线程并发地导出和恢复数据。TiDB也有tidb binlog.工具，其收集到一个TiDB簇进行的逻辑上的改变，并提供增量备份和复制到下游（TiDB，卡夫卡或MySQL）。

就我们而言，TiDB是适合我们的场景的最具成本效益的解决方案，我们想尝试一下!

使用TiDB为我们的应用程序

在我们使用TiDB的整个过程中，我们使用了多个版本进行测试或生产，包括版本1.0、2.0.5、2.0.11、2.1.5、2.1.15和3.0.3。我们见证了TiDB多年来取得的巨大进步。在本节中，我将描述我们目前如何将TiDB用于我们的计费应用程序。

TiDB架构

我们在一个高度层结构部署TiDB集群如下图所示。nginx.用于前端负载均衡。

在TiDB集群中，有三个主要组件:

• TiDB服务器是一个无状态SQL层，处理SQL请求，从存储层访问数据，并将计算结果返回给应用程序。它是mysql兼容的，并位于TiKV之上。

• TiKV服务器是分布式事务键值存储层，数据将在该层保存。它使用Raft共识协议来确保数据有多个副本，并且在某个节点故障时不会丢失。

• PD (Placement Driver)服务器元数据集群是由ettd.管理和调度TiKV节点。

TiDB使用情况

应用场景

• TiDB镜子MySQL数据库在生产环境中。TiDB收集来自在线MySQL数据库的数据，组装成数据池，以及集中管理数据。

• TiDB支持数据平台服务，包括报表、监控、操作、生成用户配置文件、计算大数据等。

• 同时涉及OLTP和在线分析处理(OLAP)工作负载。

集群

• 在我们的测试环境中，我们使用TiDB 3.0.3集群来评估新特性。

• 在我们的生产环境中，我们也有一个TiDB 3.0.3集群，它服务于两种类型的工作负载:80%是离线大数据计算，而另外20%是在线服务。

规模

环境	41个服务器 88个实例 38 Syncer实时复制流(将升级到TiDB数据迁移）
存储	20tb数据(总共50tb) 230万个地区
表现	4 k/s平均QPS 峰值10 k/s QPS(持续4小时) 1：5的读/写比
延迟	下面8毫秒的等待时间的80％的 低于125毫秒的等待时间的95％的 99.9%的延迟低于500毫秒

结论

在这篇文章中，我讨论了我们为什么要为我们的计费应用程序采用新的存储解决方案，以及为什么我们选择TiDB而不是其他替代方案。我们目前使用TiDB的成功使我们有信心在未来将更多的服务转移到TiDB。这种向外扩展的分布式SQL数据库使我们能够从数据中获得洞察，并为用户创造价值。

在下一篇文章中，我将分享一些关于如何将应用程序从MySQL迁移到TiDB的第一手经验，以及如何管理和维护TiDB集群。请继续关注。