Microsoft AZ-204: Azure Cosmos DB — 学习指南

By Laurynas Brazys · 5 August 2026 · #microsoft #az-204 #certification #exam-prep #study-guide

属于 Microsoft Azure Developer Associate AZ-204 — 学习指南. 使用经过验证的答案练习： Microsoft 考试中心, 或参加限时模拟考试： ExamRoll.io.

概述

Azure Cosmos DB 是一种完全托管的全球分布式多模型数据库，专为低延迟、弹性可扩展的应用程序而设计。它在一个通用的、分区的存储和复制引擎之上公开多种 API，提供五种可调的一致性级别，并为可用性、延迟、吞吐量和一致性提供全面的 SLA。数据被组织成帐户、数据库和容器（或根据 API 不同，称为集合/表/图）。容器通过分区键进行水平分区和扩展，所有操作都以请求单位 (Request Units, RU) 来计量，这是一种标准化的货币，它抽象了 CPU、IOPS 和内存的消耗。

API 和可编程性

Cosmos DB 支持多种线路兼容的 API，因此您可以使用原生 SDK 和驱动程序，而无需重写数据模型：

• SQL (Core) API：推荐用于新工作负载的默认 API。存储 JSON 文档，支持丰富的、类似 SQL 的查询（SELECT、WHERE、ORDER BY、文档内 JOIN、聚合）以及用于计算谓词/投影的确定性 UDF。服务器端业务逻辑以 JavaScript 存储过程和前/后触发器的形式在单个逻辑分区内运行，从而能够在共享同一分区键的多个项目上实现 ACID 事务。TransactionalBatch 在一个分区内提供多项目操作。点读取（id + 分区键）是 RU 效率最高的操作。使用类似

undefined

的代码创建一个 .NET 客户端。

• MongoDB API：与 MongoDB 线路兼容，允许使用标准的 MongoDB 驱动程序和工具（例如，使用 mongodump/mongorestore 进行迁移）。您可以使用由 Cosmos DB 的分发、自动缩放和 SLA 提供支持的 MongoDB 功能。在同一逻辑分区内支持多文档事务；为了实现严格的每用户原子性，请使用未分片的集合，或按诸如用户名的属性进行分片，以使相关文档共享一个分区。

• Cassandra API：与 Apache Cassandra 驱动程序和 CQL 兼容。非常适合宽列和时间序列访问模式。您可以获得自动全局分发和基于 RU 的扩展，而无需进行节点管理。

• Gremlin API：属性图模型，支持 TinkerPop Gremlin 查询和遍历。分区对于分发顶点和边以实现可扩展的遍历至关重要。

• Table API：键值存储，具有与 Azure Table Storage 兼容的 SDK 和语义，但由 Cosmos DB 的全球分发、RU 吞吐量和更低延迟的索引提供支持。

跨 API 的通用 SDK 操作包括 CRUD、使用 ETags 的乐观并发、upsert、服务器端脚本（存储过程、触发器）和 UDF (SQL API)。查询是参数化的，以减少 RU 消耗并提高安全性。批量操作和流式 API 可最大限度地减少客户端开销和 RU 成本，以实现高吞吐量的数据引入。

一致性、索引和查询语义

Cosmos DB 每个帐户提供五个明确定义的一致性级别（在许多 SDK 中可按请求覆盖）：

• Strong（强）：线性一致性——读取操作在全球范围内能看到最近提交的写入。最大化正确性，但限制了写入延迟和区域灵活性，并且在启用多区域写入时不可用。

• Bounded Staleness（有界过期）：读取操作落后于写入操作最多 K 个版本或 T 段时间。保证单调读取和写入顺序；对于能够容忍有界延迟的全球分布式读取来说，这是一个很好的权衡。

• Session（会话）（默认）：每个会话内实现“读己之写”、“写后读”和单调读取。每个客户端维护一个会话令牌；在节点间共享它（例如，通过 SDK 中的请求选项）可以在这些节点间保持“读己之写”。

• Consistent Prefix（一致性前缀）：读取操作永远不会观察到乱序的写入，但可能会看到日志的前缀部分。

