OceanBase 在网易游戏 DB SaaS 的技术实践：存储成本降 60%，备份恢复提速 3 倍

网易游戏 DB SaaS 平台架构

网易游戏作为中国领先的游戏开发公司之一，一直处于网络游戏自主研发领域的前端。其产品及周边业务众多，涵盖《梦幻西游》《大话西游》《蛋仔派对》，以及游戏交易宝藏地“藏宝阁”等一系列热门游戏服务及周边产品线，需要不同的数据处理产品来满足不同的业务场景。

针对这些丰富多样的游戏及周边业务场景，DB SaaS 提供了一站式的数据库私有云服务平台，旨在满足所有数据库需求。

如图 1 所示，DB SaaS 的服务主要被分为三层。

图 1 网易游戏 DB SaaS 服务架构

第一层是硬件服务层。主要提供自建 IDC 机房虚拟化、公有云（包括 AWS、阿里云、GCP、微软云）及自建私有云服务，全面覆盖底层基础设施需求。

第二层是数据库层。在硬件服务层之上，我们构建了强大的数据库服务层。这一层提供了多种类型的数据库服务，包括文档型、内存型、关系型、KV 型、向量型以及图数据库，全面满足不同的数据存储与处理需求。 

第三层是数据库服务能力层。服务能力层简单说分为三个方面：

• 一是数据库生命周期管理，主要提供资源管理、数据库架构、数据库实例的完整生命周期服务。其中资源管理涵盖从资源创建、扩容缩容及销毁，再到资源回收的灵活管控。

• 二是数据管理服务（DMS）。提供安全多样化且便捷的数据查询、分析、变更服务，包含版本管理、参数管理等多项访问控制功能，以及一系列数据处理功能。

• 三是数据迁移服务（DTS）。包括为用户提供数据查询、数据回滚、表索引管理、提供业务合服、拆分迁移等多样化数据流转服务。该服务应用场景广泛，不仅适用于异构平台的数据库迁移，还涵盖版本升级、数据合并、跨云迁移及外部系统迁移等多种需求。

针对数据库服务能力层，我们打造了一套全面的备份管理系统，主要适用于游戏场景。游戏行业的频繁更迭要求我们提供高效、灵活的备份方案，因此，网易游戏系统集成了常规备份、快速备份、增量备份、库表备份以及备份巡检等一系列强大的备份功能，确保数据的安全。

游戏业务场景特点及数据库选型需求

游戏业务特点及 MySQL 应用痛点

基于底层的 DB SaaS 服务，以一个游戏周边的服务为例，业务初期我们采用单实例主备从的架构模式。随着接入的游戏数量不断增加，这种架构已无法满足日益增长的请求需求。因此，我们决定对数据库进行拆分，比如将一个实例拆分成多个实例，以应对这一挑战，如图 2 所示。

图 2 某游戏周边服务平台的数据库架构演进

拆分后，由于业务场景的特殊性，我们需要进行大规模的合并查询，这对性能和稳定性要求极高。因此，我们引入了一个汇总实例来应对这一需求。起初，这个汇总实例是由 MySQL 承担的，但随着业务规模的不断扩大，遇到了 6 个主要问题。

1、高并发响应问题

首先，上游突发的大量流量对业务构成了严峻挑战，高峰期主库请求量达到接近十万 QPS，单个从库读的请求也在几万左右，所有从库的总 QPS 在高峰期接近百万，整体并发量高，需要频繁紧急拆库，难以应对。其次，汇总实例需要处理高并发的查询请求，对任何微小的性能抖动都极为敏感，而我们的业务对延迟极为敏感，不能容忍波动。我们之前使用的单机 MySQL 已经无法承载高并发需求。

2、数据同步延迟问题

有一些业务，从库读请求延迟要求非常高，要求延迟非常低，当请求量非常高时，尤其是一些游戏进行活动时，这种延迟尤为明显，数据库存储操作可能会频繁遭遇延迟。一旦从库出现慢查询或其他情况影响到从库延迟，会对业务造成极大影响。此外，在汇总实例时，由于需要从多个源头复制并同步上游的各个分库数据，与此同时叠加汇总实例的查询压力，进而导致数据同步的延迟。

