2025-05-27-just-make-it-scale-an-aurora-dsql-story.md

Just make it scale: An Aurora DSQL story

• URL: https://www.allthingsdistributed.com/2025/05/just-make-it-scale-an-aurora-dsql-story.html
• Added At: 2025-05-27 14:18:38

TL;DR

AWS在开发Aurora DSQL时，采用单日志模式与Crossbar层实现分布式事务的横向扩展和强一致性，解决了传统数据库的扩展难题。初期因JVM的GC问题导致性能瓶颈，后通过全面转向Rust大幅提升性能，利用其零GC和内存安全特性优化数据平面，同时基于Postgres扩展重构核心组件。团队通过技术转型最终实现高吞吐、低延迟的云端数据库，验证了Rust在性能敏感场景中的适用性及技术决策及时调整的重要性。

Summary

本文总结了AWS开发Aurora DSQL数据库时的架构设计、技术挑战及语言迁移决策。

一、背景与目标

• Aurora DSQL旨在构建无需基础设施管理、可横向扩展并支持多区域部署的云端关系型数据库。
• AWS的数据库发展历史表明，客户需求推动了创新，如DynamoDB、Redshift等服务的推出。DSQL的诞生是为了进一步解决写操作自动水平扩展的问题。

二、架构设计

1. 写操作的横向扩展：

   • 推翻传统两阶段提交（2PC）协议，改用**单日志（Single Journal）**模式，将事务写入一个日志，而非按行分片。
   • 优势：确保ACID的原子性和持久性；简化写路径扩展。
   • 挑战：读路径复杂化，需依赖Crossbar层解决数据同步和总顺序问题。

2. Crossbar层：

   • 引入Crossbar作为中间层，按订阅机制将更新分发至存储节点，确保读取时的总事务顺序。
   • 通过追踪每份日志的事务时间实现高效路由，优化了多节点协调开销。

三、性能与语言选择的困境

1. JVM的挑战：

   • 初期采用Kotlin/JVM实现时，模拟测试显示性能瓶颈：40个节点时仅达6,000 TPS（预期1,000,000 TPS），尾延迟从1秒飙升至10秒。
   • 根本原因：GC停顿导致系统扩展时的稳定性问题，节点越多，事务受影响概率接近100%。

2. 转向Rust的决策：

   • Rust实现的Adjudicator组件（处理事务冲突）性能超出Kotlin/JVM版本10倍（30,000 TPS vs. 3,000 TPS），且无需针对性优化。
   • Rust的优势：零GC消除尾延迟，内存安全减少漏洞风险，零成本抽象提升代码质量。

四、数据库与Rust的整合

1. 基于Postgres的扩展：

   • 利用Postgres的模块化特性，替换其核心组件（如复制、事务管理）而非硬叉。
   • 原计划用C扩展Postgres，但团队发现C代码易引发内存安全问题（如use-after-free、缓存溢出），最终用Rust实现，并通过类型系统确保数据一致性。

2. 控制平面的转变：

   • 初期控制平面用Kotlin/JVM开发，因需与数据平面共享逻辑，导致跨语言协作难、测试重复等问题。
   • 后来全面转向Rust：统一语言减少误用和调试成本，提升端到端性能，尾延迟接近中位数，稳定性提高。

五、团队适应与协作

• 熟练使用Rust需克服学习曲线，但AWS通过内部培训材料（"The DSQL Book"）、架构讨论会和技术专家（如Niko）的支持，帮助团队快速适应。
• 工程师从抵触转向主动学习Rust，因观察到Rust版本显著优于传统语言在关键指标上的表现。

六、结论与建议

• Rust的选择逻辑：在尾延迟敏感、需严格性能控制的场景（如DSQL的数据平面）受益，但非所有项目必须采用。需结合团队技能、业务需求和生态系统利弊权衡。
• 开发启示：优先考虑长期效率（如内存安全、可维护性），及时修正早期技术决策，避免维护多个语言代码库的隐性成本。