Amazon SAA-C03: 数据库与缓存 — 学习指南

By Laurynas Brazys · 19 July 2026 · #amazon #saa-c03 #certification #exam-prep #study-guide

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

Amazon RDS：托管关系型引擎

Amazon RDS 提供六种托管引擎——MySQL、PostgreSQL、MariaDB、Oracle、SQL Server 和 Amazon Aurora（兼容 MySQL 和 PostgreSQL）——它抽象了补丁、备份、复制拓扑和故障转移等操作。引擎的选择决定了许可方式、备份语义和功能可用性：Oracle 和 SQL Server 有自带许可 (BYOL) 与许可内含 (License Included) 的区别，SQL Server 通过原生复制最多支持五个只读副本，而 Oracle 只读副本需要企业版 (Enterprise Edition) 和 Active Data Guard。

在 RDS 中，为实现可用性和扩展性而最常使用的两个功能——同时也是最容易混淆的两个功能——是多可用区 (Multi-AZ) 部署和只读副本。它们是正交的、互补的，但不可互换。

Multi-AZ 会在第二个可用区中预置一个同步备用副本。每次写入操作在确认前都会提交到主节点和备用节点，从而使 RPO (恢复点目标) 几乎为零，并在自动故障转移期间实现 60-120 秒的 RTO (恢复时间目标)。备用节点不接受任何流量——它仅为故障转移而存在。当主节点发生故障、某个可用区受损或维护需要重启时，RDS 会将 DNS CNAME 切换到备用节点，应用程序通过相同的终端节点透明地重新连接。对于单可用区中的单点故障，Multi-AZ 是最省力的修复方案：它只是一个配置开关，不需要更改 schema 或应用程序，并且保留了原有的终端节点。较新的多可用区集群部署是一种三节点拓扑（一个写入节点，两个可读备用节点），使用半同步复制，提交延迟大约为一秒，在提供高可用性 (HA) 的同时，也提供了有限的读取分流能力。

只读副本使用引擎原生的异步复制机制（MySQL 的 binlog，PostgreSQL 的 WAL 流式复制）。它们是进行读取扩展的正确工具，适用于处理分析查询、报表仪表盘、即席 SELECT 等操作，否则这些操作会耗尽主节点上的 OLTP 资源。一个典型的场景是：由于员工运行耗时较长的月末报表，导致订单处理数据库超时。通过添加一个只读副本，并将报表工具指向其终端节点，就可以在不升级主节点的情况下隔离分析负载。只读副本可以跨区域创建，也可以手动提升为独立的数据库，但提升过程绝不会自动进行，并且在故障发生时任何尚未复制的事务都会丢失。

在这个领域有两个常见的陷阱。第一，将只读副本视为高可用性 (HA) 解决方案是完全错误的，原因有多方面：副本是异步的（可能导致数据丢失），没有自动提升机制，提升后终端节点会改变，并且进行中的事务会消失。如果一个设计承诺“零数据丢失”，却将只读副本作为故障转移目标，那么这个承诺是虚假的。第二，为了处理读取流量而预置 Multi-AZ 是在浪费金钱，因为在标准拓扑中备用节点是不可读的。Multi-AZ 解决的是可用性问题；只读副本解决的是读取扩展问题；而你通常两者都需要。

只读副本对写入扩展也毫无帮助——每次写入仍然要命中主节点，而副本必须重放这些写入。要实现写入扩展，你需要进行分片 (shard)，迁移到 Aurora（其存储是解耦的），或者重新设计架构转向 DynamoDB。

为只读副本选择合适的规格

副本的实例类型不必与主节点匹配。主节点处理全部的写入负载外加一部分读取负载；而副本只处理指向它的那部分读取负载。一个 db.r6i.4xlarge 的主节点搭配一个 db.r6i.large 的副本用于夜间报表任务是完全合理的——前提是该副本能够跟上复制的 I/O。正确的方法是：测量副本的实际 CPU、内存和副本延迟 (replica lag)，然后根据该工作负载来确定其规格。唯一需要注意的是：如果你打算在灾难恢复 (DR) 期间将某个副本提升为新的主节点，那么它必须具备能够处理写入负载的规格。规格过小的副本不适合作为提升的目标。