3、单库存储空间压力问题

单节点的存储空间已经超过十几 TB 以上，对于处理高并发 TP 业务的 MySQL 来说，这样的压力是非常巨大的。

4、业务隔离问题

随着网易游戏不断接入新游戏，业务场景变得复杂。例如，某款游戏举办活动时可能会带来突发流量，进而影响其他游戏的正常运行。因此，业务方希望实现一种既简单又有效的业务隔离手段，以确保各游戏业务之间的独立性。

5、DDL 变更的痛

这个问题也是研发和 DBA 面临的挑战，对游戏领域而言，这个问题尤为突出。原因在于，游戏领域经常进行游戏合服和拆服，因此需要进行大量且频繁的 DDL 变更。此外，游戏业务迭代非常迅速，尤其是游戏初期，需要快速迭代，快速迭代促使了频繁的 DDL 变更。

6、运维工作困难

在突发流量的情况下，即使使用顶级配置的 MySQL 也只能通过增加实例的方式来缓解压力。另外，如果单个只读从库出现故障，就需要进行实例重建的操作。由于 MySQL 实例的数据量很大，扩容从库、备份恢复都需要耗费大量时间，这对业务来说是难以接受的。

网易游戏为何选择 OceanBase？

针对上述痛点，我们通过与业务方深入沟通，明确了对数据库的具体期望，并归纳了几项数据库必备的关键特性，以精准定位数据库类型。在此期间，我们关注到 OceanBase 社区版，非常符合我们的要求。

第一点，具备高并发下的稳定性。高并发下的稳定性至关重要。OceanBase 集群三副本的分布式架构支持自动故障切换，能够保证少数节点故障情况下数据不丢失，服务不停顿，满足 RPO=0，RTO<8s 的容灾标准，确保业务连续运行不中断。OceanBase 在网易游戏的其他业务场景中已稳定运行多时，充分证明了其在高并发请求下可以保持卓越的稳定性与可靠性，几乎不出现抖动，也不会有慢查询问题。其高并发能力满足高峰期主库请求接近十万 QPS，所有从库接近百万读请求的高并发要求。

第二点，具备透明的横向扩展能力。OceanBase 具有极强的可扩展性，可以在线进行平滑扩容或缩容，并且在扩容后自动实现系统负载均衡，对应用透明无需更改业务代码，确保系统的持续运行，完全能满足网易游戏对存储横向扩展的要求。

第三点，具备很好的资源隔离特性。OceanBase 数据库支持多租户，每一个租户可以看做是 MySQL 的一个实例，单个 OceanBase 集群可以支持创建多个租户，为多个业务提供服务。为了确保业务稳定运行，OceanBase 针对租户间的资源进行了隔离，例如 CPU、内存、IOPS。通过为每个业务创建一个租户来使用 OceanBase，业务间不会相互干扰，交付也可以更加敏捷。我们对 OceanBase 的资源隔离能力进行了全面且充分的验证测试。以及 OceanBase 上线后，在多租户环境下，其资源隔离效果也得到了充分证明。

第四点，具备数据同步时效性。业务对数据实时性要求极高，因此在初期引入新的数据库产品时，我们进行了长达一个月的压测和线上跑批测试。通过使用 OceanBase 官方提供的数据迁移工具 OMS，数据同步链路几乎没有出现明显延迟，完全满足查询业务数据实时性的要求。我们在其他业务场景中也已成功应用 OMS 进行数据同步和汇总查询，实践证明其运行稳定可靠，完全满足网易游戏的业务需求。

第五点，具备一定的 HTAP 能力。如果能具备一定的 HTAP 能力，那将更为理想，这样在 TP 场景中，也能高效执行 AP 查询。在网易游戏的其他业务场景中，已验证过 OceanBase 的 HTAP 能力，一套系统、一份数据即可支撑 HTAP 场景。

