Amazon Aurora 深度探索（二）

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

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

2 Aurora的存储架构

存储层的设计和实现，体现了“the log is the database”，其含义是日志中包含了数据的信息，可以从日志中恢复出用户的数据，所以数据不一定必须再独立存储一份。而数据库的核心不仅是数据，保障数据的拥有ACID特性的事务和提供便捷查询的SQL语句、对以数据为基础提供商业的交易服务更是必不可缺失，所以更精确的说，“the log is the data”，日志就是数据也许更为合适。在笔者看来，数据库的价值不仅在数据，还在数据库的相关技术，尤其在现代巨量数据下、完备的数据库理论下，对以分布为要求的数据库架构提出新的工程实践挑战。Aurora就是走在这样的实践道路上的楷模。

2.1 存储层的工作

如图1-8所示，主机Primary RW DB写出的REDO日志（MySQL生成的日志带有LSN，Log Sequence Number，单调递增的日志顺序号）信息发送到六个Sotrage Node中的每一个Sotrage Node上的时候，只存在一个同步瓶颈点，就是图中标识为❶之处，这是Aurora的一个核心设计点，尽量最小化主节点写请求的延时。在存储节点，传输来的日志进入一个队列等待被处理。

之后日志被快速持久化到物理存储设备，并立刻给主机一个回应。这是标识为❷的处理过程，这个过程极其简单，没有额外的操作，因而速度会很快，这样能够满足如上所说的“尽量最小化主节点写请求的延时”的设计理念。❶和❷之后的其他操作，都是异步操作，不影响系统的整体性能。这样当主机Primary RW DB收到六个Sotrage Node中的四个节点的ACK后，就认为日志成功写出，可以继续其他工作了。

❸所做的工作，是对持久化了日志做处理，如排序/分组等操作作用在日志上，以便找出日志数据中的间隙，存在间隙的原因是多数派写日志的机制下，少数派可能丢失日志从而导致日志不连贯。

❹所做的工作，就是从其他存储节点（6个存储节点构成一个PG ，即Protection Group，每个节点是一个segment，存储单位是10G，位于一个数据中心中。6个存储节点每2个位于一个AZ，共分布于3个AZ）中，通过Gossip协议，来拉取本节点丢失的日志数据，以填充满所❸发现的日志间隙。在❸和❹的过程中，能发现所有的副本中：相同的、连续的日志段是哪一部分，其中最大的LSN被称为VCL（Volume Complete LSN）。

❺所做的工作，就是从持久化的日志数据中，产生数据，就如同系统故障时使用REDO日志做恢复的过程：解析REDO日志，获取其中保存的数据页的修改后像，恢复到类似于传统数据库的数据缓冲区中（这也是存储层需要存在“Caching”的一个明证）。

之后，第六步，周期性地把修复后的日志数据和由日志生成的以页为单位的数据刷出到S3做为备份。第七步，周期性地收集垃圾版本（PGMRPL，即Protection Group Min Read Point LSN），参考表1-2，可以看到，垃圾收集，是以VDL为判断依据的，当日志的LSN小于VDL，则可以被作为垃圾回收；第八步，周期性地用CRC做数据校验。

图1-8 日志数据在存储节点的处理过程图

2.2 储存层的设计讨论

现在再来反观Aurora的整体设计：

• 数据不再从数据缓冲区刷出，消除了随机写操作，减少了IO。
• 计算和存储分离，日志跨AZ写到多份存储节点，存在网络IO。
• 主备节点间传输日志和元数据，存在网络IO。

如上是三条核心点，似乎网络IO占了三分之二条，属于多数。但是网络IO都是批量数据顺序写，可极大地抵消很多次的随机写的网络IO消耗，而且通过数据冗余，极大地保障了可用性和云数据的弹性，从测试数据看，整体性能得到了可观的提升。因此这样的设计是一个优秀的架构设计。

数据冗余且有效，是使用数据库系统的基本要求。逻辑备份与还原、物理备份与恢复、主从复制、两地三中心等灾备技术方案等都是数据冗余的相关技术。数据库走向对等分布式架构，除了应对巨量数据的存储和计算的需要，也要靠数据冗余来保证数据的可用性。所以数据冗余是数据系统架构设计的一个必须考虑点。

