Amazon Aurora 深度探索（三）

本文为2017年7月《程序员》原创文章，未经允许不得转载，更多精彩文章请订阅《程序员》。 作者：李海翔 责编：仲培艺，关注数据库领域，寻求报道或者投稿请发邮件zhongpy@csdn.net。

接《Amazon Aurora 深度探索（二）》

3 Aurora的事务处理

Aurora基于MySQL和InnoDB，实现的是单点写的一主多从架构，所以在事务处理方面，没有大的变动，事务处理技术得到继承。整体上是依据SS2PL和MVCC技术实现了事务模型（参见《数据库事务处理的艺术 事务管理与并发控制》一书的10.3.3、10.3.4节）和并发控制（参见《数据库事务处理的艺术 事务管理与并发控制》一书的第11、12章）。

3.1 持久性

对于Aurora，事务的ACID特性，只有D特性与MySQL和InnoDB有很大的不同。Aurora利用MySQL的Mini-transaction和LSN在存储节点构造数据页（基本过程参见2.1节）。

如前所述，Aurora的存储层与计算层分离。存储层其功能在2.1节讨论，其设计思想在2.2节讨论。本节从事务的角度来讨论与存储层紧密相关的持久性，如表1-2所示存储层是表中的“存储节点S1、S2、S3、S4、S5、S6”。

在存储层，日志被写到持久化的存储设备后，主节点收到应答则不被阻塞，上层工作能够继续进行，且存储层的日志落盘操作保证了整个Aorora的日志持久化。然后存储层的利用日志做实时恢复，这样使得日志数据转变为了“Caching”中存储的页面格式的数据。这些工作完成，才相当于传统架构的数据库持久化完成。

但是，因为存储层不再是单点而是分布式结构，故存在故障的种类变多，如多节点的数据在实时运行过程中的一致性问题、在系统故障后的数据恢复时多节点的数据一致性问题。Aurora使用如表1-2的几个概念来表示关键的一些日志点信息，然后凭借这些点来解决“日志数据的不一致”问题，这几个概念，分别是：

• LSN, Log Sequence Number，日志序列号：单调递增，唯一标识每一条日志记录。如表1-2所示，LSN1到LSN9表示共有9条日志记录，每条有独立的LSN值。
• CPL, Consistency Point LSN，一致性点：MySQL的每个Mini事务产生的最后一个LSN为一个CPL即一致性点（一个事务包括多个Mini事务，一个Mini事务包括一到多个日志记录。这是在描述以Mini事务为基本单位的一个局部一致，尚不能达到事务一致）。如表1-2所示，“T1-Mini-t1”T1事务的第一个Mini事务的一致性点，是LSN3，如果此时系统故障，之后做恢复，事务T1不会被恢复成功；如果事务T1在主节点被标识为了提交（InnoDB的事务提交标志，是在内存标识为事务已经提交，然后才刷出日志，这点不符合预写日志的要求），事务日志尚没有持久化到存储层，这意味着数据可能会丢失。但是，InnoDB对这种先标识事务提交后刷日志的方式给出了不丢失数据的解决方式，而Aurora改变了日志的刷出机制，可能会改变或不改变InnoDB原有的数据一致性保障机制，如果改变了原有机制，论文对这一个重要点没有加以描述，只能存疑待问。
• SCL，Segment Complete LSN，段完整LSN：每一个存储节点对应的最大连续LSN，在系统存活期间，可以利用SCN与其它节点交互，采用Gossip协议，填补丢失的日志记录。如表1-2所示，只标识出了S1节点的SCL是LSN9，而对于S5节点，其SCL是LSN7。
• VCL，Volume Complete LSN，卷完整LSN：每个存储节点接收到的最大连续日志ID，因为多数派协议的使用，每个存储节点的VCL会不不同。如表1-2所示，没有表示出S1到S6各个存储节点的VCL，而是只标识出了六个节点中所有VCL中的公共最大点，这个点，是系统故障后恢复所能恢复到的一致点。注意依旧不是事务一致而是Mini事务一致，存疑的是，不能达到事务一致，其意义何在？还有什么重要的细节没有公开吗？留意到下面这段话，我们可以看出一点端倪（存储层的恢复不需要保证事务一致，存储层恢复之后，计算层还会继续恢复工作，这样才能达到事务一致）：

However, upon restart, before the database is allowed to access the storage volume, the storage service does its own recovery which is focused not on user-level transactions, but on making sure that the database sees a uniform view of storage despite its distributed nature.