第六点，成本相对较低。OceanBase 使用基于 LSM-Tree 自研的一套高级压缩的存储引擎，在存储到磁盘中时，默认对微块的数据进行编码和压缩，相比于 MySQL 的 B+ 树存储结构，OceanBase 能够节约 70%-90% 的存储成本，并且即使做了编码，也不会降低查询性能，而是由于单个微块下存储的数据更多而提升查询效率。网易游戏迁移了业务数据以后，发现即使 OceanBase 是三副本的情况，也能带来显著的存储节约，并且性能也满足业务需求。

第七点，MySQL 兼容性。OceanBase 有着良好的 MySQL 兼容性，方便业务迁移，无需修改业务代码，花费太多人力做适配测试。

基于公司其他业务场景已经充分验证 OceanBase 的相关能力，我们最终推荐业务方引入 OceanBase。

解决方案及测试：多重验证保障业务顺畅运行

在决定引入一个新的数据库之前，为了确保其适配性、高性能、高可靠等满足业务需求，我们需要对其进行严格的基准测试、业务测试、灰度测试，只有经过验证才能逐步接入应用环境。在前期测试中，我们主要从架构、高可用、一致性、兼容性、存储成本、性能等方面来做对比，以下是具体的测试情况。

测试 1：前期基础测试

1、测试环境

图 3 测试环境

2、测试工具及结果

本次测试使用 Sysbench 完成，分别进行了混合读写（读写比例 8/2）、只读场景、只写场景的测试。

OLTP 性能方面，在小规模数据量（10 张表，每张表 2000 万）时，OceanBase 4.0 版本的性能表现几乎与 MySQL 持平，OceanBase 4.1 版本的性能表现优于单机 MySQL；在数据量较大时（1 亿以上）OceanBase 扩容节点后的性能优势远超单机 MySQL，如图 4 所示。

图 4 压测对比

OLAP 性能方面，在多个大表关联或聚合分析的情况下（1 亿以上）， OceanBase 4.x 版本整体表现相对平稳，并没有出现较大波动，查询耗时也远低于 MySQL （MySQL 本身不适用于 AP 业务，此对比意义不大）。

关于存储数据压缩能力，我们从上游 MySQL 导出 5TB 数据到 OceanBase，三个副本总存储才 2.1TB，单个副本 700GB。以单份数据计算，数据压缩率接近 86%（由于上游 MySQL 存在一定的碎片空间，该数据可能也有略微偏差）。

测试 2：多租户资源隔离专项测试

针对多租户和资源隔离，我们同时对两个租户进行性能压测，主要是测试在单个租户资源被打满的情况下，另一个租户的请求响应等是否受到影响。

得出测试结论如下：

资源稳定性满足期待。高并发线程对租户资源进行压测时，租户的 CPU 和内存资源使用稳定，并没有超过限制的最大值。

隔离性满足期待，租户间没有明显影响。当租户 2 高并发线程进行压测时，租户 1 的请求量略有下降， QPS 降低大概 20%。我们推测可能是由于 I/O 资源没有做到充分的限制，出现一定程度的 I/O 争用。需要指出的是，3.x 版本并没有限制 I/O，但 4.0 版本已经实现了对 I/O 的限制。从 CPU 和内存的使用情况来看，整体没有明显的影响。

综合以上测试结果，我们认为 OceanBase 在性能、稳定性、资源隔离、降本等方面均符合网易游戏的预期，因此，我们决定与业务方共同在应用环境中正式采用 OceanBase。

引入 OceanBase 前，我们制定了分阶段策略来逐步实施 OceanBase 方案，如图 5 所示。

图 5 OceanBase 分阶段实施方案

在引入 OceanBase 的第一阶段，我们计划采用其解决汇总库问题。使用 OMS 将汇总数据的处理迁移至 OceanBase。同时，在上游流程中，削减部分重库资源，直接将更多请求导向 OceanBase 处理。

在第二阶段，计划使用 OceanBase 解决游戏库隔离问题。我们充分利用 OceanBase 的租户隔离功能，以满足业务间尤其是多游戏间的隔离需求。为此，直接在上游将多实例迁移至 OceanBase，通过多租户模式实现资源隔离。对于汇总查询，也是由 OceanBase 来完成。