Aurora自然也要实现数据冗余。如图1-5所示，数据至少在3个AZ中存6份。如果不采用“the log is the database”的理念，而使用传统数据库的技术，在跨节点写出多份数据时，势必需要采用2PC/3PC等多阶段的方式来保证提交数据的正确性，这样网络交互的次数就会很多，而且大量的随机写操作会在网络蔓延。所以“the log is the database”的理念客观上避免了传统的、耗时昂贵的分布式事务的处理机制，而又达到了数据分布的目的，这又是一个亮点。

数据至少在3个AZ中存6份，其目的是要保证数据库服务的持续可用。那么，什么算是可用呢？无论是数据中心内部的局部故障还是跨数据中心甚至跨AZ出现故障，AWS也要在某些情况下提供数据服务的可用。这就要分两种情况确定，这两种情况基于6个副本的前提（3个副本能满足多数派的读写规则，但是一旦其中一个副本不可用，则其余2个就不能保证读写一致，基于3个副本的分布式设计是脆弱的，不能切实可用地起到依靠数据冗余来换取数据可用的保障）：

第1种： 读写均可用。

如图1-9，当一个AZ出现问题，即2个副本不可用，Aurora仍然能够保证读写可用，保障数据一致。设置V=6，读多数派为Vr = 3，写多数派为Vw = 4，所以一个AZ出现故障，或者3个AZ中的两个数据中心出现故障，Aurora依然能够向外提供服务。

图1-9 Aurora保障读写可用图

第2种： 至少读可用。

当写服务不可用，至少还可以提供读服务。设置V=6，读多数派为Vr = 3，写多数派为Vw = 4时，一个AZ出现故障依旧能够提供读服务，如图1-10甚至跨不同AZ的3个数据中心出现故障（概率非常小），读服务依旧能够提供。

图1-10 Aurora保障读可用图

在1.1节，曾经说过“主从节点可以位于不同的AZ（最多位于3个VPC，需要3个AZ）但需要位于同一个Region内”。如表1-1所示，AWS在全球提供的AZ个数尚有限，按其自身的说法部署一个Aurora需要三个AZ，那么诸如只有2个AZ的Region如北京，尚不能得到较可靠的数据可用保障。

表1-1 至2017年6月AWS的Region和AZ部署表

2.3 Aurora设计的优点

首先，存储层与事务管理分离，即ACID的D特性独立，使得存储有机会成为独立的服务而存在，便于跨数据中心时实现数据的容错（fault-tolerant）、自愈（self-healing service）和快速迁移。一旦存储层具备了容错、自愈和可快速迁移特性，则对外提供服务就不用再担心数据的短暂或长久的不可用性。在数据为王的时代，此举能保护好最核心的财产，确保云数据库服务能持续不断地对外提供服务，这使得Aurora具备了云服务的弹性。此点在AWS看来，十分重要。有了这种需求，推动技术架构发生变化便水到渠成。

服务的过程中，局部数据修复的能力，速度很快。数据库宕机后的恢复，速度也很快。

Once the database starts up it performs volume recovery in collaboration with the storage service and as a result, an Aurora database can recover very quickly (generally under 10 seconds) even if it crashed while processing over 100,000 write statements per second.

服务中断后，最后的招数就是数据迁移加数据库引擎重新部署，而AWS的整个云系统具备了快速迁移数据的能力，这使得以存储为核心的云数据库有了超强的持久服务能力。

We monitor and automatically repair faults as part of our service. A 10GB segment can be repaired in 10 seconds on a 10Gbps network link. We would need to see two such failures in the same 10 second window plus a failure of an AZ not containing either of these two independent failures to lose quorum. At our observed failure rates, that’s sufficiently unlikely, even for the number of databases we manage for our customers.

其次，存储层从高度耦合的数据库引擎中分离，降低了数据库引擎的复杂度，数据库组件的分离使得数据库部署适应巨量数据的分布式处理需求。这将进一步带动数据库引擎上层的语法分析、查询优化、SQL执行、事务处理等组件进一步的解耦。

笔者认为，这是Aurora用实践为数据库架构技术的发展指出的可行方向。一个具有实践意义的分布式发展架构，总是最亮眼的，也总是具有指导意义的。存储与计算解耦，各种组件互相解耦，不断解耦...在此种思路下，AWS已经走在发展万能数据库引擎的道路上（参见4.2节）。