编者按：作为一款专注于发现和分享的音乐产品， #网易云音乐 引领音乐产品从“播放器时代”进入“在线社区时代”，为用户打造全新的音乐生活。在大体量的业务数据背后，是何种技术方案在支撑？本文分享网易云音乐PB级分库分表架构向原生分布式数据库架构迁移的技术优化经验。

作者：吕娅婷，网易云音乐资深平台开发工程师

迁移背景与核心挑战

分布式数据库 DDB 现状

网易云音乐使用最多的数据库是其内部自研的分布式 DDB 。DDB 非原生分布式数据库，而是基于 MySQL 存储节点搭建的中间件，其具有以下特点：

• 分库分表中间件：两级映射，自定义哈希。使用 MySQL 服务器作为底层数据存储节点，实现了自动路由。
• 标准化：SQL 兼容、全局自增 ID、兼容 MySQL 通信协议。
• 分布式事务：基于 2PC 协议保障数据一致性。
• 弹性扩缩容：通过 NDC 工具实现在线数据迁移（全量/增量），支持断点续传。
• 高可用：使用常见的 MySQL 主从复制实现高可用以及读写分离，同时也支持单元化。
• SQL 统计：支持 SQL 模式、SQL 频度慢 SQL及多维度  QPS  统计等。

作为网易云音乐主要的 OLTP 方案，DDB 拥有较大的数据体量，其数据流架构如图1所示。从图中可以看出，通过DBI JAR 包这个访问接口向上层应用程序提供服务。整个数据处理流程为：当上层应用程序下发 SQL 后，由DBI 进行解析生成语法树，而通过语法树生成的执行计划由执行器直接下发到底层 #MySQL。多个 MySQL 节点的结果汇聚到 DBI 进行处理，最后返回上层应用程序。

图1 DDB架构

除了 DBI JAR 包（类似 SDK 方式），我们还提供了 QS（Query Server）方式，可将其理解为一个 Proxy。QS 兼容 MySQL 协议，可作为 Proxy 单独部署，相当于一个 MySQL 实体库，支持命令行和应用接口这两种访问方式，进而使应用程序可以像访问 MySQL 一样访问 QS。

在图1中，用户通过控制流可以实现 DDL 处理和元数据分发同步，Master 节点会将元数据同步到 MetaStore 即 元数据库 中，然后将元数据变更通知到每一个 DBI 的应用层。 DBI 和应用集成的方式虽然缩短了整个数据链路，但也带来了一些运维问题，比如当DBI数量较多、底层节点发生大批量切换或更改时，整体操作较为耗时，且若部分DBI未及时感知，可能影响该应用的读取或写入。

DDB 作为一个久经考验的数据库， 在使用过程中也存在一些痛点问题。

• PB 级数据存储，缺少高效压缩。目前底层 - MySQL 节点是5.7版本，不支持高效压缩，通常情况下计算资源还有剩余，存储资源就已经遇到瓶颈，资源利用率极低。
• 扩缩容流程复杂、耗时。DBA 每年大概要花费 20% 以上的精力进行扩缩容，人力成本很高。
• 分钟级故障切换。尽管当前我们已经多次优化故障切换，但也只能达到分钟级。
• 更新操作引发从库延迟，数据复制性能存在瓶颈。在 MySQL 主从复制模式下，如果有大批量更新，MySQL  Binlog 性能存在一定瓶颈，复制延迟，对于数据敏感业务不友好。
• 缺失延续性维护。由于版本迭代成本很高，后续很难进行版本变更。

基于上述痛点，我们决定将 DDB 切换到原生分布式数据库  OceanBase 。

为什么选择从DDB迁移到 OceanBase？

OceanBase 是一款原生分布式数据库（见图2 ），采用单机分布式一体化架构设计，在弹性扩展、高可用、多活容灾、存储引擎、分布式事务、HTAP、多种主流数据库兼容性、多租户等多个方面都有关键性的技术突破，并在复杂而严苛的金融核心业务场景中久经考验。