确定方案与策略后，我们还针对业务方关心的兼容性和可靠性等因素，对 OceanBase 进行了验证。

• 兼容性问题。OceanBase 在大多数情况下兼容 MySQL 协议，但在特定业务场景下，是否可能存在不兼容的风险，需通过提前识别处理风险点进行应对。

• 可靠性的表现。为避免在链路较长的场景下，数据同步可能会遇到的问题，例如故障切换场景下业务表现如何，又如系统能否稳定承载突发的流量高峰。为了确保万无一失，应该针对这些重点问题提前进行验证，从而确保线上系统的稳定性和可靠性。

测试 3：兼容性与高并发流量验证

之所以将兼容性与高并发流量放在一起验证，是因为针对兼容性和流量突发的问题，业务方通常需要自行进行测试。然而，这对业务方来说往往是一大难题。虽然兼容性在某些场景下还能模拟测试，但突发流量的模拟却极为困难。因为线上业务通常非常复杂，要让业务方模拟出多倍流量的请求，实在是一项艰巨的任务。

为了解决这个问题，我们引入自研的流量回放系统。这一系统能够精准地回放历史流量，从而满足业务方在测试突发流量表现方面的需求。

流量回放系统主要由两大部分构成：流量抓取和流量回放。

在流量抓取环节，我们利用了一个名为 drcapture 的核心函数。这个函数会被部署在每一个 MySQL 集群的节点上，用于捕获流量数据。我们可以对 drcapture 进行精细控制，确保它只负责流量的抓取和分发，从而将其对系统性能的影响降到最低。

抓取到的流量数据随后会被发送给另一个组件——  drrecord。这个组件负责分析流量抓取的信息，进行整合处理。分析整合完成后，这些数据会被存储在系统的 Kvrocks 里，从而完成整个流量抓取的过程，如图 6 所示。

图 6 流量抓取与回放过程

流量抓取完成后，进入流量回放阶段。回放主要分为两个方向：一是兼容性验证，二是并发流量验证。我们会根据缓存的 session 级别来分发流量，确保流量被准确地发送到不同的 worker 中进行回放处理。

第一个场景是进行单倍流量回放。这一步骤主要目的是验证 OceanBase 与上游系统的兼容性。我们会生成一份兼容性分析报告，并根据该报告来确定存在的兼容性风险。

第二个场景是并发流量的验证。在这一环节，我们会进行多倍流量的回放。例如，如果上游抓取了 1 天约 24 小时的流量，要求在 2 小时内完成回放，这相当于 6 倍的流量回放速度。完成 OceanBase 的 6 倍流量回放后，会生成一份流量汇总分析报告。这份报告会涵盖 QPS、延迟、机器负载等多个方面的数据。

通过分析这份报告，我们可以判断 OceanBase 是否能承载如此高倍数的流量回放。基于这两种场景的验证结果，我们会在业务场景中进行相应的流量回放测试。

兼容性测试完成后，我们发现该业务场景在兼容性方面表现良好，为了更好验证，又回放了一整天的流量，结果证实，系统的兼容性没有任何问题，几乎没有需要改动的地方。

接下来，我们针对线上流量进行了更为严格的测试。按照五倍、甚至六倍以上的流量规模进行了回放，以检验系统在高负载下的表现。在这个过程中，我们特别关注了 OceanBase 的响应情况。结果就是，在如此高流量的冲击下，OceanBase 依然能够迅速响应，没有出现任何异常。

经过验证，无论是日常流量还是高倍流量回放，OceanBase 都能稳定运行，且无需进行改造。OceanBase 展现出了强大的处理能力和稳定性，为业务的顺畅运行提供了有力保障。

测试 4：可靠性验证

完成流量回放验证后，业务方对系统的可靠性仍存担忧。那么，如何验证系统的可靠性呢？简单来说，就是通过故障场景演练来进行检验。这些故障场景主要围绕那些可能影响系统可用性的因素来设计，具体包括：

