游卡：OceanBase在游戏核心业务的规模化降本实践-编程知识

从 2023 年 9 月测试 OceanBase，到如今 3 个核心业务应用 OceanBase，国内最早卡牌游戏研发者之一的游卡仅用了两个月。是什么原因让游卡放弃游戏行业通用的 MySQL方案，选择升级至 OceanBase？杭州游卡网络技术有限公司（以下简称“游卡”）公共支持中心运维部负责人俞振佳分享了这一数据库替换历程和实践经验。

作为国内最早的卡牌游戏研发者之一，游卡拥有以桌游为代表的线下社交场景和以线上游戏为代表的数字文化场景。核心业务是围绕”三国杀“这一核心IP展开的系列游戏和产品，不过，近年来也在探索和制造三国光环外的爆款游戏，其中一款《自在西游》上线一个月就就突破了 2 亿流水。

在游戏行业，最常见也最流行的数据库产品是 MySQL，但它对于分布式和扩展性的缺失为游戏业务发展带来了限制。以游卡的数据库集群架构（见图 1）来说，该业务架构有三个特点。

图1 游卡数据库集群架构

特点 1：三地两中心，符合三级等保要求。从图 1 可见，这是一个非常典型的传统数据库主备架构。我们在杭州配备了主备机房，在上海机房做容灾，在江苏还有一个离线备份机房。
特点 2：混合云部署，数据在本地。我们将业务部署在云上，但所有数据都存储在 IDC 中，通过企业专线将 IDC 和阿里云打通。这是目前企业业务上云普遍采用的方式，普遍认为数据比较隐私，抓在自己手里才放心。
特点 3：项目多且每个项目至少对应一个数据库集群。我们的游戏项目非常多，不论项目大小，都需要使用至少一套 MySQL 集群，因此架构繁复。

在上述架构特性下，衍生了四个使用痛点。

痛点 1：高可用(MHA)配置复杂，业务实现自动切换困难。举个例子，在一次事故中，我们的主库宕机了，但主从之间因为存在 1~2 秒的延时，从库无法切换到线上，即使切换也会丢失数据。这是因为游戏角色的属性是实时写入数据库中的，每秒钟的并发量都非常高，所以这时无论我们切不切库都无关紧要，已经对线上业务造成灾难了。

痛点 2：扩容困难、维护成本高。图 2 是移动端《三国杀》从 2015 年日志系统上线至今，平均每月日志空间的增长趋势，已经显现出几何倍数的增长态势。我们使用 MySQL 只能依靠迁移或分库分表来实现扩容，增加了大量的维护成本。尤其在业务侧投放商业推广时，迎来数据高峰，若占用大量人力维护分库分表，直接影响我们的投放效益。

图2 移动端《三国杀》数据

痛点3：资源利用率参差不齐。我们知道不可能每一款游戏都是爆款，大部分游戏产品都是非常平淡地走完一生。因此，平淡运行的游戏产品占用的机器 CPU 和内存非常富余，而爆款游戏占用的机器 CPU 和内存严重不足。

痛点4：迁移困难。由于游戏业务特性，我们经常会有一些迁移工作，但 MySQL 提供的 mysqldump 工具的性能和可视化较差，无法显示迁移进度或速度，因此我们不得不选择其他产品。

上述痛点已经困扰游卡多年，如今已成为亟待解决的问题，在多番考察后，游卡选择上线新的数据库方案——原生分布式数据库 OceanBase。下文介绍使用 OceanBase 带来的架构转变和业务收益。

起初，游卡在小范围业务中应用了OceanBase，搭建了一套规格为 3 台 48C/256G/80TB 的生产集群。由于从测试到上线不到一个月，对 OceanBase 操作经验欠缺，因此在部署时遇到了两个小问题。

问题1：数据库内存上限配置

OceanBase 需要根据一些配置项进行数据库内存上限的配置，如 memory_limit_percentage 和 memory_limit。第一次部署 OceanBase 集群的用户往往不会去手动修改这些配置，例如，我们最初使用的 4.2.0 版本就默认只使用机器内存的 80% 当做 OBServer 可以使用的内存上限（因为 memory_limit_percentage 默认值是 80%），这样物理机器就会有 20% 的内存无法被利用。

除此以外，还要给一个虚拟的 500 号租户预留一笔内存，由 system_memory 这个配置项来控制，如果不去手动配置，默认会由系统自动根据当前系统的内存情况来调整 500 号租户的内存使用策略。500 租户是个特殊的虚拟租户，共享性的、非实体租户消耗的内存都被 OceanBase 数据库划归 500 租户里。我们第一次部署环境时，当 256GB 内存的机器上线后，在 OCP 里看到的可以为普通用户租户分配的内存资源只剩 180GB（约等于 256 * 80%（memory_limit_percentage） - 30（system_memory））。后来我们了解到 OceanBase 存在和内存分配相关的一批配置项，通过调整 memory_limit_percentage 和 system_memory 解决了这个问题。