蓝/绿部署与存储

RDS 蓝/绿部署会创建一个与生产环境（绿色环境）完全一致的预发（staging）副本，并通过逻辑复制保持同步。你可以在绿色环境上升级引擎版本、更改参数组或修改 schema，对其进行测试，然后通过自动重命名终端节点在一分钟内完成切换。这消除了传统的原地升级风险，即主要版本升级失败后不得不强制进行快照回滚。

对于写入密集型的 OLTP 负载，存储类型的选择与实例类型同等重要。gp3/io2 的分类如下：

gp3 相较于 gp2 的改进在于将 IOPS 与存储大小解耦——你不再需要为了性能而过度预置容量。当持续 IOPS 需求超过 gp3 的上限，或者需要 99.999% 的持久性时，应选择 io2。Multi-Attach 允许单个 io2 卷挂载到多达 16 个 Nitro 实例上，但文件系统或应用程序必须具备集群感知能力；它不能替代复制。一个潜在的停机陷阱是：预置固定大小的存储，但没有启用存储自动扩展 (storage autoscaling)，也没有为 FreeStorageSpace 指标设置 CloudWatch 警报。当可用空间降至零时，RDS 会进入 storage-full 状态并拒绝写入操作。

Amazon Aurora：架构与端点

Aurora 将 MySQL 和 PostgreSQL 底层的存储层重新实现为一个分布式的、日志结构的、跨三个可用区（AZ）的六路复制卷。计算节点相对于存储是无状态的，因此 Aurora 副本（Replica）直接从与写入器（writer）相同的底层卷中读取数据，而不是通过重放日志。复制延迟通常为 10-20 毫秒，而标准 RDS 副本则为数秒。一个集群支持多达 15 个副本，这些副本可在大约 30 秒内提升为写入器。

Aurora 提供四种类型的端点：

当副本异构时，自定义端点就显得尤为重要。例如，六个副本中有三个是用于分析报告的 db.r6g.8xlarge 实例，而其余的则用于处理 OLTP 读取，那么通用的读取器端点偶尔会将报告任务路由到较小的节点上，从而影响性能的可预测性。一个仅限于大型副本的自定义端点可以提供确定性的工作负载隔离：

aws rds create-db-cluster-endpoint \
  --db-cluster-identifier prod-aurora \
  --db-cluster-endpoint-identifier reporting \
  --endpoint-type READER \
  --static-members reporting-node-1 reporting-node-2 reporting-node-3

请注意，Aurora 端点的 DNS TTL 为 5 秒；缓存连接字符串的时间过长会破坏故障转移行为。

Aurora Auto Scaling 根据目标 CPU 或连接数指标来增加和移除读取器，对于必须保持高可用的、不可预测的读取密集型工作负载，这是标准的解决方案：

TargetTrackingScalingPolicyConfiguration:
  PredefinedMetricSpecification:
    PredefinedMetricType: RDSReaderAverageCPUUtilization
  TargetValue: 60.0
  ScaleInCooldown: 300
  ScaleOutCooldown: 60

当 RDS MySQL 读取副本在峰值时无法将复制延迟保持在一秒以内时，低代码的解决方案是迁移到 Aurora MySQL —— 连接字符串几乎不变，而存储级别的复制可以消除延迟。

Aurora Serverless v2 与克隆

Aurora Serverless v2 能够在大约半秒内，以细粒度的 Aurora 容量单位（ACU，每个含 2 GiB 内存）垂直扩展计算能力，且不会断开会话。它适用于具有已知基线内存占用量的可变工作负载 —— 例如，一个从本地迁移过来的 MySQL，其内存消耗始终至少为 2 GiB。将最小 ACU 设置为 1，最大 ACU 设置为 32，集群便可以无需管理自动伸缩。当负载稳定且可预测时，预置型（Provisioned）Aurora 仍然是更好的选择，因为 Serverless v2 的每个 ACU 都有额外费用。

Aurora 克隆通过写时复制（copy-on-write）技术创建一个新集群，该集群与源集群共享存储页面。克隆在几秒钟内即可创建完成，并且在数据发生分歧之前不产生任何费用，这使其成为预生产环境、高风险迁移或让分析师对生产副本进行高强度测试的理想选择。快照恢复需要物理上恢复数据，可能耗时数小时；当速度至关重要时，克隆是更优的选择。

