AWS DynamoDB 故障留下的警示：比竞态条件更可怕的设计漏洞

2025 年 10 月，云世界的中心——AWS US-EAST-1 区域停摆了。EC2 停止了创建，Lambda 拒绝了响应。而所有多米诺骨牌的尽头，指向了 DynamoDB。AWS 在官方报告中将其称为潜在的竞态条件 (Race Condition)。但这真的只是运气不好的时机问题吗？在资深工程师眼中，这场事故是分布式系统的逻辑缺陷与恢复机制缺失共同酿成的惨剧。

复杂流量分发系统的真相

DynamoDB 为了实现高可用性，使用了 DNS 树状结构和基于权重的记录。流量由三个核心组件进行管理：

组件	角色	运行方式
DNS Planner	计算流量分发比例	生成区域单位的最佳优化方案
DNS Enactor	更新 Route 53 记录	在 3 个 AZ 中独立执行
DWFM	协调整体工作流	编排更新的传播过程

系统设计初衷是：当特定区间出现问题时，通过将权重设置为 0 来阻断流量。理论上非常完美，但在实际运行中，意料之外的变量爆发了。

覆盖与删除相遇的最坏剧本

事发当天，由于负载激增，Enactor 1 的处理出现延迟。与此同时，Enactor 2 已经反映了最新版本的 Plan 102。就在这时，致命的连锁反应发生了。

首先，之前延迟的 Enactor 1 终于苏醒，将旧数据 Plan 100 覆盖到了最新信息之上。紧接着在清理阶段，Enactor 2 开始删除那些不属于当前基准（Plan 102）的旧记录。对于 Enactor 2 来说，Enactor 1 刚刚恢复的数据只是需要删除的对象。最终，DynamoDB 的主终端 (Endpoint) DNS 记录彻底蒸发了。

真正的问题在于恢复逻辑的缺失

大部分人的分析到此为止，结论是“因为时机错乱导致数据被删”。但核心问题在于：为什么系统在看到空的记录时，无法自我修复？

由于终端消失，本应负责恢复的系统接连触发了运行时异常。Enactor 的代码并未假定“记录不存在”的情况。就像内存管理错误中的 Use-after-free 一样，系统因引用了已经消失的对象而崩溃。

自动化的回滚逻辑反而让情况恶化。因为作为恢复基准的数据库本身已经受到了污染。系统陷入了无限循环，自动化不再是修复系统的工具，而成了毁灭系统的武器。

官方报告背后的教训

AWS 表示将引入限流功能。但这只是缓解症状，而非根本药方。如果系统不具备感知异常状态并自我愈合的能力，同样的悲剧还会重演。

维度	官方解释	资深洞察
故障原因	并发更新冲突	写入时缺乏有效性验证 (CAS)
故障现象	自动化停止运作	故障安全 (Safe Default) 设计不足
应对方案	限制更新速度	确保恢复逻辑的幂等性

设计“优雅降级”的系统

2025 年的这场事故证明了一行代码的分量。击垮价值数十亿美元基础设施的，并非宏大的黑客攻击，而是在面对空白 DNS 记录时，因未定义行为而导致的小小异常处理疏忽。

工程的精髓不在于构建复杂的功能，而在于设计一种能力：在不可预知的失败面前，能够优雅地倒下，并确保能稳健地恢复。

稳定性必备清单

• 回滚验证：当引用的数据缺失时，系统是否能以安全的默认值运行？
• 原子性保证：在检查 (Check) 与使用 (Use) 之间的间隙，是否通过 CAS 等机制进行了保护？
• 依赖管理：即使核心数据库连接断开，是否有维持最低限度功能的策略？

真正的专家不仅关注系统是如何崩溃的，更会执着地追问：为什么它没能恢复。你的系统，现在做好“安全失败”的准备了吗？