Skip to main content

AWS 数据库服务

December 3, 2024About 9 minBasicCloudAWS

AWS 数据库服务

AWS 数据库这块服务多得容易记混，备考时我按数据模型分类:关系型(RDS 和 Aurora)、围绕 RDS 的扩展(Proxy、Custom)、NoSQL(DynamoDB 和它的缓存 DAX)、内存缓存(ElastiCache),再加上几个专用库、迁移工具 DMS 和加密。下面按这个顺序整理。

关系型 RDS 与 Aurora

Amazon RDS

RDS(Relational Database Service)是托管关系型数据库平台,支持多种引擎:MySQL、PostgreSQL、MariaDB、Oracle、Microsoft SQL Server，以及 AWS 自研的 Amazon Aurora。托管的意义在于自动处理备份、补丁、监控和故障恢复,运维量大幅减少。

主要特点:

  • 多引擎支持,创建实例时选引擎,Aurora 也是其中一个选项。
  • 简化管理:自动备份、软件补丁、监控、故障恢复。
  • 可扩展:按需扩展计算和存储。
  • 高可用:Multi-AZ 部署 + 自动故障转移。
  • 安全:VPC、IAM 集成、静态和传输中加密、网络隔离。
  • 性能监控:指标监控、日志管理、自动调优。

存储类型和 EBS 同源,分通用型 SSD(gp2/gp3,均衡之选)、预置 IOPS SSD(io1/io2,关键任务高性能低延迟)和逐步淘汰的磁盘存储(Magnetic,只适合测试)。

Multi-AZ 部署

启用 Multi-AZ 后,RDS 会在另一个可用区自动建一个同步复制的备用实例。主实例出故障、网络问题或维护时,系统自动故障切换到备用实例,无需人工干预。同步复制保证备用实例数据实时一致、不丢数据。这是 RDS 高可用的标准做法。

备份保留期

RDS 自动备份默认保留期最长 35 天,无法直接配更长。要保留数年满足合规,得用 AWS Backup——它跨服务集中管理备份,可自定义保留策略。

Amazon Aurora

Aurora 是 AWS 自研的高性能关系型数据库引擎,兼容 MySQL 和 PostgreSQL,本身属于 RDS 的一个引擎选项。它的定位是兼具商业数据库性能和开源数据库成本。

  • 高性能:比标准 MySQL 快约 5 倍,比标准 PostgreSQL 快约 3 倍,得益于优化的存储层架构。
  • 高可用自愈:默认跨多可用区,自动故障转移,可用性 99.99% 以上。
  • 存储自动扩展:从 10GB 起,最多扩到 128TB,无需人工干预。
  • 兼容性:完全兼容 MySQL 和 PostgreSQL,现有应用和工具可无缝迁移。
  • 备份恢复:自动备份到 S3,支持时间点恢复(PITR)。
  • 全球数据库:跨区域复制,实现全球读写和灾备。

RDS 扩展:Proxy 与 Custom

Amazon RDS Proxy

RDS Proxy 是托管的数据库代理,坐在应用和 RDS / Aurora 之间。核心是连接池:复用数据库连接,减轻实例连接负载,支撑更大并发,避免大量短连接耗尽数据库资源。它还能在数据库故障转移或重启时平滑处理断连、自动重路由,并支持 IAM 集成做身份验证,不必把数据库凭证直接暴露给应用。兼容 MySQL / PostgreSQL 的 RDS 和 Aurora,接入无需改代码。

典型题:无服务器应用用 API Gateway + Lambda + RDS for PostgreSQL,高峰或突发流量时因数据库连接超时报错增多,要在最少改代码的前提下减少故障。答案是开启 RDS Proxy——它管理连接池、减轻连接负载,正好解决 Lambda 这类短连接频繁建连导致的连接数暴增和超时。

AWS RDS Custom

RDS Custom 介于标准 RDS 和在 EC2 上自建数据库之间。它在保留 RDS 自动化管理(自动备份、补丁、故障恢复)的同时,开放数据库实例的底层操作系统访问,允许装自定义软件、改系统设置、做底层性能调优,这些在标准 RDS 上做不到。目前支持 SQL Server 和 Oracle 引擎。适合需要装第三方监控/安全代理、用非标准扩展、或合规上要严格控制和审计系统的场景。

NoSQL DynamoDB 与 DAX

Amazon DynamoDB

DynamoDB 是全托管的 NoSQL 数据库,支持键值和文档模型,任意规模下都能提供个位数毫秒(低于 10ms)的一致响应,吞吐和存储近乎无限。作为无服务器服务,不用预置、打补丁或管理服务器,它会自动伸缩表容量保持性能。

表类有两种:标准(默认,适合大部分负载)和标准不频繁访问(Standard-IA,为访问频率低的数据优化、成本更低)。表类可随时切换,不是永久的。

题一:可穿戴设备的数据量大、工作负载恒定可预测,要在预算内最省钱。答案是预留模式 + DynamoDB Standard-IA——预留模式适合可预测负载、提前预留容量避开按需高价,Standard-IA 进一步降存储成本,恒定负载下访问频率低不构成问题。