Aurora Global Database

Aurora Global Database 使用专用的存储层复制基础设施（而非 binlog 传输），将一个集群扩展到多达五个备用区域（secondary Region）。典型的复制延迟低于一秒，RPO 低于一秒，而托管的故障转移（managed failover）可在一分钟内将备用区域提升为主区域。

有两个关键语义：在正常操作期间，备用区域是只读的；Global Database 专为低 RPO 的灾难恢复（DR）和低延迟的远程读取而设计，而不是用于主动-主动（active-active）多主架构。认为全局数据库“会自动处理备用区域中的写入”是错误的 —— 在备用区域进行写入需要执行显式的托管故障转移或分离并提升（detach-and-promote）操作。对于跨区域 5 分钟 RPO / 20 分钟 RTO 且运维开销最小的明确要求，Global Database 是标准的解决方案。

RDS Proxy 与连接管理

无服务器（Serverless）和高并发工作负载加剧了一个典型问题：连接风暴。一个扩展到 3000 个并发执行的 Lambda 函数会打开 3000 个套接字（socket），这会耗尽 max_connections 并导致级联故障 —— 而这恰恰发生在系统处于高负载时。在函数内建连接池也无济于事，因为每个并发执行环境都是相互隔离的。

RDS Proxy 位于客户端和数据库之间，维护一个“温”连接池，并将客户端会话多路复用到这些连接上。它解决了两个问题：

1. 连接风暴。 成千上万的客户端会话被多路复用到一个小的后端连接池上。
2. 故障转移时间。 代理在重新建立后端链接时会保持客户端连接的打开状态，将用户感知的故障转移时间缩短高达 66%，并消除了客户端侧的 TCP/TLS 重建和 DNS 重新解析。

它与 IAM 和 Secrets Manager 集成以处理凭证，从而消除了应用程序代码中的硬编码密钥。

DBProxy:
  Type: AWS::RDS::DBProxy
  Properties:
    EngineFamily: POSTGRESQL
    RequireTLS: true
    IdleClientTimeout: 1800
    Auth:
      - AuthScheme: SECRETS
        SecretArn: !Ref DBSecret
        IAMAuth: REQUIRED

应用程序连接到代理端点，而不是集群端点。任何 Lambda-to-RDS 或高扇出（high-fan-out）架构都应使用 RDS Proxy，除非有特殊理由不使用。在 EC2 上运行自己的连接池程序（如 PgBouncer、ProxySQL）是可行的，但这会增加额外的运维开销，而 RDS Proxy 的目的正是为了消除这种开销。

DynamoDB：容量模式

DynamoDB 是一种托管的键值/文档存储，可在任何规模下提供个位数毫秒级的延迟，并按哈希键进行水平分区。它提供两种容量模式：

按需模式非常简单，但每个请求的成本大约是充分利用的预置容量的 6-7 倍。对于一个每晚持续 4 小时、需要 500 WCU 的批处理任务，使用按需模式会多付很多钱——采用计划扩展或预留容量的预置模式要便宜得多。反之，对于一个流量不可预测的新产品发布，使用预置模式会导致节流。对于具有中等波动的稳定工作负载，使用目标跟踪自动扩展将利用率维持在 70% 左右的预置模式，比按需模式要便宜得多——通常便宜 50-70%：

TargetTrackingScalingPolicyConfiguration:
  TargetValue: 70.0
  PredefinedMetricSpecification:
    PredefinedMetricType: DynamoDBReadCapacityUtilization
  ScaleInCooldown: 60
  ScaleOutCooldown: 60

你可以每 24 小时切换一次模式。认为按需模式普遍更便宜是一个代价高昂的错误；同样，认为预置模式总是适合突发流量也是错误的。

DynamoDB：一致性、流、全局表

读取默认为最终一致性（可能在约 1 秒内返回旧数据，成本为 0.5 RCU）。设置 ConsistentRead=true 会返回最新提交的值，但成本加倍。全局二级索引或 DAX 不支持强一致性读取——这些路径总是返回最终一致的数据。

