Microsoft AZ-305: 数据存储与数据库解决方案 — 学习指南

By Laurynas Brazys · 11 August 2026 · #microsoft #az-305 #certification #exam-prep #study-guide

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

概述

在 Azure 上设计数据存储时，需要在多种数据库和存储选项之间权衡一致性、延迟、可用性、运营复杂性和成本。该平台涵盖了完全托管的关系型数据库、全球分布式的 NoSQL、具有数据生命周期治理的对象存储、高吞吐量的分析数据湖以及内存中缓存。您的架构设计应从工作负载特征入手——例如事务性与分析性、全球覆盖与本地性、模式刚性、读/写模式、规模和速度——然后选择能够匹配这些约束条件的服务和配置，同时满足安全性、弹性和治理要求。

Azure 上的关系型数据服务

Azure SQL Database 提供两种购买模型。DTU 模型将 CPU、内存和 I/O 组合成一个混合单元，横跨 Basic、Standard 和 Premium 层级；它简单但对于容量规划不透明。vCore 模型将计算、内存和存储分离，提供硬件选择、可预测的扩展以及 Azure Hybrid Benefit 和预留容量等成本杠杆。在 vCore 模型下，主要的服务层级包括 General Purpose（计算与远程存储分离，成本均衡）、Business Critical（带有 Always On 副本的本地 SSD，用于低延迟 I/O 和快速故障转移）和 Hyperscale（采用页面服务器和分布式存储的日志结构化架构，用于 TB 级规模和基于快照的快速操作）。General Purpose 的 Serverless 模式可在配置的最小和最大值之间自动扩展计算资源，并在空闲时自动暂停；您按计算秒数和存储量付费。这非常适合间歇性或开发工作负载，但在恢复时会产生冷启动和缓存预热。

弹性池（Elastic pools）允许多个数据库共享一个计算预算和 I/O 预留空间，从而为许多负载多变的小型数据库平滑峰值并降低成本。DTU 和 vCore 模型中都存在池；正确的规模调整需要了解聚合并发度和每个数据库的突发限制，以避免“吵闹邻居”效应。

Azure SQL 的弹性模式包括活动异地复制（active geo-replication）和自动故障转移组（auto-failover groups）。活动异地复制在任何 Azure 区域异步维护最多四个可读的辅助数据库，故障转移按数据库启动。自动故障转移组跨配对的逻辑服务器将多个数据库作为一个单元进行管理，提供读/写和只读侦听器终结点，并处理计划内或计划外故障转移，且宽限期可配置——这对于多租户 SaaS 来说是理想选择。区域冗余（Zone redundancy）在 Business Critical（和 Hyperscale）层级中可用，可跨越一个区域内的多个可用区（Availability Zones），从而提高区域内容错能力。

Azure SQL Managed Instance (MI) 的目标是实现近乎 100% 的 SQL Server 兼容性（SQL Agent、跨数据库查询、Linked Servers、CLR、Service Broker）。它在您的虚拟网络内部一个专用的委托子网（Microsoft.Sql/managedInstances）上运行。实例仅使用私有 IP；配置网络安全组和路由表，以允许管理流量流向 Azure 控制平面，并允许数据流量流向您的应用程序。与 Azure Private DNS（或自定义 DNS）集成，以便客户端能够解析托管实例的私有 FQDN。对于混合连接和迁移，请确保通过站点到站点 VPN 或 ExpressRoute 建立直接连接。迁移路径包括原生备份/还原到 Azure Blob Storage (WITH COPY_ONLY, WITH MOVE)，使用 Azure Database Migration Service (DMS) 进行在线或离线迁移，以及在适当情况下使用事务复制或日志传送。MI 的 Business Critical 层级增加了低延迟存储和高可用性；General Purpose 层级通过远程磁盘提供经济高效的存储。