题二:游戏公司用 DynamoDB 存玩家数据和排行榜,需要连续备份到 S3、最少编码、不影响可用性和读容量单位(RCU)。答案是开启时间点恢复(PITR)并直接导出到 S3——PITR 是原生功能,自动持续备份到 S3,无需额外代码,也不占表性能。

Amazon DynamoDB Accelerator (DAX)

DAX 是专为 DynamoDB 设计的全托管内存缓存,把热数据缓存在内存里,读延迟从毫秒级降到微秒级。它完全兼容 DynamoDB API,作为透明缓存层存在,应用无需改代码即可加速读。AWS 托管集群维护、故障恢复和扩展。通过缓存热点数据减少 DynamoDB 的读请求,既省成本又避开性能瓶颈,还支持按需选强一致或最终一致读。适合实时游戏、广告技术、IoT 这类要极低读延迟、高频访问相同热数据的场景。

内存缓存 ElastiCache 与缓存策略

Amazon ElastiCache

ElastiCache 是托管的内存数据存储,用来缓存、加速数据库查询和应用响应,支持 Redis 和 Memcached 两种引擎。AWS 负责集群部署、监控、自动故障转移和备份。支持多节点集群和故障转移做高可用,可水平扩展容量。Redis 模式还支持持久化和快照。安全上支持 VPC 隔离、安全组、传输加密和访问控制。常见用途:数据库查询缓存、会话存储、实时分析、排行榜计数器,以及 Redis 的消息队列和发布/订阅。

典型题:EC2 按需实例跨多可用区自动伸缩、用 ALB,实例频繁扩缩,架构要支持分布式会话管理。难点是实例横向伸缩时会话数据要共享,否则请求落到不同实例会丢会话。用 ALB 粘性会话把用户固定到同一实例的做法,在实例缩减、原实例被终止时会丢会话,不适合频繁伸缩。正解是用 ElastiCache 做集中式会话存储,所有实例共享同一份会话数据,与伸缩解耦。

常见缓存策略

围绕 ElastiCache 和 DAX 之外,备考还要清楚几类通用缓存手法:

  • 应用层缓存:在程序里做内存缓存(如 Java 的 Ehcache、C# 的 MemoryCache),或用分布式缓存(Redis)。
  • 结果缓存:缓存查询结果集,适合读多写少的数据,可在应用层或 ElastiCache 实现。
  • 查询缓存:在数据库层(如 MySQL)缓存 SQL 查询结果,注意缓存失效和一致性。
  • 写入策略:Write-Through(同时写缓存和库,一致性好)、Write-Back(先写缓存延迟写库,写性能高但缓存失效有丢数据风险)、Write-Around(只写库,读时再加载缓存)。
  • TTL 与失效:设过期时间防脏数据,ElastiCache 支持自动过期。

专用数据库

几个专用库简单记其定位即可:

  • Amazon Timestream:全托管时序数据库,面向 IoT 传感器、应用日志、运营指标这类按时间记录的数值数据。会按数据年龄自动分层(从内存缓存逐步转到低成本存储)、支持 SQL 查询和窗口函数等分析、无服务器自动扩展。Amazon Timestream for InfluxDB 让你在 AWS 上跑开源 InfluxDB,毫秒级响应、可用性达 99.9%,适合实时告警和基础设施可靠性监控。
  • Amazon Neptune:全托管图数据库,支持属性图(Apache TinkerPop Gremlin 查询语言)和 RDF 图(SPARQL),适合高度互联的复杂关系数据。
  • Amazon DocumentDB:与 MongoDB 兼容的托管文档数据库,专注文档存储和查询,不是键值库。
  • Redis:开源高性能键值数据库,常用作缓存层、会话存储、排行榜、实时分析。在 AWS 上通常通过 ElastiCache for Redis 托管使用。

数据库迁移 DMS

  • AWS Database Migration Service(DMS):用来迁移数据库,支持同构和异构迁移,迁移过程中可保持源库正常运行。
  • AWS Schema Conversion Tool(SCT):模式转换工具,转换数据库结构。异构迁移(如 Oracle 到 PostgreSQL)时,源和目标的表结构、存储过程等可能不同,需要先用 SCT 转换。

数据库加密

RDS 静态加密通过 AWS KMS 密钥启用:在 KMS 中创建托管密钥,为实例开启加密即可。这里有个常见的概念混淆要分清——KMS 和 Secrets Manager 职责不同:

  • KMS 负责生成和管理加密密钥(CMK),密钥本身由 KMS 管理存储,不需要也不应该把 CMK 存进 Secrets Manager。
  • Secrets Manager 负责安全存储凭证和秘密信息(如数据库密码),它通过 KMS 提供的密钥来加密这些秘密。
  • 数据库实例一般不用 CMK 直接加密,而是用数据加密密钥(DEK)加密数据,DEK 再由 CMK 管理。

所以正确流程是:KMS 创建 CMK → 数据库密码等秘密存 Secrets Manager(用 KMS 密钥加密)→ 实例配置集成 KMS 密钥启用加密。

跨账户共享题:数据存在私有子网的 RDS 实例,要把一份数据库副本安全地分享给拥有独立 AWS 账户的外部审计师。最安全的做法是创建数据库的加密快照、与审计师共享快照,并授予其访问对应 KMS 加密密钥的权限。考点是 RDS 快照共享 + 加密 + KMS 密钥的跨账户访问权限管理。