q VDL，Volumn Durable LSN，卷持久点：传统的数据库提供CheckPoint功能，在日志中加入一个CheckPoint点，作为故障恢复时的起始点。VDL就是存储层的“CheckPoint点”，在VDL之前的日志，已经无用可以被GC，但因存储层的日志一直在持续不断地被用于“恢复”日志为“Caching”中的数据页，所以其作用和原始的“CheckPoint点”相反。注意VDL是所有存储节点上的日志比较后得到的一个共同点，不是一个Segment级的点，这和VCL相似，都是PG（Protection Group）级别的。其定义如下：

VDL or the Volume Durable LSN as the highest CPL that is smaller than or equal to VCL and truncate all log records with LSN greater than the VDL.

表1-2 日志在主节点和存储层的作用表（持久化实现表）

3.2 事务与数据分布

在1.2节，我们曾说，目前制约存储层内的“Caching”起更大作用的因素，主要在于分布式事务的机制的选取和InnoDB自身的事务实现机制。

这有两层含义。一是InnoDB自身的事务实现机制制约了存储层内的“Caching”起更大作用。二是分布式事务的机制的选取关联着存储层内的“Caching”是否有机会起更大作用。

首先：InnoDB的事务信息，几乎不在数据上（除了元组头上有个事务ID用于版本可见性判断外再无其他信息），而是位于内存中。这其实是在说，InnoDB的行级锁即索引项的记录锁，其锁表位于内存，不能随着Aurora的数据分布而“分布”。而Oracle的RAC可是在数据页上存储了足够多的事务信息（参见《数据库事务处理的艺术 事务管理与并发控制》一书的第六章），所以RAC中的其他节点，就能够随着被分布的数据而获取事务相关的信息从而在分布的各节点上处理事务的ACID特性。此点是MySQL能否走向分布式事务的一个关键点（当然选用不同的分布式事务实现机制会反过来影响这点结论）。

其次：分布式事务的机制的选取为什么会影响着Aurora的存储层内的“Caching”是否有机会起更大作用呢？

有的分布式事务架构，采取的是集中式架构，即中央点总控事务管理。事务的决策判断，都要经过中央点进行，多个子节点需要和中央节点多次交互。比如PostgreSQL-XC提供了全局事务管理器。如果MySQL/InnoDB或者Aurora的分布式架构向这个方向发展，则存储层内的“Caching”就没有多少机会起更大的作用了。

而有的分布式事务架构，采取的是事务信息随同存储分布。这样不同的节点就可以进行“分布式”的事务处理。比如基于BigTable的Percolator系统，其核心不在于两阶段提交，而是在于分布的数据项上，有着丰富的事务信息，这些信息足以被任何节点用于做ACID的实现判断（参考《Large-scale Incremental Processing Using Distributed Transactions and Notifications》）。如果MySQL/InnoDB或者Aurora的分布式架构向这个方向发展，则存储层内的“Caching”就有很大的机会起更大的作用。

走向哪条路，或走向另外的路，需看Aurora的雄心有多大。目前的Aurora告诉我们的是，其分布式架构的选择，仅是用户数据分布。事务数据的分布，其实是更大的一个话题。

3.3 事务处理

MySQL和InnoDB的事务处理技术，采用了SS2PL，把强严格两阶段锁融合到平板事务模型中，以提交和回滚机制实现A特性，并进一步在读数据时加锁确保C特性，通过MVCC实现了I特性中的RR和RC隔离级别以提高并发度。这些技术，在目前的Aurora中没有大的改变。如前所述，Aurora改变的是依据事务日志做持久化处理（D特性）和系统故障后的恢复的一部分流程处理（A、C特性的一部分），从整体上看，没有革命性的变化。但是，Aurora的事务提交却是异步的且和VDL相关（确保持久化），这点在论文中描述很细致如下：

In Aurora, transaction commits are completed asynchronously. When a client commits a transaction, the thread handling the commit request sets the transaction aside by recording its “commit LSN” as part of a separate list of transactions waiting on commit and moves on to perform other work. The equivalent to the WAL protocol is based on completing a commit, if and only if, the latest VDL is greater than or equal to the transaction’s commit LSN. As the VDL advances, the database identifies qualifying transactions that are waiting to be committed and uses a dedicated thread to send commit acknowledgements to waiting clients. Worker threads do not pause for commits, they simply pull other pending requests and continue processing.

在1.2节我们提到“鉴于以上几点，备机数据获取和更新的这个细节，算是个谜”，即备机的数据获取，是从存储层而来还是从主节点而来？我们不妨做个论文没有提及的猜想：备机的数据，源自存储层和主节点，存储层统一向上层提供数据页的缓冲服务，用以不断响应计算层的数据缺页请求，这起到了传统的数据缓冲区的作用。而主节点传输日志给备节点，备节点可以从中解析出UNDO日志信息（UNDO也是受到REDO的保护的），从而能够构造出主节点在某个时刻的完整的计算环境状态（数据缓冲区+UNDO信息），这样，备机就可以为接到的读请求构造一致的“ReadView”，为读操作提供了事务读数据的一致性状态。如为此点，则是一个巧妙的设计。更进一步，主机直接传输给备机的，可以只是准备写入REDO的UNDO信息。