Azure Database for PostgreSQL 和 MySQL Flexible Server 提供了对维护时段的精细控制、用于节省成本的启停功能，以及通过 VNet 集成实现的网络隔离。高可用性选项包括用于实现最快故障转移的同区同步备用，以及可抵御区域性故障的区域冗余高可用性（zone-redundant HA）（采用自动故障转移的同步复制）。读副本（区域内，且对于许多版本也支持跨区域）可分流读取工作负载并支持近实时分析；它们是异步的，不适用于严格一致性读取。根据 IOPS/延迟目标选择计算和存储层级，并规划好客户端库中的连接故障转移处理。

非关系型和全局分布式存储

Azure Cosmos DB 是一种完全托管、多模型、全局分布式的数据库，提供一站式全局复制功能，并在 99% 的延迟下实现个位数毫秒级的读写。根据生态系统适配度和数据模型选择 API：Core (SQL) API 用于文档和类 SQL 查询，并提供丰富的 SDK 支持；MongoDB API 用于 Mongo 线路协议兼容性；Cassandra API 用于宽列工作负载；Gremlin API 用于图遍历；Table API 用于键/属性场景。吞吐量以请求单位 (RU) 的形式进行预配，可使用固定或自动缩放模式；设计分区和索引以最小化 RU 消耗。

分区是基础。选择一个高基数的分区键，该键能均匀分布存储和流量，避免热点分区，并与您的访问模式（例如，用于多租户写入的 tenantId 或 userId，或用于平衡读取的合成复合键）保持一致。逻辑分区在大小和吞吐量上有限制；建模时应保持热点工作集呈分布式。容器的分区键在创建后无法更改；迁移需要创建新容器并移动数据。

Cosmos 的一致性涵盖五个可调级别：强（可线性化，RU/延迟最高）、有限延迟（可预测的延迟或版本窗口）、会话（以客户端为中心的“读己之写”，流行的默认设置）、一致性前缀（无乱序读取）和最终（最大可用性和性能，但可能存在异常）。按帐户选择默认级别，并在需要时按请求覆盖。多区域写入可实现真正的多主模式，以实现低延迟的全局写入和更高的可用性；通过“最后写入者获胜”（基于指定属性）、自定义策略或使用存储过程和冲突源的应用程序逻辑来处理冲突解决。

在选择正确的数据存储时，需将需求与功能相匹配。严格的关系完整性、复杂联接和事务保证倾向于选择 Azure SQL Database 或 Managed Instance。大规模全局扩展、灵活的架构和低延迟的地理访问倾向于选择 Cosmos DB。图问题（社交、推荐、网络拓扑）适合使用 Cosmos DB Gremlin API，或者当关系共置有益时，可使用 Azure SQL 中的图功能。高吞吐量时序遥测、即席探索和近实时分析与 Azure Data Explorer 相符。非结构化 Blob、媒体和大型二进制负载应存放在 Azure Blob Storage 或 ADLS Gen2 中，其元数据则存放在一个补充数据库中。

对象和分析存储

Azure Blob Storage 是非结构化数据的基础。访问层将存储成本与访问模式对应起来：热层用于频繁访问，冷层用于不频繁访问（至少保留 30 天），存档层用于长期冷存储（至少保留 180 天，再水化需要数小时）。基于 SSD 的高级块 Blob 帐户可为摄取管道等工作负载提供低延迟、高事务处理能力。生命周期管理策略根据规则（最后修改时间、Blob 索引标记或前缀）自动执行数据转换和删除，从而在无需人工干预的情况下降低成本。

块 Blob 的对象复制功能可在存储帐户之间（在相同或不同区域）异步镜像对象及其版本。它要求源和目标都启用 Blob 版本控制，并按容器对由策略驱动，支持合规性和多区域分发，同时保持与帐户级冗余选择的独立性。不可变性 (WORM) 可在容器或 Blob 范围通过基于时间的保留策略和法定保留来强制执行，并提供如 allowProtectedAppendWrites 等选项用于仅追加日志。版本级不可变性可保护过去的状态免遭篡改和勒索软件攻击。

