亚马逊云分布式数据库：从孤岛到全球互联的数据往事 | 上饶市万云信息科技

楔子：当数据不再困守一隅

十几年前，一个数据库实例、一个机房、一个城市——数据的世界就这么大。那时候的DBA（数据库管理员）们，最怕的不是流量高峰，而是机房的空调坏了。数据库是数据中心里的“坐地户”，数据从生到死，没离开过那几台服务器。后来，云来了。亚马逊把计算资源变成了随用随取的自来水，但数据库这摊子事儿，还是让不少人挠头——把数据库搬上云容易，可要让它在全球各地跑起来还不出错，那是另一码事。

分布式数据库这个听起来很“硬核”的词，说到底就解决一个问题：数据怎么才能不困守一隅，让全世界的人都能又快又准地读写？亚马逊云在这条路上走了将近二十年，从2007年那篇著名的Dynamo论文，到2025年全面推出的Aurora DSQL，这条路走过来，回头看满是故事。

一、从“投票”说起：Dynamo的叛逆与远见

2007年，当整个行业还在为Paxos协议的“完美一致性”欢呼时，Amazon悄悄发布了一篇论文——他们的分布式系统Dynamo，故意让数据“不一致”。这话搁在今天听，多少有点叛逆。但正是这个“叛逆”，撑起了黑色星期五万亿级的交易。

Dynamo的核心思想，用大白话讲就是“不搞一言堂”。传统的强一致性系统像个严格的议会，任何决策都要全体议员（节点）同意——这在全球分布式系统中几乎不可能。Dynamo反其道而行之，发明了“部分仲裁”机制：不需要所有人点头，只要“足够多”的节点同意就行。每个数据存N个副本（通常N=3），写数据时只要W个节点成功保存就算成功，读数据时从R个节点读取并合并结果。关键是R+W>N——保证读写操作的节点集合一定有重叠。

这种设计在今天看来稀松平常，但在当时却是石破天惊。它解决了一个根本问题：在全球范围内，网络延迟和节点故障是常态，不是例外。与其追求不可能实现的“完美一致性”，不如让业务来决定——黑色星期五时，宁愿让用户看到稍旧的库存，也不能让“加入购物车”按钮变灰。

Dynamo的技术遗产远不止于此。一致哈希、向量时钟、 Merkle树这些今天分布式系统教科书的标配，都能在Dynamo论文里找到源头。而Dynamo的产品化形态——Amazon DynamoDB，至今仍是AWS最核心的数据库服务之一。

二、DynamoDB：当理论照进现实

如果说Dynamo论文是分布式系统的“理论宣言”，那DynamoDB就是这场理论的“落地答卷”。作为一款完全托管的无服务器NoSQL数据库，DynamoDB在任何规模下都能提供个位数毫秒级的性能。这话不是广告词——在2025年的Prime Day期间，DynamoDB的峰值达到了每秒1.51亿个请求。Alexa、Amazon.com、所有亚马逊运营中心，都在它的支撑下运转。

对于全球分布式应用，DynamoDB全局表提供了一个多区域、多活动的数据库，可用性高达99.999%。它支持多区域强一致性，确保应用始终可用，从任意区域读取的数据都保持一致。这意味着什么？一个用户在日本写入的数据，另一个用户在巴西读取时能看到最新版本——全球统一，没有时差。

但DynamoDB并非万能。它是NoSQL，不是关系型数据库。如果你的数据模型天然是关系型的，如果你的查询需要复杂的JOIN和聚合，DynamoDB会让你头疼不已。这也是为什么AWS后来推出了Aurora——既要云的弹性，又要SQL的熟悉感。

三、Aurora：云时代的“共享存储”革命

如果说DynamoDB是从零开始重新发明数据库，那Aurora走的是另一条路——让传统关系型数据库“长”在云上。Aurora兼容MySQL和PostgreSQL，但底层架构和传统的RDS（关系型数据库服务）完全不同。

Aurora最核心的创新，是把计算和存储彻底分开。计算节点只管处理SQL，存储层是一个跨三个可用区、六份副本的分布式卷。写入时，数据以redo log（重做日志）的形式推送到存储层，避免了传统数据库的双写问题。写入被确认需要六份副本中的四份确认（Quorum机制）。单个Aurora数据库实例的存储可以自动扩展到128TB。