DynamoDB Streams 以有序日志的形式捕获项目级别的变更，并保留 24 小时，可触发 Lambda 进行下游处理（如搜索索引、通知、跨表非规范化），而无需轮询。

Global Tables 基于 Streams 构建，提供多活、多区域复制，并采用“最后写入者获胜”的冲突解决方法。当读写操作必须在多个区域内实现本地化时，这是正确的选择。但它们会使存储和写入成本大致翻倍——每次写入都会在每个副本区域消耗一个 WCU——并削弱了跨区域的一致性。一个常见的陷阱是，当单个区域就能满足可用性要求时却启用了全局表：单个区域中的 DynamoDB 已经在三个可用区（AZ）之间复制，可用性高达 99.99%。具有成本效益的单区域高可用性方案是：一个启用了 PITR 的单区域表，如果需要，还可以配置带自动扩展的预置容量。

时间点恢复 (PITR) 提供连续备份，可在过去 35 天内实现秒级恢复粒度，且开销可忽略不计。应在任何生产表上启用它——它能满足典型的分钟级而非小时级的 RPO 要求。对于更长的保留期（如法规要求），请集成 AWS Backup 以进行计划性的、具有生命周期管理的、可跨区域复制的备份。

TTL 允许你指定一个包含 Unix 纪元时间戳的属性作为过期时间；DynamoDB 会异步删除过期的项目，不产生额外费用，这对于会话存储、临时令牌或事件缓存非常理想。TTL 删除操作会流入 Streams 以便进行下游归档：

TTLSpecification:
  AttributeName: expireAt
  Enabled: true

对于分析场景，导出到 S3 会生成一个时间点快照，可供 Athena、Redshift Spectrum 或 EMR 读取，而不会消耗表容量——这是一种比扫描全表好得多的模式。

DAX：DynamoDB Accelerator

DAX 是一个专为 DynamoDB 设计的完全托管的内存写穿缓存，可提供微秒级的读取延迟，而 DynamoDB 的基线延迟为个位数毫秒级。其显著特点是 API 兼容性：DAX 客户端是 DynamoDB SDK 客户端的直接替代品，因此应用程序只需更改端点配置即可采用它，而无需重写查询逻辑：

import amazondax
dax = amazondax.AmazonDaxClient(
    endpoint_url='dax://cluster.abc.dax-clusters.us-east-1.amazonaws.com')
table = dax.Table('Products')
resp = table.get_item(Key={'sku': '1234'})  # microsecond hit path

DAX 维护两种缓存：一个用于 GetItem/BatchGetItem 结果的项目缓存和一个用于 Query/Scan 结果的查询缓存。写入是写穿模式——DAX 将写入代理到 DynamoDB，并在成功后更新其项目缓存——但查询缓存依赖于 TTL，因此即使对于刚刚写入的项目，查询结果也可能变得陈旧。

有两个限制很重要。首先，DAX 只加速最终一致性读取；强一致性读取会绕过缓存。其次，其他绕过 DAX 的写入者会导致数据陈旧。对于一个每天有数百万次访问的产品详情页面，DAX 是运维开销最小的加速器——没有缓存失效代码，也无需单独管理集群。在 DynamoDB 前面放置 ElastiCache 也能工作，但需要编写 DAX 所不需要的旁路缓存逻辑。

ElastiCache：Redis 和 Memcached

ElastiCache 作为一项运行 Redis 或 Memcached 的托管服务，提供亚毫秒级的内存数据访问。引擎的选择取决于功能需求：

• Memcached — 纯粹的多线程键值缓存，支持水平分片，但没有持久化、复制或发布/订阅功能。仅适用于丢失整个缓存也无妨的临时缓存场景。
• Redis — 支持复制、带自动故障转移的多可用区（Multi-AZ）、用于分片的集群模式、持久化、发布/订阅、有序集合、事务以及传输中和静态加密。任何需要持久化或复杂数据类型的场景都必须使用它。

主要有两种典型的使用模式。

集中式会话存储。 当 ALB 将流量分发到无状态的 EC2 或 ECS 实例时，本地会话存储会强制使用粘性会话（sticky sessions），这会导致负载不均衡，并在缩容、部署和可用区（AZ）故障期间中断服务。将会话外部化到 Redis 可以让任何实例处理任何请求，并且会话在主机故障后仍然存在：

