Amazon DOP-C02: 存储、数据库和数据管理 — 学习指南

By Laurynas Brazys · 4 August 2026 · #amazon #dop-c02 #certification #exam-prep #study-guide

属于 AWS DevOps Engineer Professional DOP-C02 — 学习指南. 使用经过验证的答案练习： Amazon 考试中心, 或参加限时模拟考试： ExamRoll.io.

概述

AWS 上的存储、数据库和数据迁移在设计时必须考虑持久性、可用性、成本效益和自动化。精通 S3 存储类和复制、DynamoDB 容量和全局分发、RDS/Aurora 配置控制和备份模式、内存中缓存、共享文件系统以及数据迁移服务，有助于构建可靠、低延迟、恢复行为可预测且支出可控的系统。

Amazon S3：存储类、生命周期、智能分层和复制

S3 存储类将成本与访问模式对应起来：

• Standard：多可用区、低延迟、无检索费用。热数据的默认选择。
• Intelligent-Tiering (S3 INT)：多可用区，可在频繁访问层和不频繁访问层之间自动分层，并提供可选的存档层。每个对象收取监控和自动化费用；小于 128 KB 的对象不会被自动分层。存档访问层和深度存档访问层是可选的，有最后访问时间阈值；从非频繁访问层检索会产生费用。
• Standard-IA 和 One Zone-IA：存储成本较低但有检索费用；有 30 天的最低存储计费。One Zone-IA 是单可用区，适用于可重新创建的数据。
• Glacier Instant Retrieval：毫秒级访问，具备存档级别的经济性；最少存储 90 天。
• Glacier Flexible Retrieval：检索时间为几分钟到几小时，提供批量/标准/加急选项；最少存储 90 天。
• Glacier Deep Archive：检索时间为几小时到 12 小时；最少存储 180 天。 在考虑最低存储期限费用、检索费用和所需访问时间的同时，选择可行的最冷存储层。

生命周期策略使用筛选条件（前缀、标签）来自动执行转换和过期操作，以实现精细化控制。关键操作包括在达到不活动阈值后转换到 IA/Glacier 层、在启用版本控制的存储桶中转换/过期非当前版本、过期删除标记，以及中止未完成的分段上传。当需要不变性时，生命周期和对象标签与 S3 Object Lock（治理/合规模式）一起使用，对于强制执行数据保留和可审计的删除至关重要。

当访问模式未知或可变时，Intelligent-Tiering 是理想选择。它能保持性能（从频繁/IA 层检索无延迟），在模式变化时无需重新设计架构，并且可以根据最后访问时间选择性地自动存档到深度层，为具有零星访问模式的长期数据集提供了敏捷性和成本控制的最佳组合。

S3 复制提供对象的持久、异步副本：

• 要求：在源和目标存储桶上启用版本控制。复制配置定义了目标存储桶/账户/区域、按前缀/标签筛选、元数据复制（ACL、标签、S3 Object Lock）、存储类，以及是否复制删除标记和现有对象。
• 同区域复制 (SRR)：满足合规性/数据主权要求、日志聚合、跨账户的原子化处理。
• 跨区域复制 (CRR)：灾难恢复 (DR)、降低延迟、全球分发、合规性。
• KMS 加密的对象：必须允许复制角色使用源 KMS 密钥解密，并使用目标 KMS 密钥加密。在复制规则的 EncryptionConfiguration 中指定副本的 KMS 密钥。对于跨账户复制，更新目标存储桶策略以允许复制角色写入。
• 现有对象：使用 S3 Batch Replication 进行回填。
• 复制时间控制 (RTC)：为复制完成增加了一个 15 分钟的 SLA，并提供复制指标和通知来监控 SLA。对合规性和严格的 RPO 很有用。
• 所有权和访问：跨账户时，启用“存储桶拥有者优先”或强制“存储桶拥有者”的对象所有权，以避免 ACL 的复杂性，并确保目标账户拥有副本。

