客户说｜承载日均亿级请求PolarDB点亮手游《迷失蔚蓝》上云之路

作者：任超，原力棱镜数据组组长

北京原力棱镜科技有限公司是国内知名的“出海”游戏研运商（以下简称“原力棱镜”），拥有《迷失蔚蓝》等系列产品，并致力于打造新颖的游戏体验，为全球玩家提供极致服务。

《迷失蔚蓝》是原力棱镜自主研发的高自由度海岛生存MMO手游。随着游戏运营时长及用户量的增长，原有自建数据库存储和运维成本日益上升，通过阿里云瑶池旗下的云原生数据库PolarDB多主集群技术优势，提高存储利用率，缩减运维成本。

《迷失蔚蓝》迁移至PolarDB多主集群后，与此前自建数据库模式相比，游戏服的数据库访问性能大幅提升，例如游戏合服速度相比自建提升3~4倍，同时数据库成本明显下降，并且满足数据库高可用性的需求。

《迷失蔚蓝》最早使用开源MySQL基于云主机自建数据库，存储所有的玩家数据，但是随着游戏业务的长线运营，我们逐渐发现自建数据库难以满足如下需求：

• 降本增效：自建方案没有办法在不增加成本的情况下，继续提升访问性能、运维效率、以及加固数据库安全；
• 提升高可用和容灾能力：自建方案MySQL版本低、可维护性差，游戏业务又是准7x24小时的在线业务，无法继续提升高可用容灾能力；
• 实现技术架构升级：自建方案不能灵活支撑业务高峰弹性扩容和低峰弹性合服，不能持续跟进云数据库发展的红利，实现总成本TCO持续降低。

我们的技术团队经过近半年调研、选型和测试，最终选择阿里云瑶池旗下的云原生数据库PolarDB多主集群作为核心数据库解决方案，替代原有的自建数据库。游戏服数据库迁移到PolarDB多主集群后，多个游戏服访问PolarDB多主集群的1个主节点。

▶︎ 原有自建部署架构：

游戏服与MySQL 5.5自建数据库分别部署云主机，运维人员需要自助管理和监控MySQL实例的运行状况，自助处理数据库故障。

▶︎ 迁移到PolarDB多主集群架构：

• 原先每个Region下相互独立的MySQL实例转变为一整套PolarDB多主集群架构，多主集群基于数据池化实现主主互备，每个主节点不再冗余一个独占的备节点。
• 使用PolarDB多主集群计算存储分离架构，内置适配游戏业务的高性能优化，实测在相同资源下单个主节点支持更大TPS能力，因此多主集群中的每个主节点能够支撑多组游戏服。
• 管理员也不再单独管理多个小集群，转为使用全局视图管理整个集群，游戏数据库负载可以随时通过主动维护命令秒级切换主节点。

在整个实际使用过程中，我们对PolarDB多主集群的主主互备、高性能、无感弹性能力的使用感受最为深刻：

1. 成本更优 —— 无需冗余备用资源

自建MySQL的主从复制方案，从节点冗余100%计算和存储资源随时准备接管主节点。使用PolarDB MySQL多主集群在计算存储分离架构基础上实现多个主节点读写同一套共享存储，节点之间主主互备，不再需要冗余计算存储资源，相比自建MySQL方案极致降低50%的数据库资源成本，实现“单节点的成本，主备的高可用”。

2. 性能更优 —— 单个节点承载更大的业务负载

我们的游戏业务是典型的写密集型负载，处理游戏逻辑的游戏服会定期将变化的数据批量写入数据库，并且随时玩家数据增长单次写入的负载持续上升，数据库的响应时间（RT）和工作负载的处理能力（TPS）至关重要。自建MySQL写入操作必须写入RedoLog和Binlog两份数据库日志才能完成提交，而PolarDB MySQL多主集群无需打开Binlog（备份恢复、主从复制仅需要RedoLog）使得写入RT时间降低的同时TPS大幅提升，实现单个主节点承载更多的游戏服业务负载。

3. 弹性运维 —— 无感开服与合服

我们游戏业务的另一个特点是弹性负载，业务高峰期负载高，比如：

1）游戏推广期，买量用户蜂拥而至；

2）维护停机后开服，很多玩家等待多时集中上线；

3）重大版本上线或有重要活动，推广效果超预期时，大量老玩家回归。

然而，进入平稳期后又会因为玩家流失，数据库负载开始走低。使用PolarDB多主集群后，通过主动维护命令10s内即可完成主节点间负载切换，游戏服可以无感弹性进行开服与合服。

原力棱镜使用PolarDB多主集群以来，每天支撑游戏服上亿次的用户请求：

• 主主互备满足了数据库高可用性需求，同时数据库总成本TCO降低50%。
• 游戏服的数据库访问性能得到大幅提升，既带来了更优良的游戏玩家体验，也使得运维管理更加便利，例如游戏采用脚本合服速度相比自建提升3~4倍。
• 无需停机即可弹性开服合服。