Azure Data Lake Storage Gen2 为 Blob 存储添加了分层命名空间，提供了真正的目录、原子性重命名和优化的文件操作。细粒度的类 POSIX ACL 可在目录和文件级别控制访问，包括访问 ACL 和默认 ACL，并与 Azure RBAC 一同进行评估。使用 Azure AD 和 OAuth2 进行身份验证，以实现最小权限和可审计性。与分析服务的集成是原生的：Azure Synapse Analytics 和 Azure Databricks 通过 ABFS 驱动程序访问 ADLS Gen2，具有可扩展的吞吐量；而 Azure Data Factory、Azure Purview 和 Azure Machine Learning 等服务则集成了编排、治理和模型训练功能。设计文件夹结构和 ACL 继承以隔离不同领域并支持多团队治理，并利用更改源和软删除等功能进行数据沿袭和恢复。

缓存和性能加速

Azure Cache for Redis 提供亚毫秒级数据访问、发布/订阅和分布式锁功能。各层级对应不同的可用性和扩展需求。基本层是用于开发/测试的单节点。标准层增加了具有自动故障转移功能的主/副本双节点。高级层引入了跨分片集群、持久化 (RDB 快照和 AOF)、VNet 支持以及主动-被动拓扑的异地复制。企业层和企业闪存层 (Redis Enterprise) 使用 CRDTs 增加了用于多区域写入的主动-主动异地复制、更大的内存占用、多线程性能和模块支持；闪存层通过 NVMe 增强 DRAM，以更低成本实现海量缓存。根据键的 TTL 和工作负载选择逐出策略：当并非所有键都有 TTL 时，使用 allkeys-lru/allkeys-random；当只有带过期时间的键应被逐出时，使用 volatile-lru/volatile-ttl；当写入失败比逐出键更可接受时，使用 noeviction。持久化以 I/O 和延迟开销为代价，减少了故障转移时的数据丢失；仅在需要时启用，并调整快照间隔。

将 Redis 集成为用于数据库查询结果、会话状态和速率限制计数器的旁路缓存。确保幂等填充，应用合适的 TTL，并实施断路器。对于集群缓存，应确定性地分片键；对于企业层的主动-主动模式，需测试冲突解决语义。

安全性、访问和弹性模式

Azure Storage 访问委托使用 SAS 令牌和策略。服务 SAS 授予对特定资源（容器、blob、文件共享、队列或表）的范围性访问权限。账户 SAS 跨越账户中的多个服务，功能强大；请务必妥善保护。用户委托 SAS（仅限 Blob 服务）源自 Azure AD 和用户委托密钥，可实现基于用户的访问控制，无需账户密钥——非常适合多租户应用程序和短期授权。存储访问策略（在容器、共享、队列和表上）将 SAS 令牌绑定到服务器端策略，这样你就可以在不轮换账户密钥的情况下撤销或缩短访问权限；没有存储访问策略的 SAS 只能通过令牌过期或轮换密钥来撤销。

在加密方面，Azure Storage 默认使用服务器端加密。存储在 Azure Key Vault 或 Managed HSM 中的客户管理的密钥 (CMK) 提供了集中的密钥生命周期控制和可审计性。加密范围允许在同一存储账户内按容器或前缀使用不同的 CMK，从而支持按租户进行密钥管理。对于按 blob 的客户端控制，可以在请求中提供客户提供的密钥 (CPK)。根据需要，在账户或范围级别将 CMK 与 CPK 结合使用，以实现法规要求的隔离。

Azure SQL 的安全性和弹性建立在前面已描述的平台层级和复制功能之上。使用自动故障转移组进行协调的跨区域故障转移和专属侦听器端点，并在可用时启用区域冗余以抵御区域性故障。对于敏感数据，应用动态数据屏蔽来对非特权用户的查询结果中的 PII 进行模糊处理，并考虑使用带安全 enclave 的 Always Encrypted 对列进行客户端保护，以防止管理员查看明文。根据你所在层级的复制行为监控 RPO/RTO 目标，并定期测试故障转移。

在规划端到端架构时，统一身份（将 Azure AD 用于 SQL、存储和分析），通过 RBAC 和 ACL 应用最小权限原则，使用 Private Link 或 VNet 集成将数据保留在公共互联网之外，并实施生命周期、不可变性和复制策略以满足保留和 DR 目标。