• 上游机器宕机对数据库同步的潜在影响；

• OMS 服务器故障时，数据库同步的稳定性；

• OceanBase 节点间若发生宕机，对业务运行的直接冲击；

• 大表进行 DDL 操作时，对数据同步可能产生的干扰。

通过这些故障演练，能够更全面地评估系统的可靠性，确保在实际运行中能够稳定应对各种突发状况。

针对上述故障问题，我们制定了相应的解决方案。

第一种方案，针对 OMS 同步源端这一关键点，我们将采用同步、域名或 VIP 等其中一种方式来实现。理论上，上游的故障切换不应影响下游的同步。为了验证这一点，我们在线上环境中进行了实际演练。当上游 MySQL 发生故障切换，并随后加大压力测试时，OMS 的同步延迟保持在几十秒的范围内，多次演练的结果均如此。这表明，在此情况下，业务完全可以接受这种延迟。

第二种方案，在 OMS 场景下，OMS 本身支持高可用搭建，我们只需进行相应配置即可，我们主要测试了 OMS 在高可用状态下的同步延迟。模拟测试显示，单个 OMS 宕机时，同步延迟大约在 30s-60s，虽有细微差别，但整体未超过 60s。对于业务层面而言，由于 OMS 宕机并非频繁发生，这种程度的延迟是可以接受的。

第三种方案，OceanBase 自身具备高可用特性。我们主要想测试单节点宕机对业务的影响程度。测试结果显示，大部分情况下业务抖动在 8s 以内，个别高压力情况下可能达到 10s。总体来说，业务抖动控制在 10s 以下，是符合预期的。

第四种方案，关于 DDL（数据定义语言）操作的同步。在进行验证时，如果在线上加大流量进行 DDL 操作，特别是涉及多个表的 DDL 变更，可能会因为同步这些变更而导致一定的延迟。为了解决这一问题，我们的方案是跳过 DDL 变更同步。如果检测到有 DDL 操作，我们会通过特定的流程直接在 OceanBase 中优先执行这些变更。这样做对 OMS 同步没有影响，而且能够确保在 DDL 变更时，下游能够优先处理这些变更，从而不影响整体的同步进程。这种方法也解决了之前提到的，在线进行 DDL 操作时可能存在的时延问题。

OceanBase 技术实践问题经验分享

经过验证后的 OceanBase，我们将其引入以解决一些重点问题，过程中遇到了一些挑战。接下来，我将为大家分享几个典型案例。

OMS 数据同步性能优化

当我们将上游数据同步到 OceanBase 时，由于默认继承了上游的表结构，我们发现了一个问题，就是在上游写入量较大的情况下，同步过程经常会出现延迟。通过 SQL 诊断，我们定位到延迟主要发生在一个与自增序列相关的函数上，特别是 RPC 部分的耗时较高。

针对上面的问题，我们深入分析后发现，当继承表结构时，自增主键采用了 OceanBase 的 Order 模式。在这种模式下，当我们需要获取自增序列时，会出现一个特定的场景，系统会分配一段自增序列供我们使用。因为在分布式数据库中，每个节点都需要获取一段自增序列以确保数据的一致性。

在 Order 模式下，OBServer 中的 leader 会负责获取一个自增段，而其他 OBServer 在需要时也会向 leader 请求这个自增属性。这样的机制导致了一个问题，每次请求都会产生 RPC 开销，因为所有的 OBServer 都可能需要与 leader 进行通信以获取或更新自增属性。

特别是在我们使用 Binlog 进行上游同步，并通过 Binlog 同步显示插入自增值时，这个问题尤为突出。因为每次插入操作都需要更新自增属性，这就意味着每次插入都会伴随着 RPC 开销。

比如，当 leader 分发任务给 OBServer 1 去更新其自增属性时，同时 OBServer N 也可能需要更新自己的自增属性，它们都会向 leader 发起请求，从而导致大量的 RPC 通信。这种 RPC 开销会大幅降低插入操作的效率，进而影响整个系统的性能。

那么针对这个问题，我们提出了两种解决方案（见图 7）。