• 资源成本：实测发现存储空间可降低至少 1/4。
• 高可用：实现自动故障恢复， RTO <8秒。
• 高效复制：底层基于 Paxos 协议实现高效复制。
• 兼容性与稳定性：兼容 MySQL 协议，迁移成本低。
• 运维成本：同样由于兼容 MySQL 协议，运维成本低。
• 社区红利：社区生态健全、活跃度高。

图2 OceanBase产品形态

从产品特性和应用案例来初步判断，我们认为OceanBase能够解决我们使用DDB时面临的问题。

迁移 OceanBase 面临的核心挑战

然而，DDB和OceanBase 作为两个由不同企业研发、架构差异较大的数据库产品，使我们在迁移过程中遇到了四个挑战。

异构数据同步挑战。  数据库内部的数据传输工具互相不支持，无法直接实现数据同步，因此需要将 DDB 的分片逻辑改造成 OceanBase 的分区，同时实现分布式事务跨节点一致性保障。

业务无感迁移挑战。  迁移过程需要实现业务无感，源端发生 DDL 变更或者 MySQL 节点主从切换时，必须保证在线切换不阻塞迁移。迁移过程对迁移组件本身的高可用也有高要求，需要做到不停服升级，而OceanBase提供的迁移工具——OMS 暂不支持（后续计划支持）。

反向迁移效率挑战。  从 DDB 到 OceanBase 的正向迁移数据最快能达到 GB /s的速度，但反向迁移在大表场景和大流量场景下同步效率较低。同时也需要支持 TB 级数据快速比对。

运维效率挑战。  整个迁移过程中可能会创建上千个同步任务，如果依靠人工运维，效率低下。

迁移架构与适配工作

由于数据迁移涉及正向同步和反向同步这两个长期的同步任务，对链路稳定性及低延时性要求很高，因此我们开始了严谨的迁移架构与适配工作。

自研 CDC 服务——NDC 架构

首先，我们自研的CDC 服务——NDC 架构，类似 DTS，可以实现端到端的全量迁移、增量迁移和数据订阅的服务系统。

• NDC 大致可以分为源端系统、NDC 集群、目标端系统三部分。源端系统目前主要支持网易内部 OLTP 类型数据库和 OceanBase，目标端支持 OLTP 和  OLAP  类型数据库、以及消息队列 Kafka 等。
• NDC 拉取源端系统的全量或增量数据，经过转化和过滤写入目标系统中。
• NDC 支持全量、增量同步/迁移；提供结构、全量数据、快速不一致复检等多模式校验，确保源和目标一的致性。 如图3所示，在 NDC 内部：Dashboard 是应用入口；Center 用于元数据管理；Engine 节点是无状态的，负责拉取源端 Binlog 等信息，然后将数据进行解析，同步到目标库。

图3  NDC架构

NDC 迁移方案

使用NDC 进行数据迁移同样涉及正向同步、反向同步，正向同步指从 DDB 到 OceanBase，反向同步指从 OceanBase 到 DDB。由于涉及部分回滚场景，因此需要保证反向同步也是稳定、安全的。

1.正向同步

正向同步主要支持如下能力：

• 并行解析 Binlog。以 MySQL 为单位并行拉取、解析可以加快解析速度，同时每个 MySQL 的并行拉取解析进程是随意无状态的，可以被分布到多个机器中，极大提高资源利用率。
• 一拉多推模式，即一次解析多次使用，减少对源端的侵入。因为在上游建立 MySQL Dump 链路对源端有感，如果 MySQL 库或 DDB 表有很多订阅需求，需要在源库建立几十个链接，不管是主库还是从库，都会产生影响和侵入，因此一拉多推模式实现只拉一次解析却能多次使用，减少了对源端的侵入。
• 支持表内并发写，不同索引数据并发写。单个MySQL内部，可以通过表、索引维度进行并发，因此最终的表并发数是该表分布的MySQL 数量乘以每个MySQL子任务内部设置的并发数，实际并发非常高，同时可以利用不同机器资源去运行同一张表的不同的MySQL级任务。
• 自动响应上游切换，自动感知主从切换、节点变更等。可以自动感知上游 MySQL的主从切换以及节点变更，不需要人力运维。

图4 正向同步方案

2.反向同步：Binlog or CDC?

