Amazon DVA-C02: 数据库与缓存 (RDS, Aurora, ElastiCache, Timestream, Proxy) — 学习指南

By Laurynas Brazys · 28 July 2026 · #amazon #dva-c02 #certification #exam-prep #study-guide

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

RDS 与 Aurora：设计、扩展和加密

在 RDS 或 Aurora 上设计关系型数据库时，首先要根据工作负载在单节点预置型 RDS 和 Aurora 的分布式存储之间进行权衡。当需要高读取扩展性和快速故障转移时，应选择 Aurora：Aurora 副本共享集群卷，因此提升速度很快；而 RDS MySQL/Postgres 的只读副本使用基于 binlog 的异步复制，可能会产生延迟。要扩展读取能力，可以添加只读副本并将应用程序的读取流量指向它们；在 Aurora 中，使用读取器端点（reader endpoint）可以在副本之间自动实现负载均衡。对于写入操作，垂直扩展（实例类型）以及精心的模式/索引设计至关重要。务必在创建时使用 KMS CMK 启用静态加密——之后再启用加密需要通过快照/恢复到一个新的加密实例中，这是一个常见的陷阱。为了实现传输中保护，应强制使用 TLS/SSL 连接（RDS 提供 CA 证书包）。对于凭证管理，首选使用 AWS Secrets Manager，并利用其内置的 RDS 轮换 Lambda 模板实现自动轮换；在 SDK 中通过 SecretsManager.getSecretValue() 以编程方式获取密钥。考虑使用 IAM 数据库身份验证来移除静态密码：通过 RDS.Signer (SDK) 或 rds.generate-db-auth-token 生成一个令牌，然后使用这个短期有效的令牌进行连接。使用 Performance Insights、Enhanced Monitoring 和 CloudWatch 进行监测；利用慢查询日志和 EXPLAIN 来定位热点。

连接池、RDS Proxy 和无服务器模式

无服务器函数和连接密集型应用通常会耗尽数据库的连接数限制。在 Node.js 中，一个直接的模式是将 mysql2/promise 连接池放在 Lambda 的全局作用域中，并在多次调用之间复用它，但这并不能解决大规模并发扩展的问题。RDS Proxy 是托管的解决方案：使用 create_db_proxy 创建代理，将其与 Secrets Manager 中的密钥以及目标 RDS/Aurora 实例关联，然后在你的应用中使用该代理的端点。RDS Proxy 负责处理连接多路复用、IAM 身份验证集成和故障转移。对于无服务器的 Aurora Serverless，或者当你偏好使用 HTTP 风格的调用时，可以使用 RDS Data API：rdsdataservice.executeStatement({resourceArn, secretArn, sql, database}) 允许 Lambda 函数在没有持久性 TCP 连接的情况下运行 SQL。一个常见的注意事项是，不要将 Data API 与预置集群混合使用——Data API 是为无服务器集群设计的，其延迟和事务语义都有所不同。另外要注意，RDS Proxy 引入了连接池超时和 max_connections 的概念；需要为 Lambda 的突发流量调整空闲客户端超时和连接借用策略。使用 SecretsManager.getSecretValue() 获取凭证，并通过 rotateSecret 或在控制台/SDK 中启用自动轮换来轮换密钥。

缓存策略：ElastiCache、DAX 和缓存设计

缓存策略的选择取决于数据存储和访问模式。对于 DynamoDB，DAX 提供了微秒级的读取延迟，并通过包装了 DynamoDB.DocumentClient 的 AmazonDaxClient 实现了透明的 SDK 集成；它非常适合读取密集型、最终一致性的工作负载。对于关系型数据库或任意键值缓存，可以使用 ElastiCache Redis 来获得高级数据结构、持久化（AOF/RDB 快照）、复制和集群模式分片等功能，或者使用 Memcached 进行简单的、可水平扩展的缓存。为读取操作实现旁路缓存（cache-aside）模式，仅当一致性和复杂性要求允许时，才使用写穿透（write-through）或写回（write-behind）模式。键的设计至关重要：按应用程序和版本为键添加前缀，使用合理的 TTL，并避免无限基数（unbounded cardinality）的问题。通过加锁并刷新模式（使用 SETNX 或 Redlock）或概率性的提前刷新 TTL 来处理缓存击穿（cache stampedes）问题。配置 Redis 时应启用多可用区和自动故障转移；通过 CreateReplicationGroup 创建带有自动故障转移和快照功能的复制组。常见的陷阱包括：写入后缓存数据陈旧、模式变更后未使缓存失效，以及期望获得绝对一致性。在 CloudWatch 中监控缓存命中率和驱逐指标，并在内存或 CPU 成为瓶颈时，扩展节点类型或集群分片。