AWS 上的数据库：DynamoDB、RDS 和 Aurora

DynamoDB 容量模式和扩展：

• 按需模式：无需容量规划；按请求定价；非常适合不可预测或突发的工作负载以及流量未知的新表。
• 预置模式：通过 DynamoDB Application Auto Scaling 根据目标利用率设置 RCU/WCU；适用于稳定或可预测的流量以及成本控制。
• 自适应容量：自动将分区吞吐量重新分配给热键，但极端的热分区仍需要负载均衡（例如，写入分片）。GSI 具有独立的容量；需仔细建模以避免节流。
• 项目大小影响容量：每 1 KB 写入消耗 1 WCU；每 4 KB 强一致性读取或每 8 KB 最终一致性读取消耗 1 RCU。

DynamoDB Streams 和 DAX：

• Streams 捕获项目级别的变更，保留期为 24 小时。可选择视图类型以包含 NEW/OLD 镜像。常见模式：用于 CQRS/事件驱动写入的 Lambda 触发器、跨表同步和审计跟踪。顺序按分区键保证，交付语义为至少一次。
• DAX 是一个托管的、API 兼容的 DynamoDB 内存缓存，可显著降低读取延迟。它支持最终一致性读取；强一致性读取必须绕过 DAX。它为项目变更提供穿透写入（write-through）和基于 TTL 的失效机制。使用多可用区集群实现高可用性，并将 DAX 子网置于靠近客户端的位置。

DynamoDB 全局表：

• 使用 Streams 实现的多区域、多主节点复制，基于系统时间戳采用“最后写入者获胜”的冲突解决方法。设计时应避免跨区域并发更新相同属性，或在应用程序侧实现对账。
• TTL 属性作为普通项目数据进行复制；由 TTL 驱动的删除在每个区域单独处理，不会作为显式删除操作进行复制。
• 备份和 PITR（时间点恢复）是区域范围的；需在每个区域恢复到新表，并（可选地）重新创建为新的全局表。

Amazon RDS 配置和备份：

• 参数组定义引擎参数。静态参数需要重启；动态参数在支持的情况下会立即应用。对实例级引擎使用数据库参数组，对 Aurora 使用集群参数组。
• 选项组用于启用引擎原生功能（例如，Oracle TDE/OEM、SQL Server 原生备份/恢复、MySQL/MariaDB 插件）。某些选项可能需要重启引擎；需谨慎管理变更窗口。
• 自动备份可在保留窗口（最长 35 天）内实现 PITR（时间点恢复）。它们会捕获每日快照和事务日志到 S3；恢复操作会生成新的实例。
• 手动快照会一直保留直到被删除，可跨区域复制，并可跨账户共享（对于加密快照，需遵守 KMS 密钥权限）。使用跨区域快照复制作为灾难恢复（DR）的种子。

Amazon Aurora 的特性：

• 端点：集群（写入器）端点始终指向主实例以进行写入。读取器端点在副本之间进行负载均衡。自定义端点可以选择一部分读取器，用于分层读取池或专门的工作负载。始终将写入指向写入器端点，将读取指向读取器/适当的自定义端点，以在故障转移期间最大程度地减少中断。
• Serverless v2：无需重启即可实现 ACU 的精细、即时扩展。它在 Aurora 集群内运行，支持混合使用 Serverless 和预置实例，非常适合突发工作负载、开发/测试或需求不均的多租户应用。由于其连续扩展的特性，它比 v1 能更好地保持连接一致性。
• 克隆：在区域内进行快速的写时复制（copy-on-write）克隆，用于开发/测试、数据科学或蓝/绿变更验证。克隆在空间上是高效的，仅在页面发生更改时才会产生差异。可以链式克隆；完成后删除以回收存储空间。

缓存和共享文件系统：ElastiCache 和 EFS

ElastiCache for Redis vs Memcached：