实际问题场景

Contoso Retail 正在启动一个全球电子商务平台，该平台具有不稳定的日间流量、严格的 PII 控制、PB 级的产品媒体数据和近乎实时的个性化需求。他们要求全球范围内的低延迟读取、最小化的停机时间以及受治理的数据分析。

1. 使用 vCore 模型将事务性目录和订单数据库放置在 Azure SQL Database 上：

• 层级选择：订单使用 Business Critical（低延迟存储和快速故障转移），目录使用 General Purpose 无服务器（应对流量突发和空闲窗口）。
• 原因：vCore 提供可预测的规模和混合优势；Business Critical 满足订单的延迟/HA 要求；无服务器模式可在低活动期间最大限度地降低计算成本。

2. 为两个数据库配置跨配对区域的自动故障转移组，并启用区域冗余：

• 原因：统一的读/写侦听器简化了应用程序的故障转移；区域冗余可防止区域性中断；跨区域副本满足 DR 要求并为报告提供读取扩展能力。

3. 将产品图片和视频存储在 Azure Blob Storage (general-purpose v2) 中，并配置生命周期管理和对象复制：

• 策略：活跃项目使用 Hot 层，30 天后转为 Cool 层，180 天后转为 Archive 层；通过对象复制功能复制到次要区域。
• 原因：随时间推移最大限度地降低存储成本，同时提供独立于账户冗余的异步区域分发；通过对法律资产使用不可变性（基于时间的 WORM）来满足保留要求。

4. 在 Azure Cosmos DB (Core API) 上构建客户资料和购物车服务，并启用多区域写入和会话一致性：

• 设计：按 userId 分区以分散写入；启用自动缩放 RU。
• 原因：多主模式为全球用户提供低延迟写入和高可用性；会话一致性确保每个用户“读己之写”，提供强大的用户体验保障和高效的 RU 使用率。

5. 引入 Azure Cache for Redis Enterprise 用于会话状态、产品详情缓存和速率限制：

• 模式：使用 Active-Active 地理分布的集群模式，以支持多区域写入。
• 原因：亚毫秒级访问和基于 CRDT 的冲突解决方案可确保会话和计数器在没有单一写入主节点的情况下跨区域保持一致。

6. 将点击流和操作日志存入具有分层命名空间和 POSIX ACL 的 Azure Data Lake Storage Gen2：

• 集成：流式摄取将数据写入经整理的文件夹；Databricks 和 Synapse 通过 ABFS 读取；启用更改源和软删除。
• 原因：精细的目录/文件 ACL 支持多团队治理；分层命名空间优化了文件操作；原生分析集成缩短了获得洞察的时间。

7. 为推荐微服务使用 Azure Database for PostgreSQL Flexible Server：

• HA：区域冗余的同步备用节点；预配只读副本用于功能实验。
• 原因：丰富的 Postgres 扩展生态系统和 JSONB 功能非常适合该服务；托管的 HA 保持了较低的 RTO；副本分担了读取负载。

8. 通过用户委托 SAS 保护临时媒体上传，并使用带加密范围的 CMK 实现按租户加密：

• 原因：消除了账户密钥的暴露风险，并实现了按租户的加密隔离和可审计性。

9. 将本地 SQL Server 的旧订单数据迁移到 Azure SQL Managed Instance，用于归档处理和代理驱动的任务：

• 步骤：使用 Data Migration Assistant 进行评估；通过 DMS 执行在线迁移；通过 ExpressRoute 连接。
• 原因：MI 保留了 SQL Agent 作业和跨数据库操作，简化了现代化改造，同时使归档工作负载靠近云端数据。

此设计通过 Cosmos DB 多区域写入和 Redis Enterprise 满足了全球性能要求，通过 ADLS Gen2 ACL 和 Storage 不可变性强制执行了治理，通过 Azure SQL 层级和自动故障转移组提供了事务完整性和快速故障转移，并通过无服务器计算和生命周期策略优化了成本。

← 身份、治理与合规 · 所有领域 · 计算与应用架构 →

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

浏览 Microsoft →