👆 立即咨询 TiDB 企业版 👆
在数字化转型的浪潮中，企业面临着数据量爆炸式增长和业务需求日益复杂的双重挑战。网易游戏和知乎 PB 级别的数据均在 TiDB 的支持下实现高效处理。TiDB 不仅提升了数据处理效率，还为企业带来了成本效益和技术优势。
本篇合集将分享网易游戏和知乎的 TiDB 应用实践，了解企业如何运用 TiDB 实现数据库架构的革新，优化业务流程，提升用户体验，并在激烈的市场竞争中稳健前行。
网易游戏 x TiDB
数据规模超 1PB ！揭秘
网易游戏规模化 TiDB SaaS 服务建设
数据库现状
TiDB 为网易游戏及其周边服务提供一站式数据库管控服务：
平台服务层：DMS 负责数据维护和治理，DTS 负责数据库之间的数据迁移，比如 MySQL 到 TiDB 之间的迁移以及到 kafka 迁移等。DaaS，主要负责服务管理，包括调度和备份。
数据库服务层面：提供了包括 MongoDB、Redis、MySQL、TiDB 等在内的多种 数据库 SaaS 服务。根据最新的统计数据，TiDB 集群的数量已超过 100 套，TiDB 的数据总规模超过了 1PB，在网易游戏中的应用中已经达到了相当的规模和深度。
TiDB 在网易游戏使用场景
TiDB 在网易游戏的应用场景非常广泛和复杂。包括基础架构服务、云存储、内部管理和质量治理等 OLTP 场景；以及上游是 MySQL，下游 TiDB 作为读扩展的业务场景；重 OLAP 场景下的业务，比如使用 TiSpark 直接请求 PD 进行报表统计计算；利用 TiDB 的横向扩展能力， 进行数据归档。
TiDB SaaS 平台服务介绍
套餐定制
我们为多样化业务场景提供定制化服务套餐，包括针对高并发 OLTP 场景的高性能套餐、满足大型业务数据归档需求的高存储套餐、适用于常规业务的普通套餐和支持测试环境的测试套餐。通过 LXC 虚拟化技术和资源隔离措施，确保了不同实例间的独立性。平台支持套餐升级，动态扩容资源以适应业务增长。
备份
快照备份：TiDB SaaS 平台提供关键的快照服务，支持 OLTP 场景下快速数据备份与恢复，操作简便且不影响业务运行。
BR 备份：提供灵活、简单的备份操作，支持库表级备份，无需预留数据盘空间，且恢复过程灵活，适应不同规模的 TiKV 节点。
恢复过程：根据快照备份和 BR 备份的不同，采取相应的恢复方法，确保数据完整性和快速恢复至 TiDB 集群。
DTS
MySQL 与 TiDB 数据流向的闭环：TiDB SaaS 平台通过 DTS 服务支持 MySQL 与 TiDB 之间的数据同步，允许指定库表同步及反向同步，确保数据迁移的完整性。
异构数据的同步：利用 TiCDC 服务，提供全量或增量数据同步至 Kafka 及其他非关系型数据库的能力，满足多样化的数据同步需求。
定制化监控调度服务
在我们使用的初期，在实际业务的应用中也遇到了很多问题，针对这些情况，我们打造了定制化的监控调度服务。
高并发请求运维实践
在应对高并发场景中，我们积累了丰富的运维经验。以网易的一个项目为例，实际 QPS 达到 36 万，远超初期预估的 10 万并发量，且面临巨大的 I/O 需求和数据清理挑战。为此，我们在设计阶段就从数据库和业务层面进行了优化，以应对这些挑战。
为解决这些问题，我们采取了以下措施：
升级 TiDB：从 5.1 版本升级到 6.1.7，提高了 GC 效率，减少了空间占用并节约了成本。
滚动升级策略：面对大规模集群，采用滚动升级和快照备份，确保升级可迅速回滚，解决大 Region 问题，保证数据备份和升级流程。
解决 Raft 性能抖动：关闭 6.1 版本的 raft engine，回到 rocksdb 默认写入方式，以减少性能抖动。
点击此处丨阅读原文
知乎 x TiDB
知乎 PB 级别 TiDB 数据库在线迁移实践
在线机房 prepare 阶段
一般在线机房迁移都是同城，且机房距离在 150 km，需要具备条件：
专线要求
数据中心距离在 150 km 以内，通常位于同一个城市或两个相邻城市；
数据中心间的网络至少采用2条光纤专线连接，并且要求延迟 3 ms 左右，并且长期稳定运行；
双专线且带宽大于 200 Gbps。
资源要求
物理机：比之前的配置要好，尤其当前的高密机型，考虑好硬盘 pv、cpu、内存资源规划；
K8s ：版本选择，以及环境搭建完毕，到达可用程度，并且可以绑定物理机 nodes 资源；
Operator：TiDB-operator 尽量选择高版本，做好调研和测试验证，到达可用状态
在线 TiDB 集群迁移切换方案
整体的迁移架构如上图所示，可以看到：
双 K8s 集群结构：上方 K8s 集群 online 代表老机房的 TiDB 集群，下方为新建立的 K8s 集群，两者均部署 TiDB 集群。
双同步链路：中间两个红框表示两种同步方式，一是利用 TiDB 的 placement-rule 进行数据副本投放，二是通过 TiCDC 同步不同版本的上下游 TiDB 集群。
跨云跨 k8s 的 TiDB placement-rule
副本投放迁移（60% tidb 集群都由此方案迁移）
迁移架构说明：
Placement Rules 是 PD 4.0 版本引入的副本规则系统，允许用户精确控制数据副本的分布和行为。优点包括自动根据规则在不同 Kubernetes 集群中投放 TiKV 数据，对业务透明，保持写入和读取性能。缺点是不能跨版本使用，且新机房产生 leader 可能导致读写延迟增加，但对多数业务可控。
多云同构集群迁移操作步骤：
在 online2 创建同版本 TiDB 集群
创建同配置同数量的 TiKV 节点 + 配置 placement-rule
调优 region 的创建速度
config set schedule 来加速调度
均衡 region leader 到新机房集群（follower->voter）
多云多活状态，缩容老机房所有 TiKV，delete store，对于“顽固 region ”进行 delete region
切 PD leader 到新机房
业务切读写到新机房
缩容老机房 TiDB Server
老机房缩容所有 pd 节点
老机房 delete pvc
回收物理机资源(delete nodes ，关机回收)
TiCDC 链接的主备集群
（ 30% TiDB 集群由此方案迁移）
基于 TiCDC 的迁移先通过 BR 恢复老集群全量数据，再同步增量数据。优点包括独立集群支持版本升级，增加数据库隔离性和稳定性，且迁移可随时回滚。缺点是 TiCDC 可能存在高延迟和同步能力限制，BR 备份/恢复耗时长，且长 gc-life-time 设置可能影响 TiDB 读性能。
TiCDC 迁移操作步骤：
在 online2 创建新 TiDB 集群
调整老集群的 gc_life_time ，比如设定为 3 天(72h，按需调整)
使用 BR 工具备份老集群 databases 数据到 S3
使用 BR 将 S3 的 TiDB 备份恢复到 online2 新集群
创建老集群到新集群的 CDC 任务
同步验证
数据验证没问题
业务方读流量灰度 100% 到新集群就可以切写
停写后，需要观察下同步链路，确认没有数据同步，然后停止老机房到新机房的 TiCDC 同步链路
业务切到下游新集群完成 TiDB 切换
观察一周后，下线 TiCDC 反向同步链路以及删除老集群
回滚方案
点击此处丨阅读原文
👇 立即咨询 TiDB 企业版 👇