问题2：磁盘空间配置

当事务日志（Clog）和数据共用同一个磁盘时，OceanBase 默认保留 40% 的磁盘空间给 Clog，数据文件只能占用其所在磁盘总空间的 60%。其实，这个比例可以通过 datafile_disk_percentage 等相关的配置项来控制。后面我们通过把数据盘、事务日志盘分别挂载到两个不同的磁盘上解决了该问题。

上述两个问题在不够了解产品时，很容易被忽略。对此，我们的经验是：目前主流的 OceanBase 数据库服务器内存为 384GB 或 512GB，384GB 内存建议配置为使用机器内存的 80%，512GB 内存建议配置为使用机器内存的 90%，这也是 OceanBase 官网显示的最佳配置。并且建议企业用户把数据盘、事务日志盘分别挂载到两个不同的磁盘上，当数据盘独占磁盘时，数据文件默认占用其所在磁盘总空间的百分比为 90%（磁盘空间规划的内容详见该文档。）

上线 OceanBase 后，游卡的业务架构和改造前的 MySQL 架构相似（见图3）。相当于将 MySQL 的主备容灾节点换成了 3 个 OBServer 节点，在每个机房部署了 OBProxy。但受限于社区版，我们没有使用 OBProxy 集群的方案，而是采用了一个比较取巧的方法。我们使用阿里云的 NLB 服务来负载 2 个 OBProxy，这样一来，当我们机房的任何一个节点出现问题时，还可以保证业务在生产环境的可用性。

图3 游卡上线 OceanBase 后的数据库集群架构

此外，我们也使用了较多的 OceanBase 生态配套，包括 OCP（OceanBase 运维管理工具)、OMS （OceanBase 数据迁移工具）、OBAgent（OceanBase 监控工具）、ODC（OceanBase 开发者工具）、OBProxy （OceanBase 专用反向代理）。这些工具和组件，为我们的运维人员提供了简单而高效的操作，进一步减轻了工作人员的负担，同时降低了运维成本。

OCP：简化运维工作，降低运维成本

首先，任何一个新产品的上线都存在学习成本，OceanBase 提供的 OCP 工具可以将黑屏转变为白屏，降低运维学习成本，使传统的集中式数据库 DBA 几乎无门槛转型到了分布式数据库，进一步降低了 DBA 的门槛，使 DBA 更容易上手数据库管理。其次，由于我们的游戏产品众多，每个游戏产品至少配备一个数据库集群，因此一个 DBA 动辄十多个集群需要运维。使用 OCP 平台后，DBA 的管理规模只剩一个后台，管理规模大幅缩减。同时，原本需要在操作系统、平台、客户端等地方进行的账号管理、慢日志分析、监控、备份管理、资源管理、容灾管理，全都集中到一个后台进行，管理工作集中、便捷。

OMS：简单、高效、直观的数据迁移

游卡曾在测试阶段对比了 OMS 和 mysqldump 的迁移性能。mysqldump 的迁移过程涉及导出、压缩、传输、恢复等，操作多且耗时长，且无法可视化，MySQL 生态也没有提供数据校验工具。相较而言，OMS 的迁移过程非常简单，分进程迁移数据后进行校验。从图 4 的迁移性能对比可见，OMS 的迁移效率比 mysqldump 高出很多，从 OMS 后台清晰可见迁移进度和速度。当前，我们已经迁移超过 20TB 数据，OMS 是现阶段最依赖的工具之一。

图4 OMS 和 mysqldump 迁移性能对比

其他工具：OBProxy、OBAgent、ODC

除了 OCP 和 OMS 外，OceanBase 生态的其他组件也相较于 MySQL 更有优势。

OBProxy 相对 MySQL Proxy 来讲，它本身已经集成到了 OCP 的后台，搭配云上的 LB 产品，简单、高效地实现 HA 配置。

OBAgent 替代 MySQL Exporter，搭配 Promethues 和 Grafana 能够平滑接入游卡监控中台，将监控数据集中展示。

ODC 不仅是开发和运维工具，更是协同工具，工单和审核功能让我们非常惊喜，替代了我们原本使用的 Navicat。

除收益外，我们在使用生态工具时，也发现了一些希望 OceanBase 优化的方向。首先是生态工具间的联通，比如目前 OCP、OMS、ODC 的相关操作分布在各自的后台中，我们希望工具间互相打通，只用一个账密和一套后台即可解决运维管理的所有问题。其次，我们希望 ODC 增加编辑表结构、编辑存储过程、数据归档等功能，打破工单结果无法通知的壁垒。

相比新技术对运维管理的助力，企业往往更关心新技术带来的降本和增效。OceanBase 很大程度上提升了游卡的资源利用率，降低了存储成本和硬件成本。