3.4 锁管理

基于MySQL的Aurora同样使用了基于封锁的并发访问控制技术。但是，Aurora改造了MySQL的锁管理器，这点论文没有提及，而在2017年的Percona技术大会上，Aurora的一个分享展示了如图1-11的内容。图中显示，在MySQL的锁表管理器上，对于Scan、Delete、Insert三种操作，把lock互斥了三种类型的并发，而Aurora分别按操作类型加锁“lock manager”，提高了并发度，这样的锁，看起来是一个系统锁，把一个粗粒度的系统锁拆分为三个细粒度的系统锁。但是，较为奇怪的是，如图1-12，Aurora展示了其效果却十分的惊人（图1-13是测试环境的配置）。

图1-11 Aurora锁管理器改进图

图1-12 Aurora锁管理器改进后的性能测试对比图

图1-13 测试环境配置图

4 云服务能力

4.1 强化的云服务能力

除了通过更多的数据冗余（跨3个AZ的 6个副本）提高高可用性外，Aurora还有着其他强大的云服务能力，这是云数据库需要重点建设的能力。

1 .存储方面，存储的单位是段（segment），每个段的大小为10G，单实例数据库存储最大限是64 TB。

2 .处理系统故障方面：

• 10秒内完成一个 10G的Segment的网络迁移。30秒完成故障转移。
• 以Segment为单位周期性并行备份。
• 以REDO日志为单位周期性并行备份。
• 通过日志实时地持续恢复，提供了更快的crash recovery。

3 . 性能方面：

• 更快的索引构建。采用自底向上的索引构建方式，比MySQL快２倍到４倍。
• 无锁并发Read-View算法。构造ReadView采用无锁算法减少竞争提高性能。
• 无锁队列提高审计功能的速度。
• 其他如热行竞争、批量数据插入等性能提升明显。

4 . 其他云服务：

• 提供快速 provisioning 和部署。
• 自动安装补丁和软件升级。
• 备份和 point-in-time 恢复。
• 计算和存储的扩展性支持。
• 如图1-3所示，存储系统的元数据存于Amazon DynamoDB中，使用Amazon SWF提供的工作流实现对Aurora的自动化管理，这也是云中规模化服务的重要能力。

4.2 万能数据库

AWS的Aurora不只是MySQL的一个分支版本，更像是一个万能的数据库系统，这样的系统，通过兼容各种主流数据库的SQL语法、功能，也许能在云上一统数据库的服务，把各种数据库的用户应用接入，通过统一的一个分布式的数据库引擎，提供各种数据库的数据服务能力。

AWS的官网，声明了“兼容 PostgreSQL的Amazon Aurora”如下：

Amazon Relational Database Service (Amazon RDS) 正在提供 Aurora (PostgreSQL) 预览版，即兼容 PostgreSQL 的 Amazon Aurora。Aurora 是一种完全托管的、兼容 PostgreSQL 和 MySQL 的关系数据库引擎。

单从字面看，Aurora不再是MySQL，而是MySQL+PostgreSQL，所以将来将会是 “MySQL+PostgreSQL+...+...”，各种数据库都将融于Aurora当中。这样提供强大无比的云数据库服务，此点非常重要，用户基于任何数据库的应用均不用修改应用的代码，无缝接入Aurora。

从技术的层面看，实现这样的目标，有多种方式。简单的方式，就是利用相同的云基础设施和云服务概念，把各个数据库单独云化，然后用Aurora统一命名。但如果进一步把计算层分离，如把语法解析、查询器、执行器拆分，不同种类的数据库使用各自的语法解析和查询优化，然后统一执行计划交给统一的执行器去执行，事务处理和数据存储则可以独自研发独立于上层的计算。如此，想象空间得以打开......

5 小结

本文探讨了Aurora的实现方面的技术内容，由于作者水平有限，错漏之处，请不吝指正。Aurora在实现方面的诸多细节，论文并没有提及，期待以此文抛砖引玉，期待多方指点讨论，共同进步。

附录

参考资料:

1. 《Amazon Aurora: Design Considerations for High Throughput Cloud Native Relational Databases》
2. https://aws.amazon.com/
3. 《数据库事务处理的艺术 事务管理与并发控制》，机械工业出版社，2017年10月出版
4. Aurora deep dive - Percona Live 2017
5. 《Level Up Your Games with Amazon Aurora》
6. 《High performance transactions in deuteronomy》