第一种方案是去掉自增列属性，避免更新自增属性时的全局生成。由于删除自增属性，依赖于数据同步来更新，不插入新数据，这种方法可能适用于某些场景。未来如果需要切换到此方案并查询数据，可能会遇到一些问题。

第二种方案是将 Order 改为 noorder 模式。在 noorder 模式下，每个 OBServer 都会维护自己的属性缓存，直接请求内部表，从而减少 RPC 开销。经过这样的改造，延迟问题得到了解决，满足了业务场景的需求。

图 7 OMS 同步性能优化方案

同步中查询读到事务中间态

在我们将 OceanBase 引入到线上环境后，遇到了一个新的问题。这个问题在之前上线的一段时间内并未出现，但突然在某一天开始频繁出现，引起了业务的注意。具体问题是，当读取 OceanBase 数据库时，经常会读取到事务的中间状态。

这种情况在数据汇总时尤为明显，系统只会读取到事务进行中的某个状态。特别是在进行游戏更新时，更新完成后，当前的事务其实只处于中间状态。就好比是，当我在开启一个事务的情况下，我先将某个值 N 改为 3 ，然后在事务还未结束时又将其改为 4，最后提交事务时将 N 改为 5。然而，在 OceanBase 读取时，却可能会读取到 N 等于 4 这个中间状态。

为什么会出现这样的问题呢？

其实，在业务的某些特殊场景下，一个事务内部可能会包含几百个不同的 DML 操作。当这样一个包含了大量 DML 操作的事务在 OMS 同步过程中被检测到时，系统可能会对其进行切分处理。切分的前提是我们没有调整过相关的默认值。例如，若设定的 maxRecords 默认值为 64，一旦事务操作数超过此值，系统便会自动执行切分。

切分，简而言之，就是将一个大事务分割为多个小事务，并分别提交。所以在此情况下，切分后系统恰好将更新 N 值为 4 的操作作为一个独立的小事务进行提交。因此，业务在查询时可能会获取到 N=4 这一中间状态。

为什么要在 OMS 中进行拆分呢？其实，这是因为当一个大事务进行同步时，可能会消耗 OMS 过多的资源，甚至导致一些异常情况的出现。为了避免这种情况，我们通常会对大事务进行限制和拆分。

针对这种场景，我们的解决方案是根据业务实际情况调整参数设置（见图 8）。比如游戏的业务场景中操作数通常不会超过 1000，那就将参数测试值设定为 1024，这样既能满足绝大多数业务需求，又留有一定余地。目前线上几乎没有超过 1024 的情况，这一调整有效解决了业务读取中间状态的问题。

图 8 解决同步事务问题

合理设计分区表

我们需要将 MySQL 原业务中单表几十亿行数据迁移到 OceanBase 中，我们考虑在 OceanBase 中建分区表。前期测试过程中，考虑到现阶段的查询性能和未来的扩展能力，结合业务特性（大部分业务查询都会带交易 ID 号的条件），我们将迁移的表结构设计成交易 ID 号的 512 个 Hash 分区，尽可能做到存储和性能平衡。

在业务灰度测试过程中，有少部分业务查询没有带交易 ID 号的条件，而是使用了其他字段去做匹配查询，虽然这一类 SQL 在所有的业务请求中占比不算高，但实际也有几千 QPS。由于这类查询没有走分区键，所以每次请求都会去扫描分散在所有 OBServer 节点的 512 个分区数据，导致 RPC 多次请求，造成过多的网络延迟，反映出来的结果就是 SQL 执行非常缓慢，影响整个业务。

我们的解决方案是，针对这类不走分区键的查询请求，选择合适的过滤条件列，创建全局索引，通过走全局索引方式，显著减少扫描的数据量。但这里要注意，如果这类查询请求过多，过滤条件列又不一样的情况下，该分区表可能需要创建多个全局索引，会带来额外的维护代价，一般不建议一张表上建太多个全局索引。

减少分区表的分区数，由原来的 512 个降到 10+ 个，在满足横向 Balance 的同时，即使扫所有的分区，RPC 延迟也相对降低一些。我们最终采用了这个方案来解决。