• Redis：支持高级数据结构、复制、发布/订阅（Pub/Sub）、Lua 脚本、流（streams）、地理空间、有序集合以及通过快照实现持久化；支持多可用区自动故障转移和用于跨区域只读副本的 Redis Global Datastore。当需要丰富的数据类型、持久性（快照恢复）或带故障转移的高可用性时，选择 Redis。
• Memcached：简单、多线程、无复制或持久化；通过客户端分片进行横向扩展；无状态且易于水平扩展。当需要用于吞吐量极高的临时、纯粹缓存，并且希望在客户端控制分片时，选择 Memcached。 Redis 集群模式和复制组：
• 集群模式禁用：一个分片，包含一个主节点和多个副本；通过只读副本进行垂直扩展或有限的水平扩展。
• 集群模式启用：跨多个主分片进行哈希槽（hash-slot）分片，每个分片都有副本，可实现近线性的横向扩展。复制组定义主/副本拓扑和多可用区故障转移。备份是按复制组进行的；测试故障转移以验证 RTO。

Amazon EFS 用于共享 POSIX 文件：

• 挂载目标：在 VPC 的每个可用区中创建一个，以确保可用区内的访问路径和可用性。挂载目标上的安全组控制 NFS 流量；如果需要，可使用 EFS 挂载帮助程序实现传输中 TLS 加密和 IAM 授权。
• 访问点：为应用程序强制指定根目录和 POSIX 身份（UID/GID），从而实现多租户隔离，并让 ECS/EKS/EC2 能够以简单、最小权限的方式挂载，无需协调操作系统用户管理。
• 生命周期管理和存储类：EFS Standard 和 Standard-IA（区域性、多可用区）以及 One Zone/One Zone-IA（单可用区）。智能分层会根据上次访问时间自动在标准和 IA 类之间移动文件；您也可以设置显式的转换策略。对于可重新创建或非关键数据，选择 One Zone 变体以节省成本。与 AWS Backup 结合使用，可实现集中式策略以及跨账户/区域的备份。

数据迁移：DMS、Snowball 和 DataSync

• AWS Database Migration Service (DMS)：使用全量加载加变更数据捕获 (CDC) 的方式，以最短的停机时间进行在线迁移。通过内置的模式转换（对于复杂转换，可使用 AWS Schema Conversion Tool）支持同构和异构迁移。用于直接迁移到 RDS/Aurora、迁移到 DynamoDB（通过 JSON 映射），或用于持续复制以实现读负载分流或分阶段切换。应根据峰值变更率来确定复制实例的大小；确保源日志（例如，binlog/redo）保留足够的历史记录。
• AWS Snowball (Edge Storage/Compute Optimized)：PB 级别的离线数据传输，适用于网络受限/昂贵或需要快速植入海量 S3/EFS 数据集的场景。可串联多个设备以处理数 PB 的负载。用于初始批量加载、远程/边缘数据收集，或从受限的数据中心迁出。数据通过 KMS 进行端到端加密；设备跟踪和防篡改密封支持监管链。
• AWS DataSync：用于 NFS/SMB 到 S3/EFS/FSx 以及 AWS 存储服务/区域之间的在线加速传输。它能处理增量变更检测、并行化、压缩、带宽控制、调度和完整性检查。用于迁移周期性增量数据、混合工作流，以及用托管的自动化方案替代自定义 rsync 脚本。在本地部署 DataSync 代理以访问本地存储。

实际问题场景

Shopify 需要对其全球产品媒体管道和目录数据进行现代化改造，同时为全球买家提高弹性和降低延迟。该公司必须：跨区域和跨账户复制产品图片并满足严格的 RPO，降低北美和欧洲的 DynamoDB 读取延迟，迁移带有持续增量更新的本地 NFS 资产，并通过可靠的备份简化 RDS 操作。

1. 从 us-east-1 的主媒体存储桶（商品账户）到 eu-west-1 的目标存储桶（交付账户），实施带有复制时间控制 (Replication Time Control) 的 S3 CRR。

