导读
B 站对 TiDB 的应用已相当广泛，被应用在了 包括视频观看、一键三连、发送弹幕、撰写评论、阅读漫画以及视频后端的存储等场景， 目前拥有近 100 套集群。
本文由 B 站数据库负责人赵月顺撰写， 详细介绍了 B 站面临业务增长选择 TiDB 的原因，以及采用 TiDB 后的部署架构、容灾实现、运维经验和未来规划 。
TiDB 在 B 站的使用场景和部署架构介绍
B 站的 TiDB 集群规模已达到 100 多套，计算节点超过 2000 个，存储节点超过 800 个。TiDB 的应用场景非常广泛，包括视频观看、一键三连、发送弹幕、撰写评论、阅读漫画以及视频后端的存储等。
B 站的 TiDB 部署采取了存算分离的策略，计算节点被部署在容器中 ，这种做法的优势在于能够充分发挥容器化管理无状态服务达到水平弹性拓展能力，允许根据需求随时对计算节点进行扩展或缩减，整个过程仅需一次服务发版，有效提升了效率与灵活性。 存储节点则继续部署在物理机上 ，这也是 B 站拥有超过 2000 个计算节点和 800 个存储节点的原因。
目前，B 站使用的是大约 3T 容量的 NVMe 硬盘。在存算分离架构下，扩容策略分为两种情况：
- 计算节点的扩容 ：当计算节点面临性能瓶颈时，B 站会利用云平台的 HPA 功能。通过设定一个阈值，一旦负载达到该阈值，系统便会自动进行水平扩展，确保计算资源能够满足业务需求。
- 存储节点的扩容 ：存储节点的扩容主要依赖于运营监控和报警机制。当存储容量接近预设的预警线时，运营团队将收到报警，随后根据实际情况进行评估，并决定是否需要进行扩容，以确保数据存储的安全性和可靠性。
海内外业务技术侧的挑战
B 站自 2018 年起大规模采用 TiDB，主要原因是那一年 B 站业务经历的空前增长。用户量每个季度的增幅达到了 70%至 80%，这一增长速度对存储基础设施构成了巨大压力。业务数据量迅速增加，单表记录突破百亿条，每秒查询量（QPS）超过万次，单机存储已无法满足业务增长的需求。
当时，线上存在千亿级别的数据表，且数据规模持续扩大。面对如此庞大的数据增长，需要一个有效的解决方案。
B 站使用 TiDB 的理由
经过对市场上的数据库存储解决方案的调研， 发现将 MySQL 迁移至 TiDB 的成本相对较低 ，这为 B 站节省了大量成本和资源。同时， B 站对数据强一致性有着严格要求 ，而当时没有中间件解决方案能够同时满足大规模数据增长和 MySQL 兼容性的需求，TiDB 成为了唯一能够满足这些条件的解决方案，为 B 站的业务发展提供了坚实的分布式数据库存储支持。转向 TiDB 后，B 站的单集群存储容量已超过 80TB。
具体而言，选择 TiDB 作为数据库的基础支撑主要出于以下考虑：
- 兼容性 ：鉴于 MySQL 在业务系统中的核心地位，TiDB 与 MySQL 的高度兼容性显得尤为重要。这种兼容性意味着现有的 MySQL 数据库可以较为轻松地迁移至 TiDB，从而降低了迁移风险和成本。同时，这种兼容性也便利了开发人员对 TiDB 的快速适应和使用，无需投入大量时间学习新的数据库操作和语法。
- 存算分离的架构 ：相较于传统数据库架构中存储和计算的紧密耦合，TiDB 的架构允许独立扩展存储和计算资源，根据业务需求灵活调整，提升了系统性能和可扩展性，同时简化了运维工作，降低了成本。
- 社区贡献 ：TiDB 拥有一个活跃的社区，成员们积极贡献代码、解答问题并进行技术交流。社区提供的详尽文档和教程加速了用户对 TiDB 的了解和掌握，而社区的反馈和建议也推动了 TiDB 的持续改进和优化。
- 可靠性 ：TiDB 满足了分布式数据库对数据可靠性的高要求。基于 Raft 协议的 TiDB 能够在节点故障和网络延迟等异常情况下，确保数据的强一致性和可靠性，为业务提供了坚实的支持。
TiDB 在大规模数据容灾场景的优势
选择 TiDB 的另外一个重要收获是，在大规模容灾恢复方面，TiDB 因其灵活的架构设计、高可用性以及对多活部署的支持上有着明显的优势。
存算分离的架构设计使得计算和存储资源能够灵活地在线扩展或缩减，整个过程对业务开发以及运维人员透明，简化了大规模环境下的资源管理和开发工作将至 0 成本。 TiDB 通过多副本和 Multi-Raft 协议确保数据在不同机房、机架和机器间的高可用性，实现快速自愈故障恢复（RTO <= 30s）和数据零丢失（RPO = 0）。此外，TiDB 支持可用区多地多活部署，通过 TiDB-binlog 进行数据同步，增强了跨区域的灾难恢复能力，确保业务连续性和数据强一致性。这些特性共同构成了 TiDB 强大的高可用自愈容灾优势。
对于 B 站而言，目前尚未实现两地三中心的布局。2023 年，B 站进行了大规模的降本增效的工作，包括大规模的机房搬迁，从 5 个机房减少到 2 个机房，从而将多中心布局转变为双中心布局。在搬迁过程中，由于 B 站的 TiDB 版本为 4.0，相对陈旧，因此采用了 TiDB 的 TiDB-binlog 专用工具在两个中心之间进行了单向数据同步，实现了基础的高可用能力。
B 站 TiDB 运维经验分享
在运维大规模的 TiDB 集群过程中，我们也总结了一些值得参考的经验：
首先，必须制定关于 TiDB 的分布式数据库使用规范 。尽管 TiDB 功能强大，但依然需要明确的规范和使用限制。这包括明确规定数据备份的时间间隔、存储方式和恢复流程。同时，对数据库访问权限进行严格控制，以防止数据泄露和误操作。
其次，对业务需求的支持需结合 TiDB 产品特点以及优势，提供合理的评估和分析。 不能无差别地满足业务部门的所有需求，而应考虑其对数据库性能的影响及是否存在更优的解决方案。例如，面对业务部门提出的数据查询请求，需评估该请求是否会对性能产生负面影响，并探索可能的优化方法。
第三，建议坚持使用 TiDB 的官方推荐版本，并慎重考虑二次开发。 一些公司基于 TiDB 进行二次开发，但结果并不理想，特别是在降本增效和人员减少的背景下，他们面临独立版本分支维护复杂以及需求迭代缓慢等困境。因此，建议用户使用官方版本，以便在升级过程中更为顺利。非官方版本在遇到未知 bug 时，可能难以获得官方的有效支持，因为官方难以了解具体的改动情况。
最后，推动 TiDB 使用的工具化、自动化和平台化是关键。 随着集群规模的扩大，缺乏这些措施将导致运维工作低效且依赖人工，影响运维效率。通过自动化工具实现数据库的部署、监控和故障恢复，减少人工干预，提高工作效率。平台化的管理方式有助于对多个数据库集群进行统一监控和管理，及时发现并解决问题。
B 站 TiDB 升级 & 人才培养计划
B 站的 TiDB 版本目前还属于比较老的版本，但我们有一些升级规划：
如图所示，部分 v6.0 和 v7.0 版本的 TiDB 正在试运行中。由于目前绝大多数集群仍在运行 v4 版本，这一版本已显陈旧，因此在升级过程中存在诸多顾虑。特别是考虑到直接跳过 v5 和 v6 版本升至 v7 可能引发的兼容性问题和潜在风险，所以没有参与官方的升级活动，但已积极开展相关测试。 测试结果表明，从 4.0 版本直接升级至 7.5 版本，并进行 TiDB 同步是可行的 ，接下来的关键步骤是对业务流量进行验证。
在人才培养方面，B 站所有 MySQL 方向的 DBA 已全面参与到 TiDB 的学习和运维中。在此过程中，TiDB 社区提供的线上学习资源，以及体系化的课程学习和考试名额，对人才培养起到了积极的推动作用。
展望未来，B 站将继续增加对 TiDB 的投入，涵盖技术研发、人才培养和业务拓展等多个方面。随着 TiDB 技术的持续进步，预期将为 B 站的业务发展提供更强有力的支持。