认识达内从这里开始

数据库是程序员在学习软件开发后端架构的时候需要重点掌握的重要知识点之一，而今天我们就通过案例分析来了解一下，数据库在游戏开发上的应用都有哪些。

后端

从进程角度来看，后端仅向其他前端和后端服务提供接口。外部客户端无法直接与后端服务通信。后端服务通常为您提供存储和访问数据的方式，例如数据库中的游戏状态数据，或数据仓库中的日志记录和分析事件。

游戏数据库

可能导致玩家退出您的游戏并且不再返回的情况，包括服务器损坏和玩家进度丢失。遗憾的是，如果您的数据库层设计不佳，两者都可能发生。

保存游戏世界的状态和玩家进度数据的数据库，可以说是游戏基础架构中关键的部分。

您对数据库能力的评估，应该是不仅能够处理预期的工作负载，而且能应对在游戏大获成功的情况下需要的工作负载。按照预期的玩家数量进行设计和测试的后端，如果突然收到超过一个数量级的更多负载，就不太可能为任何玩家提供可靠的服务。如果没有规划游戏意外成功所带来的负载，就可能会导致游戏失败，因为当玩家因数据库停机而无法继续参与时，他们就可能会抛弃您的游戏。

游戏特别容易受到这个问题的影响。虽然大多数拥有成功产品的企业都可以期望一种逐步的、有机的增长。但对于游戏业，更常见的模式是游戏刚推出时玩家有很大的兴趣，然后就迅速下降到一个低得多的使用水平。如果您的游戏大热，负担过重的数据库可能会在保存用户进度之前就出现大规模延迟，甚至完全无法保存进度。被迫决定放弃支持某些游戏功能的实时更新，是任何游戏开发者都不希望出现的情况，因此您应该仔细规划数据库资源。

在设计游戏数据库时，请牢记以下几点：

做出明智的决定。 不要因为容易测试而在开发期间使用某个数据库，然后未经评估所有的选项，就让其成为您的生产数据库。重要的是，要了解在您预期的玩家数量基础上，来自您的游戏的数据库访问的类型和频率，以及比预期增大 10 倍的情况。然后，您才可以就哪种后端可以好地处理这些局面做出明智的选择。切勿让自己陷入当数据库危机已经来临，才尝试了解如何应对的境地。

切忌假设一个解决方案是正确的选择。 请记住，您可以同时运行多种类型的数据库。许多成功的游戏用关系型数据库存储帐号信息并处理游戏中的购买操作，同时将游戏状态信息保存在单独的 NoSQL 数据库中。原因在于 NoSQL 数据库可以更好地处理大容量、低延迟的工作负载，而关系型数据库可以提供有保证的事务处理。

备份数据。定期备份和按地理分布进行备份都是从数据库故障中恢复的重要手段。

关系型数据库

许多游戏开发团队在项目起步时会使用一个关系型数据库。当数据和流量增长到数据库性能无法再承受的程度时，他们通常会优先选择扩缩数据库。一旦扩缩不再可行，许多开发者就会实现自定义数据库服务层。在此层中，您可以优先处理查询和缓存结果，因为这两者都会限制对数据库的访问。通过添加扩缩和数据库服务层，您可以生成能够处理大量玩家操作的游戏后端，但这些方法可能会遇到一些常见问题：

扩缩 - 传统关系型数据库专注于向上扩缩(垂直扩缩)的方法。但是，在规划云原生游戏后端时，强烈建议您使用横向扩缩(水平扩缩)方法，因为单个虚拟机中可以存在的核心数量总是有限的，但向您的云项目添加更多虚拟机却很容易。关系型数据库具有水平扩缩的模式，例如分片、集群和分层副本，但是如果没有停机时间，您很难将它们添加到正在运行的数据库中。如果您的流量或数据有任何超过单个数据库性能极限的可能性，您就应该从使用一个小型集群开始。这可避免在危机来临时才去学习如何扩缩数据库。在集群运行时向其添加节点并非简单的任务，但终归是可行的。

架构更改 - 很少有成功的游戏从开始就使用一种数据库架构并在整个游戏生命周期内持续使用。玩家需要新的功能和内容，而添加这些功能和内容就需要将新类型的数据保存到数据库中。在开发过程的早期阶段，您就应该决定如何更新架构。游戏发布之后，尝试在没有固定流程的情况下更新架构可能会导致意外停机，甚至丢失玩家数据。

管理 - 扩缩正在运行的关系型数据库并更新其架构都是复杂的操作。虽然 Cloud Platform 提供了自动托管的关系型数据库等常用服务，但目前在游戏后端，自动托管数据库的采用率很低。这是因为游戏后端有写入密集型的工作负载。

NoSQL 数据库

非关系型数据库可以提供大规模操作的解决方案，尤其适合处理写入密集型的工作负载。但是，它们要求您了解 NoSQL 数据模型、访问模式和事务保证。

当前有许多类型的 NoSQL 数据库，那些非常适合存储游戏世界状态的数据库具有以下特征：

扩缩 - 它们的设计考虑了水平扩缩，并且通常默认使用这种模式。调整集群大小通常是一种无需停机即可完成的操作，但有时在完全集成其他节点之前会有一些性能损失。

架构更改 - 架构是动态的，并由应用层强制执行。这是一个巨大的优势，意味着为新游戏功能添加新字段的影响变得微不足道。

管理 - 大多数云提供商提供至少一个托管 NoSQL 数据存储引擎，但 Cloud Platform 提供多个。

Google Cloud Platform 游戏数据库解决方案

使用 Cloud SQL Second Generation 作为移动游戏后端数据库

在 Cloud Engine 上部署 MongoDB

如何使用热备份设置 PostgreSQL 以实现高可用性和复制

【免责声明】：本内容转载于网络，转载目的在于传递信息。文章内容为作者个人意见，本平台对文中陈述、观点保持中立，不对所包含内容的准确性、可靠性与完整性提供形式地保证。请读者仅作参考。