• 原因：CRR 满足了跨区域和跨账户分离的要求，以实现最小权限和数据主权。RTC 提供了 15 分钟的复制 SLA 和监控，以满足合规级别的 RPO。跨账户存储桶策略确保源复制角色可以写入，而指定目标 KMS 密钥则可维持加密域。

2. 定义按前缀和标签筛选的 S3 复制规则，以分离原始文件、缩略图和日志，并启用删除标记的复制。使用 S3 批量复制来回填历史对象。

• 原因：规则范围限定避免了不必要的复制成本，而删除标记的复制使各区域在语义上保持一致。批量复制无需定制脚本即可填补历史数据空白。

3. 将产品目录和库存转换为跨 us-east-1 和 eu-west-1 的 DynamoDB 全局表；将表切换到按需容量，并为每个区域的读取密集型 API 添加 DAX 集群。

• 原因：全局表提供双活写入，具有低延迟的本地读写和持续复制能力。按需模式消除了流量高峰期间的容量规划风险。DAX 降低了热点读取的 P99 延迟，保护 DynamoDB 免受突发访问的影响。

4. 将订单关系型工作负载重构到 Amazon Aurora MySQL，使用写入器和读取器终端节点；为突发性分析添加一个小的 Aurora Serverless v2 读取器，并启用具有 14 天保留策略的自动备份。

• 原因：集群/读取器终端节点解耦了读/写操作，并在维护或故障转移期间最大程度地减少了中断。Serverless v2 经济高效地吸收了不可预测的分析突发流量。自动备份提供了时间点恢复 (PITR) 和简化的恢复流程。

5. 引入 ElastiCache for Redis（启用集群模式）用于会话存储和产品可用性缓存，配置 Multi-AZ 和快照备份；设置与业务 SLA 一致的 TTL。

• 原因：Redis 的数据结构和 Multi-AZ 故障转移确保了快速、有状态的会话和近乎实时的缓存失效。集群模式随着目录大小和流量的增长而水平扩展。

6. 创建一个 EFS 区域级文件系统，在每个应用程序 AZ 中设置挂载目标，并为需要共享 POSIX 存储（例如，媒体处理器）的工作负载配置访问点。启用 EFS 生命周期策略，在 30 天后将数据转换到 IA 层。

• 原因：EFS 提供了弹性的、多可用区的共享存储；访问点强制执行每个应用程序的隔离和 POSIX 身份。生命周期管理自动为保持可访问的冷门资产削减成本。

7. 使用 AWS DataSync 迁移本地 NFS 媒体库，通过计划任务将夜间增量同步到 S3 和 EFS。

• 原因：与临时的 rsync 相比，DataSync 能更好地处理变更检测、并行化、完整性验证和带宽控制，以最少的运维工作自动化处理持续的增量数据。

8. 使用 AWS DMS（全量加载加 CDC）和 AWS Schema Conversion Tool（在需要时）将遗留的 PostgreSQL 目录迁移到 Aurora；在 CDC 延迟耗尽后进行切换。

• 原因：DMS 实现了近乎零停机的迁移，通过持续复制确保切换时的数据一致性。SCT 处理特定于引擎的转换。

9. 使用 Snowball Edge 设备将数 PB 的历史媒体数据植入 S3，然后切换到 DataSync 进行持续的增量更新。

• 原因：Snowball 在不占用全部 WAN 链路带宽的情况下加速了初始批量传输；DataSync 通过验证和调度，在数据植入后维持持续更新。

该架构降低了全球读取延迟，提供了可预测的复制 RPO，简化了关系型数据库的操作和备份，集中了带有访问控制的共享存储，并为从批量离线迁移到自动化的增量数据迁移提供了一条切实可行的路径。

← 事件驱动架构和自动化 · 所有领域 · 网络和内容分发 →

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

浏览 Amazon →