编者按：自2023年9月起，游卡------国内最早卡牌游戏研发者之一，开始测试OceanBase，并在短短两个月内成功将三个核心业务应用迁移至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带来的架构转变
部署：内存与磁盘配置。
目前，我们在部分业务中上线了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带来的降本增效
对于企业而言，相比新技术为运维管理带来的好处，更关心新技术带来的降本和增效。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优先级分别设置为ZONE1和ZONE2，如果A、C项目的高峰分别在0和4点，则将两个租户的ZONE优先级全部设置为ZONE1。
通过这样的方式，我们的资源利用率都处于10%以上，从图6可见比原来高出很多。
图6 资源利用率对比
通过图7的柱状对比也可以看到，我们使用OceanBase后，主机的一些CPU利用率得到了显著提升。
图7 MySQL和OceanBase主机CPU利用率对比
3、服务器成本节约。
我们下架了一套MySQL集群和一个阿里云的云数据库。图8显示了我们采购MySQL集群主机和阿里云服务器的配置及成本。也是目前使用OceanBase后节省的成本。
图8 使用OceanBase节省的成本
目前我们从测试到应用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能够蒸蒸日上。