---
title: 'TiDB x Bilibili | “一键三连”背后的数据库'
date: '2023-06-29T21:53:40+08:00'
status: publish
permalink: /case/user-case-bilibili
author: xuliwen
excerpt: 'TiDB 已应用在 Bilibili 的一键三连、弹幕、评论、视频元数据存储等场景，解决了海量数据增长带来的系统压力，让技术团队更快响应业务创新需求。'
type: case
id: 1251
thumbnail: https://img1.pingcap.com/files/2023/02/Bilibili.svg
industry:
    - 视频
scene:
    - '规模 OLTP'
company_desc:
    - '哔哩哔哩（Bilibili）网站创建于 2009 年，是中国年轻世代高度聚集的综合性视频社区，被用户亲切地称为“B站”，2018 年在纳斯达克上市。根据艾瑞咨询报告，2020 年 B 站 35 岁及以下用户占比超 86% 。2021 年三季度，B 站月均活跃用户达 2.67 亿。'
white_paper_link:
    - ''
banner_image:
    - ''
---
与国内其他视频网站定位不同，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 协议、水平扩展，能很好地规避掉这些问题，部署和真正使用起来都比较快，而且对迁移数据也比较友好。

下图是上线的流程图：  
![screenshot-20220322-172740.png](https://img1.pingcap.com/prod/screenshot_20220322_172740_b1c155ef12.png)

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

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

![20220322-171618.jpg](https://img1.pingcap.com/prod/20220322_171618_346391d38c.jpg)在 2021 英雄联盟全球总决赛（即 S11）的直播与点播中，B 站迎来了一次最大的流量高峰。由于在本次赛事中，中国战队 EDG 战胜卫冕冠军，首次夺得全球总决赛冠军。网友都比较激动，B 站的赛事回顾视频点赞和弹幕数据一下子暴涨，数据流量瞬间变得特别大，QPS 最高达 30w+，比日常高 2 倍。

此外，B 站的所有视频元数据都存储在 TiDB 中。这一业务对数据库的可靠性要求较高，举例来说，视频播放到哪一帧读什么素材，其实都会有一个完整的元数据存储下来。 目前，B 站视频元数据累计达 30TB， QPS 日常维持在 5w+。在 B 站“拜年纪”活动中，TiDB 提供了较高的稳定性。

业务价值
----

从业务角度看：TiDB 高度兼容 MySQL 协议，改造成本极小，业务方的需求可以得到快速满足。

从 DBA 角度看：一方面云原生分布式架构可以实现存储与计算的水平扩展，进行容量扩增更简单，从以前的几周缩短到数分钟，对业务透明无感；另一方面，TiDB 架构实现与 MySQL 是两个不同的思路，可以帮助团队技术成员扩展思路。

在深度使用下，Bilibili 的 TiDB 节点数从去年的 1000+ 涨到了今年的 2000+，未来还将在更多业务场景中进行尝试。