TiDB 在虎牙直播的应用与实践

业务挑战主要来自于三大点。

虎牙直播在 2019 年的八、九月份才开始使用第一个 TiDB 集群，当时使用的是 3.0 版本。最开始是在一些非核心业务上试点引入 TiDB，来解决虎牙直播的可扩展性问题以及满足虎牙直播对于 OLAP 业务的一些复杂查询的快速响应需求。

当时的业务特性是按天分表，同时按照一定的策略去保留数据，并且定期删除历史数据。同时，业务也有一些需要做数据统计分析的 OLAP 场景。面临的问题在于：

• 第一，离线数据的存储成本较高。

• 第二，虎牙直播的离线分析的时效性不高，整体的查询性能不强，不能很好地满足业务的需求。

在引入 TiDB 后，存储的成本降低了，第一个问题顺利解决。针对第二个问题，虎牙直播通过 MySQL 将上游数据同步到 TiDB，然后 TiDB 负责虎牙直播的 OLTP 的场景。同时，复制一份数据列式存储到 TiFlash 里面，通过这种方式满足了实时查询的需求。

这样做的目的，一是能够减少因为分库分表而增加的业务复杂度。二是虎牙直播现在在一套集群上面就可以实现 OLTP 与 OLAP 的混合应用场景，更加方便。

在尝到甜头之后，虎牙直播核心的大数据平台也开始使用 TiDB。

在此之前，由于一些老框架的存在，比如 Oracle 的 ETL 场景，一些表数据规模过亿，当分 6~7 张表 join 进行查询的时候，返回的数据行可以到百万级，部分查询甚至每次耗时超过一分钟。

从 MySQL 迁移到 TiDB 后，原先使用的 MySQL 平均耗时 14s，使用 TiDB 后平均耗时下降到 2s，查询的速度提升了七倍。

MGR 指多点写，由于多个节点的数据写入冲突导致的大量事务回滚，产生比较大的 TPS 和延时的抖动，所以只适合写入非常少，主要是读负载的场景。

受限于每个节点的数据处理能力，而单节点的能力又受限于服务器节点的计算资源以及硬件成本等，并不能持续增加其数据存储和处理能力。因此，当数据规模增大到一定程度之后，还是需要使用分布式数据库集群。

在直播打赏业务方面，虎牙直播对于数据有强制性要求。当前的业务架构是采用同城的三个集群，通过专线同步，实现异地容灾。然后在应用中接入 MGR 集群。通过 zk 集群，统一地把 MGR 集群配置推送到 zk 集群。在应用侧，虎牙直播有一个探测程序，每 5 秒探测一次，探测 zk 集群的配置有无发生变更。同时有一个推送配置，当 MGR 发生了主动切换，zk 也会主动将其推送给 Client，这种方式导致业务接入成本较高。MGR 虽然一定程度上能解决数据强一致问题，但是虎牙直播现在采用的是单点写入的方式，因为多点写可能会面临因 DDL、DML 冲突而导致的数据出错问题。

另外，虎牙直播的 MGR 集群还面临着需要分库分表进行拆分的数据扩展性问题，影响数据做 merge 统计。MGR 对整体的网络时延要求比较高，所以不异地部署统一的 MGR 集群，因为网络时延或者网络抖动等可能会导致 MGR 频繁切换和集群整体性能降低。

• truncate partition：多个线程并发执行 truncate 同一张表，都通过校验，进入 DDL 队列，基于 FIFO (First In , First Out) 的原则，session 1 的 truncate 执行成功，这时候 partitionID 变了，然后 session 2 执行同样的 truncate 操作的时候就找不到这个 partitionID 了， session 2 的 DDL 被 block 住，后面的 DDL 也就全部被 block 住。
• truncate table：与 truncate partition 同理，不同的地方是 partitionID 换成 tableID。

问题：使用 TiDB 3.0，业务中有定时的批量 insert 语句触发，Raft apply 线程短时间需要处理大量 raft 日志，apply log 过程速度过慢

版本：TiDB 3.0、4.0

优化措施：

• 设置合理的 block-cache。

• 升级到 4.x 版本。

问题：无索引的大查询把 TiKV 机器网卡出口带宽跑满的场景

版本：TiDB 3.0、4.0

1）优化措施：优化慢查询。

2）防御措施：

慢查询很多是线上已经 running 状态，为了防止慢查询产生的一系列不良后果，可以限制单条 SQL 的最大内存消耗，限制单条 SQL 的最大执行时间，限制整个实例的最大使用内存，参数如下： 

• tidb_mem_quota_query 限制单个 SQL 的内存消耗

• max_execution_time 限制单个 SQL 执行时间

• max-memory 或 server-memory-quota 限制实例的总内存

      1）限制单条 SQL 最大内存配置：

       global: mem-quota-query: 209715200 

       oom-action: “cancel”    

       oom-use-tmp-storage=true

     2）限制单条 SQL 最大执行时间配置：

      set @@GLOBAL.max_execution_time=10000;

在直播的业务场景下，虎牙直播希望能够有什么样的分布式数据库呢？

• 首先，TiDB 采用 raft 协议，多副本多复制。能否采取一些措施减少数据节点的成本？因为虎牙直播很多业务场景对于数据的一致性要求不是那么高，而对数据整体的可用性要求比较高。这样可以降低整体数据库的部署成本。
• 其次，数据库的数据流应该可以做到自动冷热分离，热数据放在内存里面，冷数据放到硬盘里面。未来虎牙直播如果在云上部署，存储成本就更低了。
• 第三，虎牙直播还希望 TiDB 和 TiFlash 能够相互独立。比如一些纯 AP 的业务可以直接放到 TiFlash，而不需要上游去依赖 TiDB，这样可以降低整体的成本。
• 最后，TiDB 还可以考虑支持主流公有云的容器化。