Microsoft AZ-104: Azure 数据库和数据服务 — 学习指南

By Laurynas Brazys · 7 August 2026 · #microsoft #az-104 #certification #exam-prep #study-guide

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

概述

Azure 的数据库和数据服务涵盖托管的关系型引擎、全球分布式的 NoSQL、内存中缓存、大规模分析以及集成/编排。作为管理员，您必须了解购买模型、服务层、网络和安全拓扑、备份/灾难恢复 (DR) 语义，以及如何组合服务以实现性能、成本和弹性的优化。本节重点介绍您日常配置的操作选项和平台功能：预配模型 (DTU vs vCore)、弹性池、备份和长期保留、异地复制和故障转移、VNet 注入的托管实例、Cosmos DB 的分发和一致性、开源关系型数据库的高可用性 (HA)/只读副本、Synapse 引擎以及 Data Factory 运行时。

Azure 关系型数据库 (SQL Database, Managed Instance, MySQL/PostgreSQL)

Azure SQL Database 提供两种购买模型。DTU 模型将 CPU、内存和 IOPS 捆绑到数据库事务单位 (Database Transaction Units) 中，分为 Basic、Standard 和 Premium 层；该模型简单但不透明，适用于稳定、可预测的工作负载和传统的规模估算。vCore 模型则公开了 CPU 代系/数量和内存，并配有存储和 IOPS 控制。vCore 实现了规模估算的透明度，并支持 Azure Hybrid Benefit 和 Reserved Capacity 折扣。在 vCore 模型中，服务层对应不同的工作负载和可用性模式：General Purpose 使用远程高级 SSD 或 Azure 高级存储，采用标准可用性体系结构；Business Critical 将计算和存储置于具有多个副本的本地 SSD 上，延迟低，并集成了读取横向扩展功能；Hyperscale 通过页面服务器将计算和存储分离，以实现近乎即时的扩展和支持超大型数据库。对于单一数据库，无服务器计算层 (vCore) 可以弹性扩展 CPU，并能自动暂停以削减空闲成本。

弹性池在多个数据库之间共享计算资源，以更低的总成本吸收突发性、异相的工作负载。弹性池有 DTU (eDTU) 和 vCore 两种变体。您可以为每个数据库设置最小/最大上限以控制“吵闹的邻居”，并设置池的最大值来控制开销。当突发负载持续时间短且不相关时，超额订阅是可以接受的。池的规模取决于总平均消耗量加上为并发性预留的空间；监控每个数据库和池的指标对于维持服务级别目标 (SLO) 至关重要。

备份是自动的。Azure SQL 维护完整备份、差异备份和事务日志备份，支持在保留窗口（通常为 7-35 天，具体取决于服务层和存储配置）内进行任意秒级的时间点还原 (PITR)。长期保留 (LTR) 可将每周的完整备份在 RA-GRS 存储中持久化数年；您可以将 LTR 备份还原为同一订阅和区域集内任何服务器上的新数据库，如果启用了异地冗余备份存储，则还可进行跨区域还原。还原操作会创建一个新数据库，而不会就地覆盖。

异地复制选项包括用于单一数据库和池的活动异地复制（最多四个采用异步复制的可读辅助副本），以及在逻辑服务器范围内的自动故障转移组。故障转移组将多个数据库（或整个服务器）与异地灾难恢复 (geo-DR)、一个读写侦听器终结点、一个用于卸载读取操作的只读终结点、基于运行状况的自动故障转移以及基于 DNS 的重定向捆绑在一起。Business Critical 层还通过一个本地可读副本提供读取横向扩展功能，从而能够即时卸载读取工作负载，而无需处理跨区域的复杂性。