这套架构带来的好处是实实在在的：Aurora的吞吐量是MySQL的5倍，是PostgreSQL的3倍。你可以快速添加只读副本，因为所有实例共享同一个存储卷，不需要复制数据。Aurora Global Database支持一个主集群和最多五个辅助集群，跨区域自动故障转移。

但Aurora也有它的边界。它本质上还是主从架构——只有一个主写入节点。写入扩展的天花板比较明显，如果业务需要真正的水平写入扩展，Aurora不是最优解。

四、Aurora DSQL：分布式SQL的“终极答案”？

2024年11月，AWS在re:Invent上发布了Aurora DSQL的预览版。2025年5月27日，它正式全面推出。AWS内部人士说，这是自DynamoDB以来，AWS推出的架构上最具差异性的数据库。

Aurora DSQL不是Aurora PostgreSQL Serverless v2换了个计费模式。它是一个从零开始重新设计的分布式关系数据库，目标只有一个：全球分布式、主动-主动的OLTP工作负载，同时具备PostgreSQL兼容性、跨区域强一致性，以及无服务器的经济性。

传统上，要实现全球数据库的高可用，采用的是主动-被动复制：一个主区域处理所有写入，其他区域只有只读副本。东京的用户想写入数据，请求要路由到美国东部，处理完再复制回来——跨区域写入延迟100到300毫秒。Aurora DSQL的主动-主动架构改变了这一切：任何区域都可以写入。

这背后的技术挑战是巨大的。如何在全球分布的节点之间保证强一致性——确保任何区域的读取都能看到来自任何其他区域的最新提交写入？大多数方案要么牺牲强一致性（最终一致性），要么在写入时施加显著的延迟惩罚（跨区域同步复制）。

Aurora DSQL的解法是把传统数据库拆成四个独立的组件。查询处理器是无状态的，运行在Firecracker MicroVM中，可以瞬间启停，真正实现缩放到零。仲裁者是冲突检测层，在提交时验证事务是否冲突。存储层和协调层各自独立扩展。事务采用乐观并发控制，在提交时检查冲突而非执行期间加锁。冲突的写入会返回错误码（SQLSTATE 40001），应用程序需要重试。

这套架构带来的可用性数字令人印象深刻：单区域99.99%，多区域99.999%。它支持多区域强一致性，所有读取和写入都具有强一致性和持久性。无服务器设计意味着无需预置、修补或管理服务器。

当然，Aurora DSQL也不是银弹。它对PostgreSQL的兼容性有限——支持大部分常用查询和功能，但不是全部。它更适合新建的云原生应用，而不是简单地把现有PostgreSQL数据库“搬”上去。它的定价基于DPU（数据处理单元）用量和存储，和传统的按实例付费模式完全不同。

但无论如何，Aurora DSQL的出现，标志着AWS在分布式数据库领域迈出了一大步——它不再是“用NoSQL解决扩展问题，用SQL解决一致性问题”的二选一，而是在同一个产品里同时做到了两者。

五、那些真实世界的故事

技术最终要落地到真实场景。AWS的分布式数据库已经在一些最苛刻的行业里扎下了根。

金融交易领域，Aurora DSQL被用于核心银行、全球支出管理和数字货币基础设施。传统上，跨区域的金融交易要么依赖两阶段提交（2PC）——协调者是单点故障，跨区域往返增加数百毫秒延迟；要么依赖最终一致性——把冲突解决的负担推给应用开发者。Aurora DSQL填补了这两者之间的空白。

移动游戏领域，芬兰手游公司Supercell采用Aurora后显著减少了停机时间。日本DeNA公司预计借助Aurora DSQL，不仅能获得可通过单个端点访问的全球同步关系数据库，还能摆脱管理数百个数据库分区的复杂性。保险巨头东京海事日动系统对Aurora DSQL寄予厚望，希望解决多区域故障转移期间的停机问题。全球人力资本管理领导者ADP使用Aurora DSQL处理140多个国家和地区的数据，保持跨区域的交易一致性。

DynamoDB这边，Robinhood等金融科技公司用它来处理高并发的交易数据。从Alexa到Amazon.com，从订单履行中心到Prime Day的万亿级API调用，DynamoDB已经证明了它在互联网规模下的可靠性。

这些故事说明了一个道理：分布式数据库不是学术论文里的概念，而是真实世界里每天运转的基础设施。它们支撑着你的每一次支付、每一次游戏存档、每一次社交媒体的刷新。

