海量存储、吞吐量可扩展... 游戏开发者关注的数据库长什么样？

游戏开发者越来越关注全托管 NoSQL 云数据库服务。 NoSQL 云数据库服务广泛使用在游戏玩家信息和状态管理、配对、排行榜、装备财产清单、社交、埋点数据捕获与分析等场景，它可以在全球范围内提供更低延迟的多玩家体验，并大幅减少数据库管理运维工作。

《我的世界：地球（Minecraft：Earth）》、《行尸走肉:无人之地（The Walking Dead: No Man’s Land）》、《光环 5：守护者》、《World War Z》、《Magic the gathering: Arena》等游戏，以及 Xbox Live、Windows Store 都采用了 Azure Cosmos DB 数据库服务。

一句话定义：

“Azure Cosmos DB is Microsoft’s globally distributed, horizontally partitioned, multimodel database service.”

Azure Cosmos DB 诞生于 2010 年，目前数以万计的客户使用 Cosmos DB 并将其配置为多区域进行全球复制。Cosmos DB 是用于任何规模的全球分布式多模型 NoSQL 数据库服务。所谓多模型数据库服务，意思是说数据可以以多种不同的方式存储。目前，Cosmos DB 提供 4 种数据模型，开发者可以使用 Azure 原生及开源 API、多种 SDK、自动 SchemaAgnostic 索引、全球分布多主写入、non-ETL HTAP 分析（无需数据抽取即可实现 OLAP）等功能特性，实现简化开发的目标。

Azure Cosmos DB 提供无与伦比的、SLA 财务承诺的性能、可用性和一致性的保证（注意：性能和一致性也有 SLA），即任何规模下 99% 时间内读写响应时间 < 10 毫秒的性能，99.999% 的可用性以及逻辑分区范围内 100%读取请求满足所选一致性级别。Azure CosmosDB 可以自动即时扩展伸缩，可以满足每秒几亿 QPS 的访问请求。

Azure Cosmos DB 引擎使用快照隔，支持满足 ACID 的事务以及乐观并发控制（OCC）。在逻辑分区范围内支持多记录事务，即基于 JavaScript 的存储过程、触发器、UDF 包含的所有数据库读写操作都可以囊括在一个 满足 ACID 事务中，该事务在逻辑分区内的所有记录（项目）之间使用快照隔离。快照隔离可以保证读操作读取的行是事务开始时可用的最后提交版本，保证读取的是已经提交过的数据，并且可以实现可重复读，也能确保不会幻读。

目前市场上大多数商业用途的分布式 NoSQL 数据库只能提供强一致性（Strong）和最终一致性（Eventual）。 Azure Cosmos DB 复制协议提供 5 种一致性级别，按最强到最弱的顺序，一致性级别分别为：强、有限过期、会话、一致前缀、最终。每个级别在可用性与性能方面各有利弊，开发者可以根据需要在 PACELC 定理定义的读取一致性、可用性、延迟和吞吐量之间进行权衡。（请注意，此处所谓一致性，是指分布式数据库多副本之间复制协议的一致性，与 ACID 中的一致性不是一回事。）

Azure Cosmos DB 支持两种备份模式：连续备份和定期备份，支持 30 日以内任意时间点恢复 （PIT Recovery） 。

• Cosmos DB 资源模型

Cosmos DB 的资源模型包括数据库账户（database account）、数据库（database）、容器（container）和记录项目（item）。

用户 Azure 租户订阅下可以创建一个或多个数据库帐户；一个数据库帐户管理一个或多个数据库；Cosmos DB 数据库管理用户、权限和容器，一个数据库管理一个或多个 Container；

Container 管理用户的数据 items（以 JSON 格式）、和基于 JavaScript 的存储过程、触发器和用户定义函数 （UDF）等。

用户可以在 Database 和 Container 上下两个层面配置处理能力资源（CPU, IOPS, 和 Memory ），预配吞吐量(Request Units)。Container 可以提供无限的预配吞吐量 （RU/s） 和存储。 Container 和 item 在不同模型和 API 接口下被投射成不同资源类型。例如，在使用面向文档的 API 时，底层的 container 和 item 分别被投影为集合（Collection）和文档（Document）；对于面向图（Graph）API 访问，底层的 container 和 item 分别投影为图（Graph）、节点（node）和边（edge）；使用 Key-Value API ，底层的 container 和 item 分别投影为表（table）和行（row）。

• Cosmos DB 全球分布系统拓扑

Cosmos DB 服务部署在全球所有 Azure 区域。如下图所示，我们从宏观到微观来

逐步了解它的拓扑架构。

Cosmos DB 部署在 Azure Service Fabric 之上，使用 Service Fabric 进行命名、路由、集群和容器管理、滚动升级协调、故障检测、领导者选举和负载平衡功能。 CosmosDB 部署在一个或多个 Service Fabric 群集中，每个群集都可能运行多代硬件和不同数量的机器（在 60-800 台机器之间）。

