Amazon Aurora(SIGMOD 2018)云数据库关键技术解读

说在前面

本文主要介绍 《Amazon Aurora: On Avoiding Distributed Consensus for I/Os, Commits, and Membership Changes 》（SIGMOD 2018）这篇论文，这篇论文主要是关于Amazon Aurora分布式数据库中一些关键技术的实现思路。
若想直到更多关于Aurora基础架构的，可参考 《Amazon Aurora: Design Considerations for High Throughput Cloud Native Relational Databases》（SIGMOD 2017）这篇论文。

大致介绍

Aurora是亚马逊的分布式云数据库，它与传统的关系型数据库不太一样，它的设计是专门针对分布式环境的，不像MySQL一类也可适用于（或说更适用于）单机状态。

Aurora最大的特点是存储节点和计算节点分离（或说database instance和storage分离），真正的日志式数据库。Aurora采用的是面向服务的架构，计算节点（也称作数据库实例database instance）专门负责提供服务，而存储节点则将数据的存储功能抽象化，方便扩展调整。存储节点仅负责数据落盘以及redo log落盘，计算节点则负责其它功能，如分布式事务、锁管理，读写请求等。将存储分离也使得数据存储、备份更加灵活可变，但同时也增加了容灾和同步的难度，本文将详细介绍这些机制。

优化写效率

需要提前说明的是，写的时候计算节点，也就是数据库实例，仅仅传redo log到存储节点（所以说它是日志式数据库）。而存储节点则会将redo log落盘，同时会周期性的刷data page到磁盘中。

Aurora采用的是quorum模型，即在多份（同样的）数据上进行读写。

这里大致介绍下Aurora的quorum机制（更多信息可搜quorum一致性），Aurora每份数据都有6个副本（也称为节点或者分区segment，这是数据组织的最小单位），分别存储在3个AZ（Avalible Zone，可以理解为3台不同的机器）上。针对6个副本（segment）组成的protection group，每次写的时候需要随机写4个分区，这样能保证其中至少有一个分区包含着上次写的最新数据；而读的时候则要随机读3个分区，这样能保证读到最新的数据。