• Eventual（最终）：最高的可用性和最低的延迟，但不提供顺序保证。

对于 SQL API，索引默认是自动且一致的。每个项目和属性都被索引，无需管理架构，因此写入会立即更新索引（索引模式为 Consistent）。您可以优化索引策略以：

• 排除大型或写入密集型路径以降低写入的 RU 成本。
• 添加复合索引以支持对多个属性的高效 ORDER BY 操作，以及组合了跨不同属性的筛选和排序的查询。
• 为 GeoJSON 类型（Point、LineString、Polygon、MultiPolygon）添加空间索引，并使用 ST_DISTANCE、ST_WITHIN 和 ST_INTERSECTS 等空间函数进行查询。 对于仅通过 id/分区键读取的写入优化型容器，索引模式也可以设置为 None。不同的 API 通过其原生范式公开索引功能（例如，MongoDB 和 Cassandra 驱动程序构造），但都利用了底层的 Cosmos 索引引擎。

注意项目大小和查询形态。SQL API 强制执行项目大小限制（例如 2 MB），跨分区查询、大型投影和复杂谓词会增加 RU 消耗。使用选择性投影、适当的筛选器和分区感知的查询来最小化 RU 成本。

分区和吞吐量 (RU)

Cosmos DB 区分逻辑分区和物理分区：

• 逻辑分区按分区键值对项目进行分组。共享相同键的所有项目会一起参与事务性批处理和服务器端脚本。
• 物理分区由服务管理，并托管许多逻辑分区。吞吐量 (RU) 和存储分布在各个物理分区上；“热”逻辑分区可能会成为物理分区吞吐量的瓶颈。

选择一个具有高基数和随时间均匀分布的访问模式的有效分区键。好的键应与您的主要访问路径相关联（例如，userId、deviceId、tenantId 或 orderId）。避免使用会导致偏斜的低基数或按时间分桶的键（例如，country、status 或 day）。当没有单个属性适合时：

• 使用连接多个属性的合成键。
• 追加一个随机或哈希后缀以将负载分散到各个分区，同时通过前缀查询或维护查找表来保持可查询性。
• 考虑使用分层分区键来组合多个属性，从而实现更好的分布和高效的前缀查询。

吞吐量模型：

• 预配吞吐量：在容器或数据库（由子容器共享）上预留 RU/s。性能可预测，成本稳定。可手动或通过 API/CLI 进行扩展。
• 自动缩放：设置最大 RU/s；Cosmos DB 会根据负载在该最大值的 10% 到 100% 之间弹性伸缩。按每小时使用的最高 RU 计费；非常适合可变工作负载和未知峰值。
• 无服务器：无预配 RU/s；按操作的 RU 消耗量付费。是开发、突发性或没有可预测基线的低吞吐量工作负载的理想选择。

RU 优化技术包括通过 id+分区键进行点读取、参数化查询、选择性投影、通过反规范化来减少类 JOIN 模式，以及使用更改源生成派生视图，而不是进行复杂的多容器查询。使用带有 If-Match 的 ETag 进行并发控制，以避免耗费大量 RU 的重试。监控 RU 指标和限制 (HTTP 429)，并在 SDK 中实施带抖动的重试策略。

全球分发与变更源

Cosmos DB 的一站式多区域分发功能让您可以随时添加或删除区域。所有区域都是可读的；启用多区域写入后，可在任何地方进行并发写入，并在邻近区域实现 99% 的读取延迟低于 10 毫秒。客户端 SDK 应配置首选区域，以便将流量路由到本地并平滑地进行故障转移。在 .NET 中，通过 CosmosClientOptions 的 ApplicationPreferredRegions（或其他 SDK 中的等效项）提供首选区域。多区域写入需要一个冲突解决策略：

• 最后写入者获胜：使用一个冲突解决路径（例如，时间戳或版本属性）。如果未指定，则可以使用系统时间戳。
• 自定义解决：使用一个合并存储过程来确定性地协调冲突。
• 手动：检查冲突源并显式解决。

