共计 4271 个字符，预计需要花费 11 分钟才能阅读完成。
作者介绍： 田维繁，网易游戏资深数据库工程师，TUG 华南区 Co-Leader。数据库老兵，保护过多种数据库，目前在网易游戏负责数据库公有云平台的运维和开发。
在 TUG 网易线上企业行流动中，来自网易游戏的资深数据库工程师田维繁老师分享了 TiDB 海量 region 集群调优主题，以下内容整顿自当天流动分享实录。 此次分享的主题包含三个方面：
- 第一局部是对于网易游戏以及网易游戏目前应用 TiDB 现状；
- 第二局部是 tombstone key 案例分享，包含整个排查过程介绍；
- 第三局部是应用 TiDB 5.0 的初体验以及将来瞻望。
对于咱们
咱们是面向整个网易游戏，提供一站式数据库公有云服务的部门，提供包含 MongoDB、MySQL、Redis、TiDB 等数据库服务。网易游戏 99% 以上的游戏业务都在应用咱们提供的数据库公有云服务。
TiDB 在网易游戏的应用状况如下：整个 TiDB 的集群数量在 50+，TiDB 环境的整体数据规模在 200TB+，最大的集群节点数 25+，包含大部分的 TiKV 以及小局部的 TiFlash 节点，单集群的最大数据量在 25TB+。只管目前 TiDB 属于初步应用阶段，然而也曾经达到了肯定规模，整个业务应用过程中咱们也碰到了诸多问题。
本次分享我筛选了一个 比拟有意思的案例，分享咱们排查的整个过程，也十分冀望大家能从中失去肯定的参考借鉴。
tombstone key 引发的“血案”
咱们分享的案例是 tomstone key 引发的“血案”，可能有的小伙伴们会问 tomstone key 是什么？前面会具体的介绍 tomstone key 的含意。
为什么叫“血案”呢？是因为一想到血案，大家会感觉这个问题的确比较严重。
这个问题过后影响了网易某大型游戏的实时和离线业务剖析场景，导致整个剖析业务不可用，进而影响了外部数据报表零碎的可用性。另外，因为持续时间还较长，游戏的产品经营以及公司的高层也无奈及时地看到游戏数据。
背景
在剖析具体问题前，先简略介绍一下整个业务背景：集群单节点 region 数十分多，TiKV 节点数在 25+，单节点 region 数在 9 万 +。次要业务属于实时剖析型的业务，存在大量的事务型删除和插入操作。
问题现状
上面进入问题案例现场，这个案例从一个电话报警开始。某一天凌晨 4 点，咱们接到了电话报警，确定问题影响之后，第一工夫告诉业务，而后开始问题排查，看看到底是什么引起的报警。
如上图所示，能够看到整个节点的 CPU 是被打满的，此时首先猜想是否因为热点导致了这种景象，个别状况下单个节点 CPU 异样高，都会被认定为是热点问题。为了疾速解决这个问题，咱们临时先把该节点下线，免得导致整个数据库的不可用。后果发现将该节点下线之后，其余的 TiKV 节点也会忽然呈现飙高的状况，即不能通过简略的重启节点来让业务恢复正常。既然是热点问题，那么紧急排查热点迫不及待。首先，热力求的确存在一些热点问题，能够有针对性的找出热点对应的一些表。
其次，通过热力求，以及一些热点的元数据表，锁定大批量的热点表，发现这些表都是联结组建的。这样就比较简单了，间接批量设置一个参数 SHARD\_ROW\_ID_BITS 去打散。
同时，也须要联系业务去发现可能存在的热点表，一起做打散。除此之外，咱们还会监控 hot region 表，如果呈现未打散的表，会设置参数主动打散。并且适当调整 PD 的热点调度并发数，而后加大整个热点的调度，能够疾速解决相似的热点问题。通过一波调整之后，发现 CPU 的确降下来了，拜访业务反馈也失常，好像问题曾经解决了。然而到了第二天，咱们在 10 点钟又收到一波的电话报警，此时的问题在业务上曾经非常紧急，咱们立刻对整个问题进行从新梳理。梳理过程中，咱们回顾了第一次解决的状况，猜想要么第一次解决问题不够彻底，要么基本就不是热点问题导致的。于是咱们回归问题自身进行剖析。既然是 CPU 飙高，咱们首先从 CPU 这个点去排查，排查完之后发现是 storeage readpool CPU 这项指标飙高。
这个指标飙高之前其实没有碰到过，过后也比拟迷茫，所以咱们分割了 TiDB 社区的技术专家：启斌、启航以及跃跃，在线反对。
通过日志，以及一些其余的指标：包含 seek duration 以及 Batch Get 等，锁定了是 seek tombstone key 引起的问题。
回到最开始的问题，什么是 tombstone key ? 这里也简略介绍一下。
个别删完数据之后，TiDB 中会保留多版本数据，即在新插入数据笼罩老数据时，老数据不会马上被清理掉，而是和新数据一起保留，同时以工夫戳来辨别多版本。这些多版本数据什么时候被删除清理掉呢？ 此时有一个 GC 线程，GC 线程会通过后盾去遍历，遍历超过 GC 工夫的一些 key。而后将这些 key 标记为 tombstone key。这些 key 其实只是做一个标记，即所谓的 tombstone key。这些 key 的清理是由 RocksDB 引擎后盾发动一个线程以 Compaction 的形式来进行回收。RocksDB 整个 Compaction 过程 这里也简略介绍一下。首先数据插入 RocksDB 之后，会写入 WAL，而后正式的写入 memory table 的内存块。当内存块写满之后，咱们会把它标记为 immutable member table。
标记完之后，RocksDB 会把内存块 flush 到磁盘，生成一个 SST 文件，这就是咱们的所谓的 level 0 层。
当 level 0 层 SST 文件越来越多时，就会呈现大量的反复数据，也即 tombstone key 会开始呈现在这一层，此时 RocksDB 就会通过 compaction 的形式，将这些 SST 合并到 level 1 层。
当 level 1 层文件达到肯定预值之后，又会合并到 level 2 层，这就是整个 RocksDB compaction 过程的简略形容。
到这里，整个问题简直确认了起因。
故障产生前业务删除过大量的数据，也即在存在大量 tombstone key。在这种状况下执行大量事务，TiKV 就可能会 seek 到大量的被删掉的 tombstone key。因为须要跳过这些 tombstone key，所以可能会导致 batch get 的性能重大降落，进而影响整个 Storage ReadPool CPU 飙高，使整个节点卡住。
这里须要回顾一下，第一次解决问题的时候，咱们通过热点打散之后，整个问题好像就复原了？
为什么过后咱们热点打散之后问题就复原了？其实咱们也做一个回顾，过后发现在打散热点的时候，的确对整个问题有了肯定的缓解，最根本原因在于解决的过程中，RocksDB 对底层的 tombstone key 做了一个 compaction，导致 tombstone key 隐没了，所以问题失去了复原。
确定问题之后，下一步就是怎么样去优化，彻底解决这个问题。为此，咱们制订了一些优化的措施。
如何优化
- 业务侧
首先，分区表革新。某些场景如：业务在补数据时能够按天间接删除分区，TiDB 就会走疾速的 Delete Ranges 而不必等 compaction。
其次，防止热点问题。业务读申请改为 follower read 形式，创立表指定打散个性，缓解读写热点问题，肯定水平上缓解了 seek tombstone key 的影响。
第三，尽可能拆分大事务。事务过大，对整个 TiKV 层，都会造成比拟大压力；事务过大时，须要操作大量的 key，更容易触发 tombstone key。
在业务层做一些优化计划之后，在运维侧咱们也去做了一些解决的计划或者优化的计划。
- 运维侧
首先，手工 compaction。问题产生时，能够紧急下掉有问题的 TiKV 节点，手工进行 compaction 后，从新接入。其次，热点表打散。建设主动监控机制来监控集群热点表状况，依据热点类型以及表类型设置主动打散。第三，更欠缺的沟通渠道。建设与官网的对立沟通渠道，针对 TiDB 相干问题实时沟通，同时也会不定期的组织一些线下交流活动。
- 彻底优化思路
其实这个问题最好的计划是从数据库层做一个彻底的优化，从上述介绍中，思路应该是比拟明了的。
存在 tombstone key 的场景下，写操作或者是 Batch Get，只有绕过这些 tombstone key 从而防止 seek 过多的 tombstone key，就能够很彻底地防止这个问题。此外，相干的优化计划，官网曾经合并到了 TiDB 5.0，并且在 4.0.12 版本也做了一个优化。
TiDB 5.0 初体验
咱们十分期待 5.0 的到来。所以在 5.0 公布之后也第一工夫做了一些相干测试。这里针对一些测试案例，简略地跟小伙伴们分享一下。
TiDB 5.0 测试体验
- 稳定性
首先是 稳定性，因为咱们是 4.0 或者 4.0 之前的版本，或多或少都会碰到一些问题，比方在高并发的状况下呈现性能抖动，这个问题也始终困扰着咱们，咱们在测试的时候发现 TiDB 4.0.12，在高并发状况下，整个 duration 还有 QPS 都是有肯定的稳定的。
通过比照测试 5.0，发现整个 duration 和 QPS 是比较稳定的，甚至简直看到是一条稳固的直线。
- MPP
5.0 也开发了一些新个性，咱们对一些新个性比拟感兴趣，所以也做了一些测试。
比方两阶段提交，能够看到在测试过程中关上异步提交之后，整体的插入性能 TPS 晋升了 33%，延时响应升高了 37%，相较之前有比拟大的晋升。
提到 5.0，不得不提到一个 5.0 个性的重头戏，也就是 MPP 个性，这也是咱们比拟关注的。
对此，咱们做了很多的测试，包含基准测试和一些其余的单 SQL 测试。
这里我想跟大家分享一个实在的数据库场景测试案例。测试的 MySQL 大略有 6T 的数据，咱们跟 TiDB 5.0 的 MPP 做了性能比照，后果发现 MPP 在 5.0 单个 TiFlash 状况下，大多数时候比 MySQL 的性能好并且很多，甚至有些会比 MySQL 性能好十几倍。
如果有多个 TiFlash，在应用 MPP 个性之后，性能会更佳。通过测试，咱们对 5.0 充斥了信念。
TiDB 5.0 将来可期
接下来咱们会去推动 5.0 的落地，比方一些实时业务剖析的场景，同时也会主推一些大数据场景在 TiDB 5.0 的落地。除此之外，推动 TP 型的业务在 TiKV 5.0 的落地也在咱们的打算之中。
对于整个数据库的公有云服务而言，咱们在整个 TiDB 建设过程中，做了很多周边的生态，比方数据库迁徙、对立监控平台，还有一些自动化的创立、增加等等。后续咱们会持续欠缺整个 TiDB 的生态建设，使 TiDB 能更好的在整个网易游戏的云服务落地，同时解决咱们业务的后顾之忧。在应用过程中，咱们也失去了 TUG 小伙伴们的大力支持。所以咱们在获取 TUG 社区反对的同时，也会去深度参加整个 TUG 社区的建设，共建整个 TUG 社区。