Azure Service Fabric 是微软的开源项目，它是 Azure 分布式系统基础架构管理服务。Azure Cosmos DB、Azure SQL 数据库、Azure Event Hubs、Azure Data Factory、Dynamics 365、Skype for Business、Intune、Cortana 等都使用 Service Fabric 作为控制平面进行调度控制管理。Service Fabric 提供云规模的高可用性和持久性服务，从本质上了解应用程序的可用基础架构和资源需求，支持自动扩展、滚动升级和故障发生时的自我修复。

部署 Cosmos DB 服务的每台服务器都有专用的本地 SSD。 与远程存储相比，本地 SSD 存储提供无与伦比的性能，可以提供<10 微秒的延迟和几百万 IOPS。集群中的机器通常分布在 10-20 个故障域（Fault Domain）中。每个故障域包含若干机架，它们共享电源供给和网络交换机，多副本部署于多故障域保证同一区域（Region） 内硬件故障情况下集群的高可用。

每台服务器上运行成百上千个 replica，replica 通过动态负载均衡放置在每台服务器上。每个 replica 都托管一个 Cosmos DB 数据库引擎的实例，数据库引擎管理资源以及关联的索引。Cosmos DB 数据库引擎由组件包括：资源管理器、JavaScript 语言运行时、查询处理器、复制状态管理（RSM）、索引管理器、存储引擎、日志和 IO 管理器等。为了提供持久性和高可用性，数据库存储引擎将数据以及索引持久化存储到本地 SSD，并且在多个 Replicas 上进行备份。

Container 是一个逻辑概念，相当于一个表、文档数据库的集合（Collection）或图（Graph）。Container 对 Schema 完全不可知，它只提供了一个查询范围。数据加载如 Cosmos DB 的 Container 会被自动索引。Azure Cosmos DB 使用分区来横向扩展 Container，以满足性能需要。Container 通过 hash 分区键（Partition Key）进行数据分布，相同 partition key 的 item 分布在一个逻辑分区（Logic Partition），每个 logic partition 存储最大 20GB 数据（设计选择 partition key 时需要注意）。一个或多个 logic partition 映射到底层物理分区（physical partition），物理分区由系统自动管理，对用户是透明的。用户 container 对应的 physical partition 数量由预配吞吐量（RU/s）和存储的数据容量决定，每个 physical partition 的限制为 10000RU/s 和 50GB 数据，物理分区的总数量没有任何限制。

物理分区（physical partition）由一组跨多个故障域的自我管理和动态负载平衡的副本（replica）实现，称为副本集（replica-set），其中包括 1 个 leader、2 个 follower 和 2 个 forwarder。也就是说，一份数据有 4 个副本，所以读取数据用一个 1RU 的话，写入则需要 5 个 RU。每个物理分区跨地理区域复制，实现跨区域冗余。全球分布只读 replication 实现了就近读取数据；全球分布多主写入（Multi-Master）

replication 则实现了就近写入数据。实现 Multi-Master 的关键是解决冲突（Conflict），包括：insert conflicts、replace conflicts、delete conflicts。Cosmos DB 提供 Last WriteWins （LWW）和自定义冲突解决策略。

基于上述 Cosmos DB 全球分布系统架构，Azure Service Fabric 通过 partition 实现了 Cosmos DB 几乎无限的计算和存储容量横向扩展。Cosmos DB 快速的、SLA 支持的<10ms 的数据读写性能，还和底层数据结构和索引设计有关。

• Cosmos DB 数据结构与索引

Cosmos DB 将 JSON 数据构建成树（tree），直接对 tree 进行读写操作（而不是关系数据库中的行和列）。JSON 与 XML 不同，XML 有 Schema 规格定义说明，JSON 没有 schema 定义。Cosmos DB 将 JSON 数据的标签（label）与值（value）融合在一起构建树，label 作为树的子 interior node, value 作为树的 leaf node，同时增加一个虚拟 root。

Cosmos DB 对树的每一个 path 进行自动索引，无论 JSON 数据是 10 层嵌套，还是 1 层键值对，系统处理是一样的。因此，规范化的路径表示是自动索引和查询子系统实现的基础。索引与 JSON 数据的映射有两种，正排索引映射（forward index mapping）和倒排索引映射（inverted index mapping）。forward index 维护一个（document id, path）方向的元组映射；inverted index 维护一个（path, document id）方向的元组映射。Forwardindex 适合范围或不等式条件的查询，例如过滤或排序。inverted index 则适合点读。

对模式不可知（SCHEMA AGNOSTIC）数据自动索引是 Cosmos DB 独特的机制，它满足了各种条件查询<10ms 的快速性能，而无需开发者设计 secondary indexes，从而简化了开发。

• 总结

Comos DB 是业界第一个也是唯一一个具有完整且立即可用的全球分布式数据库。它提供海量存储和吞吐量的可扩展性能力，99.999%的高可用性，<10ms 的访问延迟，原生支持大规模不同类型的数据，定义明确的 5 种一致性模型，以及领先的 Non-ETL HTAP 能力。

很多知名游戏公司已经借助 Azure 平台的强大能力将产品成功推广到海外市场并逐渐站稳了脚跟，您不想试试？

欢迎点击这里免费试用Azure，让更多海外玩家沉浸在你的游戏世界中。