import redis, json
r = redis.Redis(host='sessions.abc123.ng.0001.use1.cache.amazonaws.com',
                port=6379, ssl=True)

def save_session(sid, data, ttl=1800):
    r.setex(f"sess:{sid}", ttl, json.dumps(data))

为高开销查询提供读取分流 — 例如排行榜（通过 Redis 有序集合的 ZADD/ZREVRANGE 实现）、目录查找、聚合计算。缓存策略必须与一致性需求相匹配：

• 懒加载（Lazy loading / Cache-aside）： 应用程序先读取缓存；如果未命中，则读取数据库，然后用 TTL（生存时间）填充缓存。这种方法简单，但冷启动时的未命中会影响性能，且数据可能过时。
• 穿透写（Write-through）： 应用程序在同一次操作中同时写入缓存和数据库。缓存能保持最新，但写入速度较慢，并且未被使用的数据仍会占用内存。
• 回写（Write-back / Write-behind）： 先写入缓存，然后异步地刷新到数据库。写入速度最快，但缓存故障会导致数据丢失。

data = r.get(f"product:{sku}")
if data is None:
    data = db.query("SELECT * FROM products WHERE sku=%s", sku)
    r.setex(f"product:{sku}", 300, serialize(data))

依赖任何缓存层而没有失效策略——如 TTL、更新时显式 DEL 或穿透写——都会导致脏读。这种故障模式是静默的：应用程序看起来一切正常，直到用户注意到数据不一致。此外，当读取需求超出只读副本的处理能力时，缓存通常是扩展读取最经济的方式，并且能在流量高峰期保护主数据库。

与 DAX 不同，ElastiCache 与引擎无关——你需要自己负责失效逻辑——这就是为什么当后端存储是 DynamoDB 时，DAX 在运维简单性上更胜一筹的原因。

迁移：DMS 和 SCT

AWS Database Migration Service (DMS) 可在同构引擎（如 Oracle→Oracle、MySQL→Aurora MySQL）或异构引擎（如 Oracle→Aurora PostgreSQL、SQL Server→RDS MySQL、本地→DynamoDB）之间复制数据。一个 DMS 任务包含三个阶段：

1. 完全加载（Full load） — 批量复制现有行。
2. CDC（变更数据捕获） — 跟踪源数据库的事务日志并应用持续的变更。
3. 完全加载 + CDC — 这是常见的最小化停机时间模式：源数据库保持在线，DMS 保持目标同步，切换只需一次短暂的 DNS 变更。

aws dms create-replication-task \
  --replication-task-identifier ora-to-aurora \
  --source-endpoint-arn $SRC --target-endpoint-arn $TGT \
  --migration-type full-load-and-cdc \
  --table-mappings file://mappings.json \
  --replication-instance-arn $RI

DMS Serverless 无需再规划和管理复制实例的规模——容量会根据工作负载自动配置，适合可变或长时间运行的 CDC 任务。源引擎必须启用补充日志（Oracle）或 ROW 格式的二进制日志（MySQL）。对于非常大的初始数据加载，DMS 可与 Snowball Edge 集成进行离线加载。

DMS 迁移的是数据，而不是模式（schema）。对于异构迁移，你需要将其与 AWS Schema Conversion Tool (SCT) 配合使用，SCT 可以转换存储过程、视图、触发器、序列以及特定方言的类型——例如，将 Oracle PL/SQL 转换为 PostgreSQL PL/pgSQL，或将 T-SQL 转换为 Aurora MySQL。SCT 会生成一份评估报告，标记出需要手动修改的对象（对于复杂的代码库，通常占 5-20%）。在跨引擎迁移中单独使用 DMS 是一个常见的错误：虽然 DMS 可以创建基本的目标表，但它无法正确转换存储过程或专有类型。对于同构迁移，则不需要 SCT——使用原生工具（mysqldump、pg_dump、RMAN）加上 DMS CDC 就足够了。

完整的跨引擎迁移模式如下：

1. SCT: convert schema, apply to target RDS/Aurora
2. DMS full-load task: bulk copy existing data
3. DMS CDC task: capture ongoing changes from source
4. Cutover: stop writes at source, wait for CDC lag = 0, redirect app