Azure SQL Managed Instance (MI) 提供近乎 100% 的 SQL Server 引擎兼容性，包括 SQL Agent、跨数据库查询、CLR、链接服务器、Service Broker 以及从 Azure Blob Storage 对 .bak 文件进行本机备份/还原。MI 是 VNet 注入的：您需要将其部署到一个具有私有 IP 和 NSG/UDR 控制的专用、委托子网中；请预先规划子网大小和地址空间，因为之后调整子网大小会很复杂。迁移路径包括 Azure Database Migration Service（支持联机/脱机直接转换）、将本机备份/还原到 URL 以导入 MI，以及从本地 SQL Server 到 MI 的事务复制。当您需要与 SQL Server 保持功能层面的一致性或需要单一数据库不提供的实例范围功能时，应选择 MI。

Azure Database for MySQL 和 Azure Database for PostgreSQL (Flexible Server) 提供托管的开源 (OSS) 引擎，并允许您控制维护时段、通过停止/启动来节省成本、使用可突发和通用计算、存储自动增长以及 VNet 集成。Flexible Server 通过同步复制提供高可用性；您可以选择跨可用区的区域冗余 HA 以获得更强的故障隔离，或选择同区 HA 以降低写入延迟。只读副本可用于横向扩展读取，并且可以在区域内或跨区域进行预配；它们使用异步复制，非常适合分析、报告或读取密集型微服务。在需要时，您可以提升一个副本以进行故障转移或区域扩展，但需注意可能存在的复制延迟。

分布式数据与缓存 (Cosmos DB 和 Azure Cache for Redis)

Azure Cosmos DB 是一个全球分布式、多模型数据库，为 Core (SQL)、MongoDB、Cassandra、Gremlin (graph) 和 Table 提供 API。API 的选择决定了客户端驱动程序的兼容性和数据模型的语义；在操作层面，无论使用哪种 API，您都需要管理吞吐量（预配的 RU 或自动缩放）和分区。数据通过分区键进行水平分区，该分区键必须具有高基数和均匀的访问分布，以避免热点分区；应避免使用单调递增的键，并在存在复合访问模式时考虑使用分层分区键。支持跨分区查询，但会消耗更多 RU；在可能的情况下，应通过分区键将相关数据并置。

一致性级别可在账户、数据库或请求级别进行调整：强一致性 (Strong) 保证线性一致性；有界过期 (Bounded Staleness) 按时间或版本限制过期的程度；会话 (Session)（默认）为会话提供“读己之写”；一致性前缀 (Consistent Prefix) 保证顺序，但非完全一致；最终一致性 (Eventual) 最大化可用性和性能。对于多区域写入，选择适当的冲突解决策略（“最后写入者获胜”(LastWriterWins) 或通过存储过程自定义）并定义故障转移优先级。全球分发功能只需单击即可添加区域；该服务负责处理复制、故障转移和延迟优化的路由，并提供关于吞吐量、延迟、可用性和一致性的 SLA。

Azure Cache for Redis 提供由 Redis 支持的亚毫秒级延迟。各层级的功能逐步增强：Basic（单节点，用于开发/测试）、Standard（具有 SLA 的复制式双节点主/从结构）、Premium（更大的规格、群集、持久化、VNet 注入、异地复制以及 Redis 模块如 Bloom）、Enterprise 和 Enterprise Flash（基于 Redis Enterprise，具有高级群集、用于多主写入的主动异地复制以及由闪存支持的更大型缓存）。逐出策略定义了在内存压力下的行为：noeviction（写入时报错）、allkeys-lru/lfu/random（考虑所有键）和 volatile-lru/lfu/ttl/random（仅考虑设置了 TTL 的键）。对于会话缓存，如果不能承受会话丢失，请使用 Premium 或更高层级以实现持久化，启用键的 TTL 来限制增长，并考虑使用群集来提高吞吐量和规模。将缓存放置在与应用服务器相同的区域和虚拟网络中以最小化延迟；使用托管标识或访问密钥，并通过 Private Link 或 VNet 注入来强制实施网络隔离。

分析与集成 (Synapse Analytics 和 Data Factory)

