TiDB x 虎牙直播 | 从容应对亿级用户游戏直播场景

业务挑战

直播平台需要存储大量视频、图片、私信以及人员登录等信息，同时要求信息可灵活地被程序调用，数据库在其中起到了非常核心的作用。历史上，虎牙直播使用的数据库产品以 MySQL 为主体，并使用 Redis 作为缓存，同时在某些业务场景使用 Mongo 集群提供服务。对数据库有着较高的性能、扩展性及高可用要求：

性能： 在游戏决赛、季赛等高并发场景下，直播在线业务的数据库对性能有着较高要求，虎牙希望数据库在 OLTP 侧可以降低直播延迟，更高效地进行响应，在面对高并发流量时，能够快速扩容，满足直播对于读写的扩展性要求。同时，虎牙希望数据库能够有一个一体化的 HTAP 架构，来高效满足各种复杂查询和实时应用需求。

扩展性： 虎牙直播平台上有订单、私信、秩序、点播、支付等业务，其中不少实例数据量都在 1TB 以上，为了解决数据扩展性，虎牙在过去主要采用 MySQL 分库分表的方式来解决数据存储扩展问题。但这种方法对业务存在一定侵入性，随着数据继续增长，还需要做二次或多次拆分，业务改造成本及整体运维成本不断增高。

高可用： 直播业务对延迟和持续服务有着严苛要求，这将直接影响着用户的流畅体验。虎牙直播要求整个数据库可用性需要达到 99.99%，为此虎牙采用了同城多 AZ 容灾与异地容灾方案保障数据库高可用需求。

数据强一致： 直播时如果用户非常喜欢某个主播，经常会给主播送出大量虚拟礼物，这意味着虎牙直播业务中也包含了支付等金融业务场景，该场景要求数据库需具备金融级数据强一致性。过去，虎牙主要基于 MySQL 做数据库的读写分离，这会导致业务面临数据一致性问题，虽然可以通过代理中间件的方法解决，但并没有达到支付业务对于数据一致性的要求。

成本： 随着业务的不断发展，通过同城 AZ 容灾和异地容灾部署的集群规模不断上涨，这也导致数据存储成本急剧翻倍。虎牙希望保持数据库稳定的同时，能够有效控制总体成本。

为什么选择 TiDB？

在对主流数据库进行选型测试后，虎牙直播在 2019 年开始引入 TiDB 分布式数据库，最开始从一些非核心业务开始试点应用。虎牙直播数据库负责人黄华亮表示，经过 6 年发展的 TiDB 已经是一个比较成熟完善的产品，其扩展性、兼容 MySQL 协议、数据强一致性、HTAP 等特性能够完美解决虎牙直播面临的业务挑战。尤其在 TiDB 5.0 发布之后，TiDB 在许多企业级特性方面都有巨大提升。

解决方案

虎牙直播以前的数据存储以 MySQL 为主，引入 TiDB 前需要按天分表，同时按照一定策略保留数据，定期删除历史数据，这使得虎牙的离线数据存储成本较高。TiDB 在开启高压缩时，即使采用默认的三副本，其存储成本也比采用双副本的 MySQL 更低。同时，TiDB 具有丰富的开放生态，运维操作非常简便，支持一键扩容、自动高可用、无锁DDL 等功能，在大多数场景下有着使用成本的绝对优势，TiDB 的引入顺利解决了虎牙的成本问题。

在尝到甜头后，虎牙直播核心大数据平台也开始使用 TiDB。在此之前， MySQL 的 ETL 场景中一些表数据规模过亿，当分 6-7 张表进行 join 查询时，部分查询耗时甚至超过一分钟。迁移到 TiDB 后，从原先平均耗时 14s 下降到 2s，查询速度提升了七倍之多。

作为直播平台，虎牙的核心场景是视频业务，对数据库的要求特点为写少读多。但 MySQL 的读取性能不高，同时存在数据扩展性难题，虎牙不得不面临分库分表的选择。为了解决该问题，虎牙直播的业务架构从 MySQL 的一主多从架构迁移到 TiDB + TiFlash 架构。TiDB 的分布式架构支持一键式扩缩容，并且整个过程对应用完全透明，业务无感知，可以更好地应对虎牙直播扩展性需求。不仅如此，通过使用 TiFlash，虎牙整体查询性能提升超过 2 倍多。

此外，虎牙的直播打赏业务对于数据有强一致性要求。虎牙直播当前数据库架构采用了同城 3AZ 的 MGR 集群，并通过专线同步到异地实现容灾。但是目前遇到性能、成本等问题，未来计划尝试 TiDB 通过 Multi Raft 保证数据的强一致性，可以满足同城跨 AZ 及异地多 AZ 容灾下的数据强一致。