Amazon DynamoDB：谈游戏用例与设计模式

Original URL: https://amazonaws-china.com/cn/blogs/database/amazon-dynamodb-gaming-use-cases-and-design-patterns/

当前，游戏企业在游戏平台上的各个层面都在广泛应用Amazon DynamoDB——从游戏状态、玩家数据、会话记录再到排行榜皆在此列。在DynamoDB的支持下，游戏厂商能够将各项功能以非常可靠的方式扩展至数百万并发用户，同时始终保持稳定的低延迟表现（毫秒级）。另外，作为一项全托管服务，DynamoDB不会带来任何运营开销。这意味着游戏开发人员能够专注于游戏设计工作，而不必分神于数据库管理。如果游戏开发商希望将现有应用从单一AWS区域扩展到多个区域，则可依靠DynamoDB的全局表功能实现跨多个区域的主-主数据复制。

在本篇文章中，我们将具体了解游戏企业在DynamoDB服务使用中的部分常见用例及设计模式。

本文中使用的术语

在本篇文章中，我将使用以下几个数据建模术语：

• 1:1建模：使用分区键作为主键，进行一对一关系建模。
• 1:M建模：使用分区键与排序键作为主键，进行一对多关系建模。
• N:M建模：使用分区键与排序键作为主键，配合表及全局二级索引进行多对多关系建模。

游戏用例与设计模式

用例：游戏状态与玩家数据存储

利用DynamoDB存储玩家的游戏状态及其他数据，将帮助游戏厂商支撑大量的并发玩家，同时始终保持毫秒级别的访问延迟。以电子艺界（又称艺电，EA）公司为例，这家大型视频游戏厂商在全球拥有超过3亿注册玩家。对EA而言，高达数百万的每日活跃用户将带来每秒超10万条请求，这无疑代表着极高的并发度。与原有数据库MySQL集群相比，EA在迁移至DynamoDB之后将成本降低达90%。EA通过DynamoDB将游戏状态、用户数据以及游戏库存数据保存在多个表内。此外，EA还使用用户ID作为分区键与主键（1：1建模模式）。

大型多人在线角色扮演游戏《战斗营地》的开发商PennyPop选择了DynamoDB支持这款游戏，灵活实现从每分钟几项请求到每秒种高达8万项请求的业务规模扩展。由于DynamoDB是一项全托盘服务，因此PennyPop公司的小型开发团队得以专注于游戏设计本身，而不必分神于运维工作。此外，与传统的托管，分片的MySQL数据库相比，DynamoDB每年至少为PennyPop节约50%运营成本。单从工作负载强度来看，不使用DynamoDB的话，PennyPop将需要把三名服务器工程师增加至六名，才能运行相同负载的游戏环境。

设计模式：要在DynamoDB当中存储数据，游戏厂商需要通过玩家ID对游戏状态及其他玩家数据进行分区，而后采用键-值访问模式（1：1建模）。如果需要更进一步的细粒度访问，厂商则可使用排序键（1：M建模）。如此一来，他们就能分别访问并更新玩家数据集内的不同属性与子集。这意味着系统不必检索整个数据集。通过这种方式，DynamoDB事务API将以事务性方式为不同属性更新并存储多个条目。部分厂商还会压缩用户数据以进一步降低存储成本。例如，PennyPop就利用gzip压缩器将数据存储为base64字符串形式，从而将玩家数据的体积降低至原始大小的十分之一。

用例：玩家会话历史记录数据存储

游戏开发商将会话历史记录与其他面向时间的数据存储在DyanmoDB当中，以便随时按玩家、日期以及时间执行快速查找。例如，Riot Games旗下的《英雄联盟》在世界各国广受好评，日均生成高达TB级别的玩家数据，而全部玩家会话历史记录都被存储在DynamoDB当中。以此为基础，玩家支持团队即可快速查找与特定玩家相关的所有信息，例如玩家的游戏内购买记录与上次登录时间。这部分数据此前被存储在Vertica当中，虽然这种作法有利于数据分析，但却不利于单键查找。这导致单一查找操作往往需要数分钟时间。Riot Games决定使用DynamoDB以改善查找性能，因此将所有数据从Vertica复制至DynamoDB，并在DynamoDB当中为所有用户数据及历史记录创建物化视图以支持快速查找功能。在DynamoDB的帮助下，查找时间由此前的几分钟缩短到现在的一秒以内。

设计模式：为了在DynamoDB中存储玩家会话历史记录以及其他面向时间的数据，游戏厂商通常会使用玩家ID作为分区键，并选择日期及时间（例如上次登录时间）作为排序键（1：M建模）。通过这样的架构，游戏厂商即可通过玩家ID及日期/时间高效访问每位玩家的数据；进而针对特定日期与时间选择单一记录，或根据针对特定日期与时间范围选择一组记录，轻松实现定制化查询。

用例：排行榜

游戏开发商可以使用DynamoDB轻松支持较为简单的排行榜功能。其中一大典型用例就是通过排行榜显示游戏中的最高得分。如果游戏厂商已经在DynamoDB当中存储有玩家的游戏状态（包括玩家的最高得分），则可通过使用全局二级索引直接提取最高分数值。

设计模式：首先按玩家ID对存储表进行划分，再使用此表存储玩家的游戏状态（包括将最高得分作为属性保存），即可通过全局二级索引建立起排行榜功能。索引将使用游戏ID或名称作为分区键，再使用top-score最高分属性作为排序键（N：M建模）。具体细节请参阅《DynamoDB开发人员指南》中的“全局二级索引”部分。

总结

在本文中，我们探讨了游戏厂商最常用的几种DynamoDB用例与设计模式。通过DynamoDB Accelerator（简称DAX）提供的强大最终一致性支持选项，DynamoDB得以支持多条目ACID事务、原子计数器与内存缓存等功能，从而满足游戏应用中的诸多常见需求。

关于AWS上游戏设计模式的更多细节信息，请参阅AWS可扩展游戏模式简介文档。此外，关于在AWS上开发游戏的其他资源，请参阅Amazon Game Tech文档。当然，大家也可以直接在评论区中留言，或在DynamoDB论坛上发布新的讨论主题。

本篇作者