Azure Synapse Analytics 统一了数据仓库、大数据和数据集成。专用 SQL 池（前身为 SQL DW）是一个 MPP 引擎，具有哈希/轮循分布、复制表和结果集缓存。您可以纵向扩展或缩减计算资源以满足 SLA 时间窗口，并可以暂停以仅支付存储费用。可以使用工作负载组和重要性设置来实现工作负载隔离，以保护关键查询。无服务器 SQL 池无需预配即可对 Azure Data Lake Storage Gen2 中的数据提供按需 T-SQL 查询；您按扫描的 TB 数付费，并可以使用视图将模式外部化以构建语义层。Spark 池将 Apache Spark 引入 Synapse，提供自动缩放和按需集群，支持 notebook、Delta Lake 和机器学习，并集成了安全性和数据沿袭；您可以在 Spark 和 SQL 引擎之间共享 lakehouse 数据。

Azure Data Factory (ADF) 负责编排数据移动和转换。管道 (Pipeline) 协调各种活动 (Activity)，例如复制 (Copy)、数据流 (Data Flow)（基于 Spark 的映射流）以及外部计算（Databricks、Synapse、Functions）。数据集 (Dataset) 定义数据的结构和位置，而链接服务 (Linked Service) 则封装连接到源/目标的详细信息（身份验证、终结点）。集成运行时 (IR) 提供计算和网络平面：Azure IR 用于云原生数据移动和转换，自承载 IR (Self-hosted IR) 用于通过出站 HTTPS 连接本地或专用网络中的源，Azure-SSIS IR 用于直接迁移 (lift-and-shift) SSIS 包。触发器（计划、翻转窗口、事件驱动）可实现可重复的编排；可以启用托管虚拟网络和专用终结点以防止数据外泄并实现合规连接。参数化和 Key Vault 集成支持可重用、安全的模式，用于环境提升（开发/测试/生产）。

业务连续性、异地功能与弹性池

备份和还原策略因服务而异，但有几个共同的主题：自动化、定期测试还原，以及将用于操作错误的 PITR（时间点还原）与用于合规性的 LTR（长期保留）分开。在 Azure SQL 中，使用 PITR 来应对意外删除或部署失败；将 LTR 的每周完整备份存储在 RA-GRS 中，以满足法规保留要求和跨区域灾难恢复的还原需求。对于 MySQL/PostgreSQL 灵活服务器，在支持的情况下启用带有异地冗余存储的自动备份，根据策略设置保留期，并验证到备用服务器的时间点还原。拥有多个区域的 Cosmos DB 账户可启用自动故障转移；当 RPO 必须为零且应用程序能够确定性地解决冲突时，应结合多区域写入使用。

Azure SQL 中的异地复制和自动故障转移组提供灾难恢复（DR）和读取分流功能。当你希望显式管理辅助副本时，对单个数据库/池使用活动异地复制；使用自动故障转移组来组合多个数据库，并获得基于 DNS 的侦听器以及自动故障转移功能。在低延迟读取很重要但灾难恢复不是目标的情况下，使用业务关键型（Business Critical）的读取横向扩展或超大规模（Hyperscale）的命名副本，将分析和报告工作负载从主副本上分离出去。监控复制延迟和故障转移健康信号，并进行故障转移演练测试，以验证 RTO/RPO。

弹性池是针对多租户 SaaS 和大量小型数据库进行成本优化的杠杆。在基于 DTU 的池中，分配 eDTU 并设置每个数据库的上限；在基于 vCore 的池中，分配 vCore、内存和 IO 吞吐量，并设置每个数据库的最大 vCore 数和 IO 治理规则。通过衡量每个数据库第 95 百分位的使用率，并将池容量与并发模式对齐来进行适当的规模调整；为具有更高 SLO 的租户提高每个数据库的上限，并考虑按工作负载类别（例如，重度与轻度租户）拆分池。对池和每个数据库的限制使用警报，以尽早检测饱和状态。当少数数据库持续达到最大上限时，将它们迁移到专用计算资源或单独的池中，以保持可预测性。