设计主键或唯一键，保证数据同步的数据一致性

在 OMS 同步 MySQL 到 OceanBase 的过程中，查询 OceanBase 的表数据，存在重复的行数据。经过排查，该分区表没有主键和唯一键，导致同步过程中，无法进行一致性校验，在 OMS 同步过程中，如果出现重启、重试等情况时，就有可能重复同步数据，引起数据冲突。

我们的解决方法是对 OceanBase 的表加上主键或者唯一键，即使重试，也会保证同步的数据一致。

OceanBase 为网易游戏 DB SaaS 带来的改变

引入 OceanBase 后，我们的业务架构如图 9 所示，业务痛点得到有效解决。目前，OMS 工具会将 MySQL 主库所有数据同步到 OceanBase 集群中，上游 MySQL 主库会依据业务逻辑定期清理大量数据，以降低 MySQL 的存储空间，而 OMS 的链路设置了忽略 MySQL 中清理数据的 DML、DDL 操作，保证 OceanBase 集群中有一份完整数据，供业务查询。

图 9 引入 OceanBase 后的业务架构

整个架构替换后，我们获得以下六点收益。

1、查询稳定。查询稳定性是业务反馈中最为重要的一点。在采用 OceanBase 替代原汇总库后，业务反馈查询变得非常稳定，与之前使用 MySQL 时相比，稳定性有了显著提升，几乎无抖动情况。

2、灵活扩展降低高并发压力。OceanBase 的扩展能力可以高效支持业务未来高并发请求，原来 MySQL 只读从库的 QPS 请求，迁移到 OceanBase 后压力骤降，风险得到有效控制。

3、存储成本下降。与 MySQL 单副本对比，OceanBase 整体存储成本下降超过 80%，将上游 MySQL 数据量进行大量归档后，存储成本压缩了 30% 以上，存储压力大幅减少。通过 OMS 迁移 MySQL 数据到 OceanBase 集群，并定期清理 MySQL 的业务数据，大幅降低 MySQL 因数据量过大带来的各种风险。

4、数据实时性得到有效控制。之前在使用 MySQL 作为汇总库时，业务场景中存在大量延迟。引进 OMS 并同步到 OceanBase 后，业务高峰期的延迟最多仅 2s，完全满足业务需求。OMS 的逻辑复制方式读取 MySQL Binlog 操作，回放到 OceanBase 集群中，不会出现 MySQL 常见的主从延迟问题。如果出现数据同步延迟、慢查询，OceanBase 都有对应的监控报告。

5、备份恢复效率提升。在游戏场景中，备份恢复效率至关重要，它决定了网易游戏能否迅速回档或执行关键操作。面对频繁的数据恢复需求，我们深知备份恢复效率的重要性。在采用 OceanBase 后，其恢复效率与原汇总库相比，提升了至少三倍。不仅缩短了游戏回档的效率，更为业务方带来了显著的收益。

6、运维更加简单。出现突发流量时，可以通过动态调整租户、集群资源的方式临时应急。出现突发流量或业务上线 SQL 出现慢 SQL 时，可以使用白屏化的 SQL 限流功能。如果需要水平扩容，整个扩容操作对应用无感。同时，在故障场景下，集群的 Paxos 高可用模式基本保障对应用无感。备份和恢复效率大幅提升，因整体压缩超过 30%，后台替换故障节点时，需要恢复的数据量相对 MySQL 更少。

OceanBase 在网易游戏上线后，不断扩展于其他业务中，包括核心业务，比如在充值系统中替换分库分表以降低架构复杂性和提升扩展能力；在汇总查询业务中解决数据同步延迟问题。

直到 2025 年，随着更多业务测试、试用 OceanBase，规模化的验证让我们体会到创建集群、录入 DB SaaS 以及平台的手动管理等操作繁琐、重复，日常运维变得低效。此外，各个业务人员都登录 DB SaaS 平台进行操作，涉及权限管理的安全隐患，以及大家使用同一个 OCP 账号进行登录查询，存在误操作风险。