Binlog 模式是我们最早支持的同步模式，简单易用、稳定性高、兼容性强。大致流程如下：

• BC 模块拉取 Clog 并将其转换为 Binlog 格式，转换后将其写入 Binlog 文件。
• MySQL Binlog 生态工具发起 Binlog 订阅请求到 OBProxy，OBProxy 将其转发至 OBLogproxy。
• OBLogproxy 接收 Binlog 订阅请求后启动 BD 模块，读取 Binlog 文件并对外提供订阅服务，即 Binlog Dump 服务。

相当于为了使下游使用方便，兼容了 MySQL 的 Binlog，将 OceanBase 产生的 Clog 多转了一层转为 Binlog，但由于链路增加，效率会比较低。去年 Binlog 解析模式的效率是每秒25MB/每秒，对我们来说是无法接受的，后来 OceanBase 团队将这个值优化到了140MB/每秒，暂时满足了业务需求。

图5 Binlog同步模式

相比 Bonlog 模式，CDC 模式更简单，因为不需要将 Clog 转换为 Binlog，直接拉取 Clog，使用OBLogClient 启动，具体流程如下：

• OBLogClient 启动后需要发送消息到 OBLogProxy，需指定要订阅的用户、库表、增量链路位点等信息。
• OBLogProxy 鉴权通过后，启动 OBLogreader 子进程，并将连接等相关信息传递至 OBLogreader 子进程。
• OBLogreader 启动后会提取并解析 Clog，按照一定的数据格式发送至下游来完成数据订阅。

图6  CDC同步模式

OBCDC or OBLogProxy？

我们对 OBCDC 和 OBLogProxy 也做了调研，两个方案都属于 CDC 模式，OBCDC 是持续迭代版本的 OBLogProxy。

• OBCDC：以动态库的形式对外提供 OceanBase 数据库实时增量（事务）数据。通过 RPC 向 OceanBase 数据库请求各分区的 Clog（Redo）日志。
• OBLogProxy：OBCDC 的代理，OBLogProxy 调用 OBCDC，作为 OBCDC 的消费者获取 OceanBase 数据库的增量事务数据。

图7 OBCDC 和 OBLogProxy 方案对比

虽然CDC模式省去了binlog生成及解析的额外成本，但由于技术栈、兼容性及可维护性的考量（OceanBase 在 4.2.0版本后将不继续维护 CDC 模式），两种形式都非理想解决方案，因此我们最终并未采用CDC模式。

目前我们基本上实现了业务无感迁移、零数据丢失、正向同步效率GB/s，反向百+MB/s。

图8 正向迁移、反向迁移流程

支持迁移 OceanBase 的适配优化

在迁移过程中，我们共完成了如下方面的适配和优化工作。

• 驱动适配：JDBC 驱动版本降至8.0.25版本。
• 语法适配：移除 OceanBase 暂未支持的 DML 或语法（如 insert、ignore 语法）。
• Binlog 解析适配：移除 RotateLogEvent 的 Checksum 校验。
• 反向双模式：CDC 及 Binlog 双增量模式、内存队列及消息队列双缓存模式应对不同流量场景，提升反向同步速度.。
• 元数据变更感知：提升 DDB 为源端时底层 MySQL 发生主从切换的 NDC 感知及响应速度。

后续我们也计划实现通过 AI 迁移，即基于 MCP 的多 Agent 实现 NDC 工具的智能化运维，降低迁移过程中长期同步任务的运维成本。目前还处于早期迁移阶段，相关工作正在进行中。

当前进展与未来规划

当前网易云音乐各业务已经逐步开始使用 NDC 进行验证、线上同步、双跑等相关落地，部分业务已完成迁移，周边基础设施也开始陆续跟进，验证了系统是成熟可用的。但为了业务的稳定切换，我们的切换周期相对比较长，还有很多工作要做。

后续我们会进入核心试点和大规模迁移阶段，进一步完善 OceanBase 及周边生态的体系化建设，包括工单、部署、测试、调优、运维等。虽然我们在起步阶段，却已经接受了 OceanBase 社区很多的帮助，在此也非常感谢 OceanBase 的支持帮助。