TiDB x Bilibili | “一键三连”背后的数据库

与国内其他视频网站定位不同，B 站主要围绕用户、创作者和内容，构建了一个源源不断产生优质内容的生态系统。许多优秀的专业视频创作者都聚集在 B 站创作内容，涵盖生活、游戏、时尚、知识、音乐等数千个品类和圈层，引领着流行文化的风潮。

十多年过去，从最初的二次元弹幕视频网站发展到现在的综合性视频社区，B 站的规模日益扩大，业务场景主要包含点播类业务、直播类业务、电商类业务、游戏类业务。每种场景对数据库等底层 IT 架构都提出了不同的需求，如点播对可用性要求比较高，直播是高并发场景，存在大量热点数据，电商则要求数据强一致性，游戏对性能要求比较高，这也对 B 站的 IT 架构提出了更多挑战。

业务挑战

2018 年后，B 站每个季度用户都在以百分之七八十的比例增长，带给数据库的压力自然也在倍增。据了解，2018 年前，B 站数据架构大部分采用标准的主从架构。 2018 年后，B 站进入快速发展期，用户增长较快，急速增长的背后带来了大量的变更需求，数据量急速膨胀，需要频繁进行资源扩容、拆分、迁移。

当时，B 站的数据库大部分都在采用 MySQL，按照常规的技术演进方案，B 站应该开始考虑引入分库分表架构来解决 MySQL 单机瓶颈问题了。但一个理想的中间件，不论是开源还是自研都需要很长时间去打磨，才能使业务平滑适配。

解决方案

在调研了 TiDB、CockroachDB、Vitess、Kingshard 等开源方案后，从应用的兼容性、改造成本、扩展性、高可用、运维的复杂度等维度评估后，发现 TiDB 是唯一的选择，没有其他更合适的数据库。TiDB 作为一款云原生分布式数据库，具有水平扩展、高度兼容 MySQL 、无需考虑分库分表等特点，可以满足海量数据规模，带来更强的业务灵活性和成本效益。

熟悉 B 站的用户肯定都知道“一键三连”（点赞、投币、收藏），这对于提升 UP 主的创作信心具有极大功效，随着用户的快速增长，这部分的数据量也在飞速增长。点赞平台聚合了 B 站所有点赞信息，来自十几个不同业务方，截止到 2018 年时，点赞数据量已经达到百亿条，MySQL 数据库 2 TB，接口 QPS 高达数万。

在业务快速增长的同时，MySQL 的磁盘空间也在快速逼近磁盘空间的上限，而 B 站的业务特点决定了相关数据不能像电商类一样进行归档。当时摆在 B 站面前的只有两条路，一是采用分库分表方案，虽然可以解决持续的空间需求，但这种方案也存在一些不足，如：中间件的打磨需要时间；对业务有入侵，需要改写代码，无法快速满足业务方的需求等。另一种就是采用 NewSQL 数据库。在对开源解决方案调研后，发现 TiDB 高度兼容 MySQL 协议、水平扩展，能很好地规避掉这些问题，部署和真正使用起来都比较快，而且对迁移数据也比较友好。

下图是上线的流程图：

在使用 TiDB 后，因为没有分表的存在，业务的 QPS 减少了 1/4，业务端耗时从 4ms 降低为 1.5ms。

从 2018 年 B 站开始在生产环境上线 TiDB ，目前整体部署规模已达到 100+ 集群，数据节点 TiKV 2000+ 部署在物理机，计算节点 TiDB Server 则大部分运行在 B 站的 PaaS 上，以 Docker 方式部署，快速动态扩缩容（部署架构图如下）。相关业务场景包含了大家熟知的一键三连、弹幕、评论等。