使用 Timestream 的时间序列和只读副本模式

Amazon Timestream 是专为时间序列构建的：使用 SDK 的 WriteRecords API 通过批处理的 WriteRecords 调用来注入数据，并使用 TimestreamQuery.query(sql) 进行查询。设计记录 schema 时，应使用低基数（low cardinality）的维度，并采用多度量记录（multi-measure records）来减少写入放大。为每个表配置内存和磁盘存储的保留规则，以将近期数据保留在热存储中，并廉价地存储旧数据；调整保留策略至关重要，因为内存层的保留大小会影响成本和查询性能。对于分析，使用时间序列特定的查询（如 time_bin 或 bin），并将筛选条件向下推送到维度上，以最小化扫描的数据量。在将时间序列与关系型存储集成时，将历史不变数据卸载到 Timestream，并使用 RDS/Aurora 结合 ElastiCache 来提供热元数据。对于关系型数据库的读取扩展，添加只读副本并路由只读流量；对于 Aurora，使用读取器端点（reader endpoints），并在路由关键读取请求前检查副本延迟（CloudWatch ReplicaLag）。一个常见的开发者陷阱是在 Timestream 中使用高基数维度，或为每个请求生成缓存键，这会导致存储膨胀并损害性能。使用批处理进行写入，并采用异步注入管道（如 Kinesis、Firehose）来平滑流量峰值并避免限流。

实践问题：用例场景

场景：NovaShop 在 AWS 上运行一个多区域电子商务平台，在 us-east-1 中使用 Aurora MySQL 处理订单，拥有基于 Lambda 的 API 和一个存储在 DynamoDB 中的全球客户目录。开发人员在单个 AWS 账户中使用 CI/CD，并将数据库凭证存储在 Secrets Manager 中。

挑战：在销售高峰期，Lambda 函数耗尽了数据库连接，并且客户目录需要微秒级的读取性能；开发人员必须通过轮换凭证来维护安全性，并确保产品读取的延迟最小。

推荐方法：

使用 CreateDBProxy 为 Aurora 集群创建一个 RDS Proxy，链接 Secrets Manager 秘密的 ARN，并配置 IAM 身份验证；更新 Lambda 以使用代理端点，并通过 SecretsManager.getSecretValue() 获取凭证。
对于目录，部署一个 Amazon DAX 集群，并将 DynamoDB 客户端切换到 AmazonDaxClient({endpoints})，它包装了 DynamoDB DocumentClient 以实现微秒级读取。
使用 RDS 轮换 Lambda 模板（rotate-secret 或通过控制台配置）为 Aurora 秘密启用 Secrets Manager 自动轮换，并确保 Lambda 的 IAM 角色有权调用 secretsmanager:GetSecretValue。
为会话缓存添加一个 ElastiCache Redis 集群（集群模式），并实施旁路缓存（cache-aside）模式，使用 TTL 和 SETNX 刷新锁来防止缓存踩踏（stampedes）。

理由：使用 RDS Proxy 可以防止 Lambda 扩展时产生的连接风暴，而 IAM/Secrets Manager 通过自动轮换保护凭证；DAX 提供微秒级的 DynamoDB 读取性能，ElastiCache 处理瞬态会话/读取缓存，这符合无服务器扩展和安全最佳实践。

← 存储、Amazon S3、CloudFront 与文件系统 (EFS · 所有领域 · 消息传递、流处理与事件驱动架构 (SNS →

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