变更源为每个逻辑分区键提供一个有序的、仅追加的变更日志。它非常适用于：

• 事件驱动架构和 CQRS（将文档投影到读取优化的视图中）。
• 下游管道（数据湖引入、搜索索引、缓存失效）。
• 近实时分析与审计。 主要有两种使用模式：
• 变更源处理器库：分布式、容错的处理方式，它使用一个租约容器在工作进程之间平衡分区并安全地横向扩展。
• 使用 FeedIterator 的拉取模型：通过您自己控制的检查点逻辑显式迭代变更；跨 FeedRange 分割工作以实现并行化。 Azure Functions 提供了一个 Cosmos DB 触发器，它为无服务器处理封装了处理器模式。您可以从头开始或从“现在”开始，全保真变更源会捕获中间更新和删除，以提供完整的审计跟踪。设计您的租约容器时，应确保其具有足够的吞吐量，并选择幂等的处理程序以适应重试和至少一次的交付保证。

实际问题场景

Spotify 需要提供一个全球可用的个性化服务，该服务能实时引入用户交互，更新每个用户的推荐，并从最近的区域提供低延迟读取。写入可能来自全球各地的移动客户端，并且推荐更新必须扇出到下游系统。

1. 选择 Cosmos DB SQL (Core) API 并启用多区域写入

• 原因：Core API 提供丰富的查询和服务器端可编程性。多区域写入可最大限度地减少全球写入延迟，并能在区域性故障期间容忍写入停机。

2. 定义一个高基数分区键和分层键

• 方法：按 userId 分区；对于极其活跃的用户，使用分层键，例如 [“userId”, “bucket”]，其中 bucket 是一个哈希后缀。
• 原因：均匀分发写入和读取负载，支持按用户进行事务性更新，并避免热分区。

3. 在主容器上配置自动缩放吞吐量

• 原因：流量具有昼夜节律且受活动驱动；自动缩放可以处理高达配置的最大 RU/s 的突发流量，同时使成本与实际负载成正比。

4. 在账户级别将会话一致性设置为 Session

• 原因：移动客户端需要“读己之写”以获得良好的用户体验，同时又没有 Strong 一致性带来的延迟限制。会话令牌由客户端和网关层携带，以在节点间保持会话语义。

5. 使用 Azure Functions 和变更源处理器实现变更源处理

• 方法：创建一个带有 Cosmos DB 触发器的 Functions 应用，该触发器绑定到交互容器。使用一个专用的租约容器，并启用多个实例以实现并行处理。
• 原因：这提供了弹性的、可扩展的、低运维的处​​理能力，用于更新物化视图（例如，推荐容器）并将事件发布到 Event Hubs 以进行流式分析。

6. 创建一个具有定制索引策略的派生推荐容器

• 方法：从索引中排除大型、写入密集型的属性；为 (userId, score DESC) 添加复合索引以支持 TOP-K 查询。
• 原因：在降低 RU 写入成本的同时，实现高效的排序查找，以支持个性化信息流。

7. 在 SDK 中启用全球分发并配置首选区域

• 方法：在北美、欧洲和亚太地区添加区域。根据应用的部署区域，使用 ApplicationPreferredRegions 配置 CosmosClientOptions。
• 原因：确保读取在本地提供，以实现低于 10 毫秒的延迟，并使故障转移对应用透明。

8. 配置冲突解决与可观测性

• 方法：使用“最后写入者获胜”策略，并配合一个服务器生成的逻辑时钟（版本属性）来实现幂等更新，同时将冲突路由到监控队列以处理罕见的边缘情况。
• 原因：在并发多区域写入下保证确定性收敛，并提供运营可见性。

该架构提供了全球低延迟的读写、通过变更源实现的弹性事件处理、经济高效的自动缩放，以及适用于个性化工作负载的强大一致性语义。

← Azure 存储与 Blob 存储 · 所有领域 · Azure 容器解决方案 →

练习这些题目 → · 在 ExamRoll.io 上限时练习 →

浏览 Microsoft →