作者介绍
黄华亮 @Hacker_9rFJpXrg，虎牙直播数据库团队负责人&架构师，负责虎牙数据库维护和数据库团队的管理工作，推进高可用架构演进、数据库服务平台化、运维效率与运维质量提升、成本优化等，对数据库多业务场景架构设计、高并发解决方案、数据生态管控有着丰富的实践经验，对数据库库中间件、分布式数据库有一定的积累。
本文整理自虎牙直播数据库负责人黄华亮在 TUG 企业行——走进网易活动的演讲。本次的分享主要从业务背景、业务挑战、技术架构选型、业务场景应用与实践、常见的问题与未来规划 6 个部分分享。
演讲实录： [TUG 网易线上企业行] TiDB 在虎牙直播的应用与实践_哔哩哔哩_bilibili
业务背景
虎牙直播在 2014 年从 YY 直播分离，开始独立运营。2016 年的战略是 ALL IN 移动端游戏直播，2018 年在纽交所上市，2019年搬到番禺区新总部，2020 年接受腾讯投资，腾讯成为虎牙直播控股股东。
虎牙直播公司主要有两个产品。国内主打虎牙直播应用，主要做电竞直播，覆盖 3800 款游戏，月活突破 1.78 亿。在海外主打 Nimo TV，主要在东南亚、南美、中东地区流行，覆盖全球多个国家，月活达 3000 万。
虎牙直播的数据库产品以 MySQL 为主体，使用 Redis 缓存，同时在某些业务场景使用 MongoDB 集群提供服务，下面跟大家分享一下虎牙直播业务在数据库上当前存在的问题和现状。
-
扩展性要求 。虎牙直播在订单、私信、秩序、点播、支付等业务上，有不少 1T 以上的实例，这会导致数据扩展性可能产生一些问题。虎牙直播在历史上主要采用结合业务做 MySQL 分表的方式来解决数据存储的扩展性问题。
-
高可用要求 。虎牙直播要求整个数据库的可用性达到 99.99%，为了达到如此高的可用性，虎牙直播做了数据库的同城多 AZ 容灾与异地容灾。
-
成本要求 。虎牙直播希望在保持数据库稳定性的同时，能够不断地降低数据库成本。
-
性能要求 。虎牙性能上有两个要求，一个是直播的在线业务，虎牙直播希望在游戏决赛、季赛等高并发的场景下，数据库能够有更好的性能。另外是 OLAP 侧，虎牙直播希望能够更高效地去满足各种复杂查询和实时应用的需求，即需要实现高性能 OLTP 服务业务，传统大数据架构已经很难满足实时数仓等 OLAP 业务对数据库的性能要求。
-
数据一致性要求 。包括了支付等金融业务对数据强一致性的要求(包含异地容灾)。
业务挑战
业务挑战主要来自于三大点。
数据存储的扩展性
之前虎牙直播通过业务侧的拆分来解决这个问题，但是这种方法对业务存在一定的侵入性，同时面临着数据增长之后，需要做二次或多次拆分的问题，业务改造成本以及整体的运维成本就会变得相当高。虎牙直播也可以基于一定的规则做归档，但是这种方式只适用于虎牙直播一些特定的业务场景。
直播的高性能要求
在 OLTP 侧，虎牙直播希望可以降低直播的延迟 ，能够更高效地进行响应，以及面对一些突发流量的时候，能够快速地扩容，满足虎牙直播对于数据写入与读取的扩展性要求。同时，虎牙直播希望能够有一个一体化的 HTAP 的架构，能同时满足业务对 OLAP 的需求。
控制成本
虎牙直播首先做了数据库的读写分离。基于 MySQL 的服务进行读写分离之后，业务会面临数据一致性的问题，有一种方法是通过代理中间件来解决，但是这种方法并没有很好地去解决业务对于数据一致性的要求。
同时，虎牙直播通过集群同城多 AZ 容灾以及多地域的集群部署之后，数据存储成本会急剧的翻倍。
另外，虎牙直播的离线业务数据处理链路比较长，所以整体的维护成本较高，基础设施总体来说也会比较臃肿。
为什么选择 TiDB
虎牙直播业务对于数据库的选型有以下几点考虑：
- 第一，这个数据库必须是 成熟的产品 。从 2017 年 TiDB 1.0 GA 发版到现在的 5.0 版本，TiDB 已经是一个成熟的、愈发完善的数据库。
- 第二，虎牙直播的数据存储以 MySQL 为主，而 TiDB 几乎 99% 兼容 MySQL 协议 ，迁移成本很低，业务的改造压力也比较小。
- 第三，虎牙直播存在 扩展性需求 ，而 TiDB 的 3 层结构支持一键式在线扩容缩容，整个过程对应用完全透明且无影响。同时，TiDB 在业务上比较透明，对业务的感知度很小。
- 第四， 成本优势 。在实践中，TiDB 开启高压缩，采用默认的三副本情况下，存储成本也往往比采用双副本的 MySQL 更低；同时，因为 TiDB 的生态比较丰富，运维操作也比较简便，支持一键扩容、自动高可用、Online DDL 等，在大多数场景下有着使用成本的绝对优势。
- 第五， TiDB 可以保证数据的一致性 。TiDB 用 Multi Raft 保证数据的强一致性，满足同城跨 AZ，异地多 AZ 容灾下的数据强一致。
- 最后一点， 高性能 。TiDB 的存储引擎使用了 LSM-Tree，它将所有的随机写变成了顺序写，可以满足高性能 OLTP 场景。同时，TiSpark+TiFlash+MPP 满足实时、高性能的 OLAP 场景。
业务场景应用与实践
分库分表应用
虎牙直播在 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，查询的速度提升了七倍。
准实时 AP 应用
第三个场景是 虎牙直播与视频业务相关的场景 。这个业务的特性是， 写的少读的多 。还有一个痛点是，业务的读取性能不高，同时存在数据的扩展性难题，面临着未来要做分库分表的需求。
为了解决这些问题，虎牙直播的业务架构从原来使用 MySQL 的一主多从，迁移到现在的 TiDB + TiFlash 架构。
虎牙直播抓取了 9 个场景，做了原来架构和现在的 TiDB 架构的性能对比。整理出来的数据如下图。在换用 TiDB + TiFlash 架构后，不仅解决了数据扩展性的需求，整体的查询性能也提升了超过两倍。
这样一来，便解决了虎牙直播在 AP 上的对于数据查询的性能要求。
MGR 替代方案
MGR 指多点写，由于多个节点的数据写入冲突导致的大量事务回滚，产生比较大的 TPS 和延时的抖动，所以只适合写入非常少，主要是读负载的场景。
受限于每个节点的数据处理能力，而单节点的能力又受限于服务器节点的计算资源以及硬件成本等，并不能持续增加其数据存储和处理能力。因此，当数据规模增大到一定程度之后，还是需要使用分布式数据库集群。
在直播打赏业务方面，虎牙直播对于数据有强制性要求。当前的业务架构是采用同城的三个集群，通过专线同步，实现异地容灾。然后在应用中接入 MGR 集群。通过 zk 集群，统一地把 MGR 集群配置推送到 zk 集群。在应用侧，虎牙直播有一个探测程序，每 5 秒探测一次，探测 zk 集群的配置有无发生变更。同时有一个推送配置，当 MGR 发生了主动切换，zk 也会主动将其推送给 Client，这种方式导致业务接入成本较高。MGR 虽然一定程度上能解决数据强一致问题，但是虎牙直播现在采用的是单点写入的方式，因为多点写可能会面临因 DDL、DML 冲突而导致的数据出错问题。
另外，虎牙直播的 MGR 集群还面临着需要分库分表进行拆分的数据扩展性问题，影响数据做 merge 统计。MGR 对整体的网络时延要求比较高，所以不异地部署统一的 MGR 集群，因为网络时延或者网络抖动等可能会导致 MGR 频繁切换和集群整体性能降低。
除此之外，MGR 在大事务时经常会产生抖动，主要是因为 MGR 没有做好流控。同时，MGR 架构属于数据多副本并且无法压缩的异地部署方式，整体部署成本也会偏高。
而 TiDB 5.0 对于跨机房等方面有做优化，虎牙直播正在尝试将 MGR 方案移植到 TiDB。这样的第一点好处是解决了扩展性的问题，第二点是可以更好地进行流控，比如可以对事务进行一些限制，对于大事务可以在业务侧做一些拆分。另外，虎牙直播的数据库在 Server 本身也可以做一些流量控制。
常见问题
案例：并发 DDL 堵住了后续所有 DDL 的 Bug
描述：并发执行 truncate table 或 truncate partition 堵住了后续所有的 DDL
版本：TiDB 3.0、4.0
原因：
-
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。
案例：TiKV 频繁 OOM
问题：使用 TiDB 3.0，业务中有定时的批量 insert 语句触发，Raft apply 线程短时间需要处理大量 raft 日志，apply log 过程速度过慢
版本：TiDB 3.0、4.0
优化措施：
- 设置合理的 block-cache。
- 升级到 4.x 版本。
案例：TiKV 节点网络带宽被打满
问题：无索引的大查询把 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=true2）限制单条 SQL 最大执行时间配置：
set @@GLOBAL.max_execution_time=10000;
未来规划
TiDB 在虎牙直播的实时 AP、分库分表，以及虎牙直播的大数据应用都已经铺开。
未来，虎牙直播希望 TiDB 能够在保稳的同时，降低虎牙直播的数据库成本。同时，让 TiDB 能够接受更多的业务，比如虎牙直播的 TP 业务，替代现有的数仓产品：Greenplum、ClickHouse 等。虎牙直播希望能够把公司内的 OLTP 与 OLAP 以及多类的数据库产品尽量地去做技术的统一，以降低运维和业务的成本。
同时，架构演进也必不可少。TiDB 5.0 的发布，虎牙直播比较关注的新特性是 MPP 架构、整体性能的提升，以及跨 AZ 跨地域容灾、金融等数据强一致性场景的应用。
另外，虎牙直播也希望可以在低成本的情况下，去尝试 TiDB 产品的容器化。
畅想
在直播的业务场景下，虎牙直播希望能够有什么样的分布式数据库呢？
低成本
-
首先， TiDB 采用 raft 协议，多副本多复制 。能否采取一些措施减少数据节点的成本？因为虎牙直播很多业务场景对于数据的一致性要求不是那么高，而对数据整体的可用性要求比较高。这样可以降低整体数据库的部署成本。
-
其次， 数据库的数据流应该可以做到自动冷热分离 ，热数据放在内存里面，冷数据放到硬盘里面。未来虎牙直播如果在云上部署，存储成本就更低了。
-
第三，虎牙直播还 希望 TiDB 和 TiFlash 能够相互独立 。比如一些纯 AP 的业务可以直接放到 TiFlash，而不需要上游去依赖 TiDB，这样可以降低整体的成本。
-
最后，TiDB 还可以 考虑支持主流公有云的容器化 。
高性能
虎牙直播希望 TiDB 在未来能够支持用户在数据一致性的等级上自主选择。比如支持用户在非强一致性的业务场景下，可以选择弱一致从而提升性能。
极致弹性
直播很多业务场景，比如赛事或者主播生日活动等情况下，可能会有一些预测之外的流量，虎牙直播希望数据库也可以支持整体的快速扩容。比如对于只读副本，能够快速复制多个副本支撑读流量的快速上升。另外，数据能够快速的迁移，快速扩容写入的能力也必不可少。
关于 TUG
TUG（TiDB User Group） 是由 TiDB 用户自发组织、管理的独立社区，PingCAP 官方提供赞助与支持。目前共有华北、华东、华南（广州、深圳）、西南（成都、重庆）、TUG APEC（新加坡）小组。TUG 成立的初衷是“连接用户，共建社区”，汇聚了全球数据库、大数据技术从业者，是一个独立、自发、不以盈利为目的的组织。
如果你对数据库、大数据感兴趣，如果你也想跟业界大咖们一起交流最前沿的数据库与大数据知识，欢迎加入 TUG，和 TUG 一起成长！