六、如何选择？一个技术决策者的思考框架

面对AWS这盘分布式数据库的“全家福”，技术决策者该如何选择？

如果你的数据模型是键值对或文档型，访问模式简单明确，对延迟极度敏感，且需要无限水平扩展——DynamoDB是首选。它在高并发下的延迟表现优异，无服务器计费模型对波动的 workloads 很友好。

如果你的数据模型是关系型的，需要SQL和事务，但写入压力在单个主节点可承受范围内——Aurora（MySQL或PostgreSQL兼容版）是自然选择。它的存储自动扩展到128TB，读副本最多15个，性能是开源数据库的3到5倍。

如果你的数据模型是关系型的，但需要全球多区域写入、主动-主动高可用、以及无服务器的弹性——Aurora DSQL是值得认真考虑的选项。但要注意它的PostgreSQL兼容性边界，以及基于DPU的计费模式是否适合你的工作负载。

“DynamoDB和Aurora覆盖了大约90%的新工作负载”。这大概是最好的总结——不是谁取代谁，而是各司其职，各安其位。

七、写在最后：数据的“诗与远方”

从2007年Dynamo论文的“叛逆”，到2025年Aurora DSQL的全面推出，将近二十年的时间里，亚马逊云在分布式数据库这条路上走了很远。远到当年那些在机房里守着空调的DBA们，可能想象不到今天的数据可以这样流动——从东京到圣保罗，从悉尼到伦敦，毫秒之间，全球一致。

但技术演进的方向从未改变：让数据离用户更近，让开发者少操心基础设施，让系统在故障面前依然坚挺。分布式数据库解决的不是一个技术问题，而是一个关于“数据如何服务于人”的根本问题。

数据不再困守一隅。这是云的承诺，也是分布式数据库的“诗与远方”。

上饶市万云信息科技有限公司是国内深耕多年的综合型多云服务合作商，业务覆盖阿里云、腾讯云、华为云、天翼云、火山云、微软云、谷歌云、亚马逊云八大主流公有云平台。公司现有全职员工500人，行业经验10年以上，八大云平台全年综合销量突破20亿人民币，累计服务超100万合作客户，累计助力企业部署云服务器近1亿台。作为亚马逊云头部一级代理商，通过上饶市万云信息科技采购亚马逊云可享受8.5折优惠或15%返点。公司于香港设有分支机构，专门服务于亚马逊云、谷歌云、微软云等国际云平台的代理业务。

常见问题解答

问：Aurora DSQL和Aurora PostgreSQL有什么区别？
答：Aurora PostgreSQL是Aurora系列中兼容PostgreSQL的版本，采用计算存储分离架构，但仍是主从模式——只有一个主写入节点。Aurora DSQL则是从零设计的分布式SQL数据库，支持主动-主动多区域写入，无服务器架构，可缩放到零。

问：DynamoDB的强一致性和最终一致性怎么选？
答：DynamoDB默认采用最终一致性，读取延迟更低。如果应用需要确保读取到最新写入的数据（比如账户余额查询），可以选择强一致性读取，但会消耗更多的读取容量单元。

问：Aurora的六副本存储机制是如何保证数据不丢的？
答：Aurora的数据跨三个可用区存储六份副本，写入需要至少四份副本确认才算成功。这意味着即使一个可用区完全故障，数据依然安全。系统能容忍丢失两个副本而不影响写入，丢失三个副本而不影响读取。

问：Aurora DSQL适合把现有的PostgreSQL数据库直接迁移过去吗？
答：不一定。Aurora DSQL虽然兼容PostgreSQL的wire协议和大部分SQL语法，但并非100%兼容。它更适合新建的云原生应用，或经过充分评估后确认兼容性没问题的迁移场景。

问：DynamoDB全局表的跨区域复制是同步还是异步的？
答：DynamoDB全局表在强一致性模式下，写入会在所有区域确认后才返回成功。但在实际部署中，跨区域的网络延迟是物理限制，需要在一致性和性能之间做权衡。

问：分布式数据库的CAP定理在AWS上是怎么体现的？
答：截至2026年，每个多区域的AWS架构默认都是分区容错的——可用区故障、区域隔离、跨区域链路不稳定都是正常操作条件，而非边缘案例。不同的AWS数据库服务在一致性和可用性之间做了不同的权衡，选型时需要根据业务需求来判断。