共计 3650 个字符，预计需要花费 10 分钟才能阅读完成。
作者介绍： 李文杰，网易互娱高级数据库工程师，TUG 2019 年度和 2020 年度 MVA。次要负责大数据研发和数据分析工作，为产品提供精细化经营领导；同时在部门内推广应用 TiDB，为业务上云及数据库分布式化积攒教训和摸索最优计划，目前是 TiDB 治理小组负责人。
本文整顿自 TUG 网易线上企业行流动，由网易游戏高级数据库工程师李文杰老师分享，次要介绍分布式数据库 TiDB 在网易游戏的利用实践经验。
网易游戏最开始引入 TiDB 是从 AP 的角度来进行应用的。在第一次应用 TiDB 时，咱们把跑批业务这种计算量比拟大的工作迁徙到 TiDB 下面。在迁徙过程中，如果跑的任务量比拟大，置信很多人会遇到“transaction too large”报错这个问题。
TiDB 事务限度
通过一番排查发现，因为分布式事务要做两阶段提交，并且底层还须要做 Raft 复制，如果一个事务十分大，会使得提交过程十分慢，并且会卡住上面的 Raft 复制流程。为了防止零碎呈现被卡住的状况，TiDB 对事务的大小做了限度，具体限度的内容有单事务的 SQL 语句数、KV 键值对数目和大小、单 KV 键值对大小等。
晓得这个限度后，咱们就能够找到了解决办法，即 把大的事务按业务的需要切分为多个小事务分批执行，这样之前跑失败的 SQL 就能胜利运行了，而且在 MySQL/Oracle 中的跑批程序，也都胜利迁徙到了 TiDB。
同时，咱们不得不思考，在没有问题的时候，程序能够跑得十分顺畅，然而当机房中呈现网络问题，或是呈现其余的故障时，就会呈现一部分数据写入到了 TiDB 中，而另外一部分数据是没有写入的。在场景中的体现是一个事务的执行没有可能保障其原子性，只执行了其中一部分，有一部分胜利，有一部分失败了。
经排查发现，这是因为咱们手动开启了事务切分，这种状况下大事务的原子性就无奈保障，只能保障每个批次的小事务原子性，从整个工作的全局角度来看，数据呈现了不统一。
那么该如何解决这个问题呢？
TiDB 大事务优化
通过向官网反馈问题之后，TiDB 4.0 对大事务进行了深度优化，不仅勾销了一些限度，而且将单事务大小从 100MB 间接放宽限度到 10GB，间接优化了 100 倍。但与此同时也带来了另一个问题，在进行 t+1 的跑批业务时，前一天可能会有几百甚至上千万的数据量，如果用程序 JDBC+TiDB 形式解决，效率其实不高，解决时长往往须要继续数小时，甚至几十小时以上。
那么该如何进步计算工作的整体吞吐量？答案是 TiSpark。
TiSpark：高效解决简单 OLAP 计算
TiSpark 是在 Spark 根底上开发的一个插件，它能够高效地从 TiKV 读取数据。同时反对索引查找和计算下推策略，有很高的查问性能。咱们在实际过程发现，应用 TiSpark 读取 TiKV 的形式，5 分钟能够实现 2 亿行数据读取。同时它也有很高的写入性能。有了 TiSpark，咱们能够间接通过 Spark 工具拜访 TiKV 数据。通过工夫证实，TiSpark 读、写 TiKV 都有着十分好的性能体现，通过 TiSpark 咱们能够解决比较复杂、数据量比拟大的运算。
TiSpark 实际
在实践中，应用 TiSpark 次要有两种形式：
- 形式一：TiSpark + JDBC 写入
TiSpark + JDBC 写入形式可能主动切分大事务，但不肯定能保障事务的原子性和隔离性，且故障复原时须要人工染指。这种形式写入速度能够达到 180 万行 /min，通过 TiDB 解决 SQL 再写入 TiKV，速度个别。
- 形式二：TiSpark 批量写入 TiKV
TiSpark 批量写入 TiKV 不会主动切分大事务。通过 TiSpark 间接读写 TiKV，相当于间接通过大事务读写 TiKV 的数据，能够保障事务的原子性和隔离性，同时领有良好的写入性能，写入速度能够达到 300 万行 /min。通过 TiSpark 的利用，解决了咱们大数据量批处理工作的问题，然而也存在肯定的隐患。TiSpark 在进行读、写 TiKV 的时候，因为 TiKV 是作为整个 TiDB 架构的存储引擎，如果存储引擎层的数据读写压力大，对于线上的其余业务将会产生显著的影响。此外，在 TiSpark 读写 TiKV 时，如果没有对 IO 进行限度，很容引发性能抖动，导致拜访提早回升，也会对其余线上业务产生影响。
怎么样才能够做到无效隔离? 或者 TiFlash 列式存储引擎能提供答案。
TiFlash：列式存储引擎
TiFlash 作为 TiKV 行式存储引擎的补充，它是 TiKV 数据的 raft 正本，TiFlash 作为在 TiKV 根底上的列式正本，通过 raft 协定保证数据同步的一致性和完整性。这样同样的一份数据就能够存储在两个存储引擎外面。TiKV 保留的是行存数据，TiFlash 保留的是列式数据。
在做 Spark 的计算剖析时，咱们能够间接从 TiFlash 集群进行读取，计算效率会十分高。用列式数据做 AP 剖析，对于行式数据来说，几乎就是降维打击。
TiFlash：TPC-H 性能剖析
TiSpark + TiFlash 的联合利用使计算效率获得了量与质的晋升。TPC-H 性能剖析显示，在与 TiKV 的横向比照中，简直全副 query 场景下 TiFlash 执行效率都高于 TiKV，且局部场景的效率远高于 TiKV。用了 TiFlash 当前，既不影响 TiKV 的集群性能，也不影响线下的集群业务，而且在做离线大数据分析时，仍然可能放弃很好的性能与吞吐量。
通过实践证明，TiFlash 能够解决咱们的诸多问题，是十分棒的一个工具。
TiFlash 利用：计算更高效
在网易游戏用户画像的局部指标计算场景中，应用上 TiSpark + TiFlash 后，不同业务内容的 SQL 处理速度相比 TiSpark + TiKV 快了至多 4 倍。所以应用 TiFlash 之后，离线批处理效率有了质的晋升。
JSpark：跨源离线计算
随着业务规模和利用场景的减少，不同数据分布存储在不同的存储引擎。比方日志数据存储在 Hive，数据库数据存储在 TiDB，跨数据源拜访须要大量数据迁徙，耗时且费劲。是否间接买通不同数据源，实现跨源互访？针对这个问题网易游戏采纳了 JSpark 工具。JSaprk 是为了买通底层不同存储，实现跨源拜访指标而实现的一个离线计算工具。这个工具外围是 TiSpark + Spark 组件，Spark 作为桥梁，能够实现不同数据源的拜访。
JSpark 基于 TiSpark 和 JDBC 进行封装，在 TiKV 能够进行数据读写，在 TiFlash 能够进行列式 AP 计算，在 TiDB 能够做惯例的 SQL 计算，目前咱们曾经封装实现了 TiDB 和 Hive 的互相读写性能，后续 JSpark 工具将会反对 TiDB 与 ES 的读写互访，实现 TiDB、Hive、ES 多源数据拜访。
目前 JSpark 工具，次要是实现了以下性能：
反对 TiSpark+JDBC 形式读写 TiDB 和读写 Hive，这种形式效率个别。
- 利用场景：在 TiDB 宽表中只操作业务须要的局部列。
反对读 TiDB 表数据，Spark 计算结果写入 Hive 指标表。读举荐应用 TiSpark 读取 TiKV 或 TiFlash 的形式，写举荐应用 TiSpark 写入 TiKV 的形式，效率会更高。
- 利用场景：定期轮转 TiDB 分区表过期分区，备份永恒保留正本到 Hive，防止 TiDB 表过大。
反对读 Hive 表数据，Spark 计算结果写入 TiDB 指标表。举荐应用 TiSpark 写入 TiKV 的形式，效率高。
- 利用场景：剖析 Hive 数据产出用户画像指标并写入线上 TiDB，提供线上业务 TP 查问。另一个实际场景是复原 Hive 备份到 TiDB。
反对前端 web 或业务发动 http 申请，近程启动 Spark 作业，实现底层 TiDB 和 Hive 的联结查问。
- 利用场景：前端治理平台点击查问按钮，获取某玩家 Hive 链路日志和 TiDB 数据的联结聚合后果，提炼出相干行为数据。
咱们在开发和应用 JSpark 相干性能期间，也发现了 TiSpark 的一个可优化点。
目前 TiSpark 不反对同时拜访多个 TiDB 数据源，运行时只能注册一个 TiDB 集群，不能注册多个，这不便于跨 TiDB 集群计算。在将来咱们心愿 TiSpark 能够反对同时拜访多个 TiDB 集群。
TiDB 利用：HTAP 数据体系
JSpark 目前是离线计算的外围框架，除此之外还与 JFlink 实时计算框架相结合，独特组成了大数据处理能力。JSpark 负责离线大数据计算框架，JFlink 负责实时计算框架，两者独特组成了 HTAP 的数据体系。
HTAP 计算能力：JSpark+JFlink
首先，将线上数据实时同步汇总到 TiDB 集群，再依附 JSpark + JFlink 在 TiDB 和其余数据源进行离线和实时计算，产出用户画像等指标剖析数据，反馈线上业务查问。
TiDB 利用：HTAP 数据体系
目前，通过 3 年的倒退，网易游戏的集群总实例数量 170 个，数据规模达到 100 + TB 级别。咱们的业务涵盖用户画像、防沉迷、经营、报表、业务监控等多个方面，并且业务规模和集群规模也在一直倒退和扩充中。
以上就是网易游戏在应用 TiDB 的过程中，对于 AP 计算演进的过程，心愿明天的分享能够对大家有所启发。
