分布式数据库迁移OceanBase——基于网易云音乐自研CDC服务的平滑迁移方案

编者按：作为一款专注于发现和分享的音乐产品，#网易云音乐 引领音乐产品从“播放器时代”进入“在线社区时代”，为用户打造全新的音乐生活。在大体量的业务数据背后，是何种技术方案在支撑？本文分享网易云音乐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、多种主流数据库兼容性、多租户等多个方面都有关键性的技术突破，并在复杂而严苛的金融核心业务场景中久经考验。
<ul>资源成本：实测发现存储空间可降低至少 1/4。
高可用：实现自动故障恢复，RTO

收藏一下   不知道什么时候能用到