实践问题场景

星巴克需要对其全球忠诚度平台进行现代化改造，以应对促销期间的流量高峰，减少运营开销，并在不中断全球门店运营的情况下支持分析。

对操作数据存储进行分区：

选择 Azure Cosmos DB (Core SQL API) 来处理客户互动和奖励事件，以实现低延迟的全球分发。在靠近主要客户群体的区域配置多区域写入，并将一致性级别设置为会话（Session）一致性，以在“读己之写”和性能之间取得平衡。选择一个高基数的分区键，如 customerId 或复合层次键 (customerId, eventMonth)，以分散吞吐量并支持常见的查询模式。

部署 Azure SQL Managed Instance 来处理账户余额、兑换和 SKU/目录，因为需要近 100% 的 SQL Server 兼容性以支持现有的存储过程和跨数据库逻辑。根据 VNet 注入的要求，将 MI 放置在专用的、已委托的子网中，并配置所需的 NSG 和路由表，从而实现从应用子网和 ExpressRoute 的私有访问。

为关系型工作负载提供全局读取扩展和灾难恢复：

对于使用 Azure SQL Database 的新微服务，使用 vCore 业务关键型（Business Critical）层级以实现低延迟和读取横向扩展。创建一个到配对区域的自动故障转移组，并配置只读侦听器端点，以支持本地化读取并实现自动故障转移，从而满足 DR 目标。

添加低延迟会话管理：

部署具有群集和数据持久化功能的 Azure Cache for Redis Premium 版，用于存储 Web 和移动会话令牌。设置 allkeys-lfu 逐出策略，以保留频繁访问的会话。将缓存与应用层集成在同一 VNet 和区域内，以最大限度地减少延迟。

编排数据移动并构建分析平台：

使用 Azure Data Factory 将操作数据（来自 Cosmos DB 更改源和 SQL MI）复制到 Azure Data Lake Storage Gen2。采用带有私有端点的托管 VNet IR，以防止数据泄露。对管道进行参数化，并使用翻转窗口触发器来保证有序处理。

通过弹性成本控制启用企业级分析：

在 Azure Synapse Analytics 中，使用无服务器 SQL 池对 Parquet 数据进行即席探索，并使用专用 SQL 池为需要可预测性能的、高并发的 BI 模型提供服务。创建 Spark 池用于对忠诚度行为进行特征工程，并在数据湖中写入 Delta 表，以实现 Spark 和 SQL 之间的互操作性。

治理、备份和保留：

配置 Cosmos DB 自动故障转移的优先级，并使用带有时间戳字段的“最后写入者获胜”（LastWriterWins）策略来监控冲突。对于 Azure SQL Database 和 MI，验证 PITR 窗口并启用 LTR 以满足合规性保留要求。对于支持辅助性 OSS 服务的 Flexible Server 实例（例如，在 PostgreSQL 中记录区域门店遥测数据），启用区域冗余 HA 并配置读取副本以用于报告。

为何选择这些服务：Cosmos DB 的全球分发和可调一致性解决了全球范围内的延迟敏感型交互；MI 在提供托管运维的同时保留了复杂的 SQL Server 功能；业务关键型（Business Critical）数据库提供了本地读取扩展能力，而没有跨区域延迟；Redis 确保了流量高峰期间亚毫秒级的会话访问；ADF 提供了从私有网络进行安全、受治理的数据移动；Synapse 混合了按需和预配的分析能力，以实现经济高效、可扩展的洞察。这一组合在促销期间满足了性能 SLO，通过托管的 PaaS 减少了管理工作，并强制执行了明确的 RTO/RPO 和合规性边界。

← Azure App Service 和 PaaS 计算 · 所有领域 · Azure Monitor、备份和站点恢复 →

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