基于上述规模化落地 OceanBase 的背景，我们内部产生了三方面的需求，不同角色的需求不同。

• 开发者希望在解决兼容性问题的同时适配业务场景需求，并保证数据安全性；

• SRE 关心试用 OceanBase 的架构成本，以及能否提供多机房的容灾能力，并在发生故障时能够快速定位问题；

• DBA 角度的需求在于提升运维效率，当 OceanBase 规模化落地后能够做好全方位、全阶段的运维管理。

总的来说，我们需要一个流程规范、具备多机房容灾能力和安全及审计能力、能够兼容不同数据库的平台，以完成数据安全的全生命周期管理。因此，我们决定将 OceanBase 生态工具的能力集成到 DB SaaS 中，建设 OceanBase 云平台，提供一站式运维管理能力。以下简要分享建设经验。

在数据库运维的生命周期中，第一步是创建集群。目前我们主要在 DB Saas 平台根据不同需求推出定制套餐，包含测试套餐、高性能套餐、多机房容灾套餐、用户定制化套餐等。我们首先对套餐进行虚拟化，再对其做 CPU 内存和 I/O 的隔离，之后调用 OCP 接口录入机器，进行集群创建、租户创建，最后回到 DB Saas 平台完成信息录入，完成整个集群的创建流程。

在该过程中主要做到三点：一是对接功能完善的 OCP 接口，让 OCP 自行对环境检查和创建；二是调用 OCP 接口完成创建与部署操作；三是与 OCP 深度结合，借用它的能力自动处理集群创建过程中的异常行为。

集群创建后，面临的问题是如何保证数据迁移的兼容性、稳定性。

虽然 OceanBase 已经兼容绝大多数 MySQL 协议，但在特定场景中仍然可能存在风险。同时，若在活动场景中流量突增，确保 OceanBase 能够稳定承载，或者在多备流量场景出现机器异常，其表现能够符合预期，就需要我们提前进行压测以尽可能准确地评估风险。

关于兼容性问题，我们的解决方案是上文提到的流量回放平台和 DMS。借用流量回放平台生成兼容性报告，借用 DMS 平台完成审计。通过这两个平台我们能够做到兼容多种数据库、精细化权限管控、完善数据保护机制。

当数据完成迁移后，我们又来到全方位监控与告警的管理阶段。对于基础监控报警，我们通过轻量级的 Vmagent，采集 OCP，将监控信息采集到统一的存储系统中（Prometheus）。DB Saas 平台从 Prometheus 捞取数据进行多维度展示，便于我们梳理重点监控项进行分级报警。对于偶尔的抖动，我们通过发起秒级探测组件进行报警，同时查看日志，进行全方位分析。

在数据管理的生命周期中，备份恢复有着举足轻重的地位。我们的备份恢复建设主要围绕 OCP 定制化一些备份策略，或在 OCP 平台发起备份再传送到我们自建的 S3 存储系统。想知道备份过程是否存在异常，只需在 DB SaaS 平台拉起 OCP 监控即可。恢复集群也是通过在 DB SaaS 平台调用 OCP 接口，从 S3 存储系统重新拉起备份进行恢复，并观测其进展。

目前网易游戏的云平台建设主要是在 DB SaaS 平台深度集成 OCP，提供企业级运维能力，提升运维效率，除了上述能力外，我们还计划将 obdiag 集成进来，实现一键诊断、一键巡检、智能分析等功能。

总结和展望

网易游戏引入 OceanBase 以来，系统非常稳定，未出现任何性能抖动和同步延迟问题，有效解决了业务痛点。同时，将 OceanBase 的生态工具纳入网易 SaaS DB 平台后，丰富了我们的服务能力，使我们能够为更多的产品提供数据库层面的支持，助力网易游戏更多产品和关键业务发展。

未来，随着 OceanBase 稳定运行，其可靠性和性能得到进一步验证，网易游戏将继续探索 OceanBase 的应用，我们计划逐步减少更多的 MySQL 从库，并考虑将全部业务升级到 OceanBase。