1、存储资源利用率提升

OceanBase 最初打动游卡的是其数据高压缩能力，经过测试，游卡的数据可以压缩到原有数据到 19%~37% 不等（见图 5），且并不会造成性能下降和 CPU 开销的增加。

图5 MySQL迁移到OceanBase后空间对比

而对于硬件成本的节省，经过计算，当前企业采用的固态存储约 450 元/TB，RAID10 后约 900 元/TB，今年预计迁移 20TB 数据，迁移后预计空间 7TB 以内，可以节省成本 (20-7)T*900元/T*3=35100 元。上文提到的业务集群，其数据可用空间大约为 50GB。按照 80% 的文件存储容量计算，我们可以迁移 125TB 左右的数据。那么，一个集群可以为我们节省 20 万元。

2、计算资源（CPU、内存）利用率提升

至于 CPU 和内存利用率的提升，我们可以结合游戏行业的数据库性能指标特点来讲。

游戏行业的从库、容灾库资源利用率低，即使是主库，在大多数时间（90%）内其 CPU 利用率不到 10%。只有游戏每日任务开启时（如凌晨 2 点、上午 10 点时），利用率会达到高峰。不同游戏的高峰期不同，比如 A 游戏集中在 0 点，B 游戏集中在 10 点，而运维人员做数据分析集中在凌晨 3-4 点。

基于游戏业务特点，我们在 OceanBase 中对租户做了一些优化。通过不同租户的 Zone 优先级调整，不同业务的组合，适当超限配置，提高资源利用率。也就是说，我们 CPU 的配置已经超过了数据库拥有的 48 核。用这种方式来提高资源利用率。举个例子，比如 A 项目和 B 项目的高峰都在 0 点，将两个租户的 Zone 优先级分别设置为 Zone 1 和 Zone 2，如果 A、C 项目的高峰分别在 0 和 4 点，则将两个租户的 Zone 优先级全部设置为 Zone 1。

通过这样的方式，我们的资源利用率都处于 10% 以上，从图 6 可见比原来高出很多。

图6 资源利用率对比

通过图 7 的柱状对比也可以看到，我们使用 OceanBase 后，主机的一些 CPU 利用率得到了显著提升。

图7 MySQL 和 OceanBase 主机 CPU 利用率对比

3、服务器成本节约

我们下架了一套 MySQL 集群和一个阿里云的云数据库。图 8 显示了我们采购 MySQL 集群主机和阿里云服务器的配置及成本。也是目前使用 OceanBase 后节省的成本。

图8 使用 OceanBase 节省的成本

目前，游卡从测试到应用 OceanBase 至今三个月余，升级效果显著。未来，游卡会在更多场景中探索 OceanBase 的价值。

场景一：亿级大表性能优化

我们的一款手游项目一天的数据量是 4-5 亿条，在使用 MySQL 时，我们分了 14 张表，共 164 种数据类型，占用 60~100GB 的存储空间。在 OceanBase 中，我们尝试将所有分表的数据重新合并，并将原来的 14 张表按照数据类型转变为 14 个分区。我们进行了插入和读取测试，随机插入 10 万条数据，随机选取 1 万个账号，对随机数据类型进行查询，结果显示查询时间与 MySQL 单表查询耗时基本一致。随着数据量和数据类型的增长，OceanBase 分区带来的管理便捷性愈发明显，因为我们不必担心未来某个表的数据量过大后，再次分表的开销。

场景二：历史库存储降本

我们想使用费用低廉的存储（大容量低转速机械硬盘）搭建历史库，满足历史低频日志数据查询需求。因为游戏行业有一个要求，即厂商对玩家的消费行为等数据能够追溯一年。而事实上，厂商对游戏玩家在 3 个月前的行为查询率较低，如果这部分数据存储在主力集群中，是对存储资源的浪费。因此，我们需要将查询率低的历史数据同步到历史数据集群中，以节省存储成本。而 OceanBase 的存储技术可以使历史库降本达到 50%~95%，我们期待在历史库场景中验证 OceanBase 的价值。

游卡的迁移进度主要分三大部分：第一部分是 3 个已上线的生产业务，其中包含游卡核心项目——三国杀 Online；第二部分是 4 个内部项目，包含监控、审计、CMDB 等内部信息化数据库；第三部分是游卡集团的 IM 项目。在此过程中，我们感谢项目组对运维的信任和对新技术的包容，也非常感谢 OceanBase 社区对我们的支持。

目前已经完成迁移上线的项目，解决了使用 MySQL 时的高可用配置复杂和容灾、扩容等痛点，显著提升了服务器资源的使用率，并以此节省了计算资源的成本。后续，我们会将更多业务上线 OceanBase，希望 OceanBase 能够蒸蒸日上。