备份与时间点恢复

RDS 自动备份结合了每日快照和每 5 分钟一次的事务日志备份，从而能在保留窗口（1-35 天，默认为 7 天）内实现任意秒级的时间点恢复（PITR）。恢复操作会创建一个新实例——你无法在原实例上恢复——因此必须更新应用程序的端点或 CNAME。手动快照的保留时间不受保留窗口限制，并且在实例删除后仍然存在（取决于是否创建最终快照的设置），可以跨区域复制用于灾难恢复（DR），也可以跨账户共享。

针对基于 EBS 的快照的 Fast Snapshot Restore (FSR) 功能消除了懒加载（lazy-load）的性能开销，使恢复的卷能立即获得完整性能——这在需要在时间压力下从一个快照启动多个环境时非常有用。Aurora 克隆功能在同一区域内复制时完全绕过了快照。DynamoDB PITR 是一项类似的功能，必须为每个表启用，并在恢复时生成一个新表。

专用数据库

当访问模式有特定需求时，选择专用数据库引擎可以避免日后昂贵的架构重构。Amazon Neptune 是一个托管的图数据库，支持 Gremlin、openCypher 和 SPARQL——适用于需要遍历关系（如欺诈团伙、社交图谱、知识图谱）的查询，这类查询在关系型引擎中使用递归连接的成本会高得惊人。Amazon QLDB 是一个不可变的、可加密验证的分类账数据库，拥有一个仅可追加的日志，适用于需要防篡改审计的记录系统——如供应链溯源、金融交易、车管所记录。DynamoDB 是实现任何规模下个位数毫秒级键值或文档访问的默认选择，它使用单一表设计、用于分层访问的复合排序键以及用于备用访问路径的 GSI 等模式。将这些工作负载强行放入 RDS 会导致锁争用（分类账写入）、查询复杂性（图遍历）或扩展瓶颈（高吞吐量键值访问）——这些问题在后期修复的成本远高于在设计之初就做出正确选择。

常见误区总结

• 将只读副本用作 HA。 异步复制、无自动提升、提升后终端节点会变更、进行中的事务会丢失。Multi-AZ 才是 HA 的解决方案。
• 将 Multi-AZ 用于读取扩展。 在标准的 RDS Multi-AZ 中，备用实例不可读。应使用只读副本或 Aurora 副本。
• 在生产环境中使用 Single-AZ。 没有故障转移目标；在任何 AZ 事件或实例重启时都会失去可用性。Multi-AZ 的成本大约是其 2 倍，但带来了可用性的质的飞跃。
• 默认将副本大小设置得与主实例相同。 副本通常需要小得多的资源；除非副本是提升目标，否则应根据实测的工作负载来调整其大小。
• 认为按需模式的 DynamoDB 总是更便宜。 其每次请求的成本大约是预置模式的 6-7 倍；对于稳定的工作负载，预置 + 自动扩展模式更具优势。
• 为单区域需求使用 Global Tables。 除非需要多区域用户近程访问或灾难恢复 (DR)，否则这会使成本翻倍并削弱一致性，而没有任何好处。
• 认为 Aurora Global Database 的备用数据库可以处理写入。 它们是只读的，直到通过托管的故障转移将其提升为主数据库。
• Lambda → RDS 时不使用 RDS Proxy。 连接风暴会耗尽 max_connections；函数内的连接池在并发执行环境之间不起作用。
• 仅使用 DMS 进行异构迁移。 DMS 只迁移数据，不迁移模式。应与 SCT 配合使用。
• 使用固定的 RDS 存储，且未配置自动扩展或 FreeStorageSpace 警报。 这是潜在的停机风险 — storage-full 状态会拒绝写入操作。
• 使用缓存但没有失效策略。 会导致静默的陈旧数据。TTL、穿透写 (write-through) 或显式失效是必不可少的。
• 通过 DAX 或 GSI 实现强一致性读取。 这两种方式都只提供最终一致的数据。

← 内容分发、边缘与性能优化 · 所有领域 · 分析、数据湖、ML 与专用工作负载 →

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

浏览 Amazon →