Amazon Aurora深度探索--第二篇--存储架构

内容简介：Amazon Aurora深度探索--第二篇--存储架构

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

如图 1-7 所示，主机 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 被称为 （ Volume Complete LSN ）。

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

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

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

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

q   数据不再从数据缓冲区刷出，消除了随机写操作，减少了 IO 。

q   计算和存储分离，日志跨 AZ 写到多份存储节点，存在网络 IO 。

q   主备节点间传输日志和元数据，存在网络 IO 。

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

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

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

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

种： 读写均可用。

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

保障读写可用图

    第 2 种： 至少读可用。

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

图 1-9 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 部署表

目前的区域（ Region ）和可用区（ AZ ）数量	即将推出的区域
AWS GovCloud (2 个 ) 美国西部：俄勒冈 (3 个 ) 、加利福尼亚北部 (3 个 ) 美国东部：弗吉尼亚北部 (5 个 ) 、俄亥俄 (3 个 ) 加拿大：中部 (2 个 ) 南美洲：圣保罗 (3 个 ) 欧洲：爱尔兰 (3 个 ) 、法兰克福 (2 个 ) 、伦敦 (2 个 ) 亚太地区： 新加坡 (2 个 ) 、悉尼 (3 个 ) 、东京 (3 个 ) 、首尔 (2 个 ) 、孟买 (2 个 ) 中国：北京 (2 个 )	巴黎 宁夏 斯德哥尔摩

首先，存储层与事务管理分离，即 ACID 的 D 特性独立，使得存储有机会成为独立的服务而存在，便于跨数据中心时实现数据的容错（ fault-tolerant ）、自愈（ self-healing service ） [3] 和快速迁移。一旦存储层具备了容错、自愈和可快速迁移特性，则对外提供服务就不用再担心数据的短暂或长久的不可用性。在数据为王的时代，此举能保护好最核心的财产，确保云数据库服务能持续不断地对外提供服务，这使得 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

节）。

以上所述就是小编给大家介绍的《Amazon Aurora深度探索--第二篇--存储架构》，希望对大家有所帮助，如果大家有任何疑问请给我留言，小编会及时回复大家的。在此也非常感谢大家对 码农网 的支持！

查看所有标签

猜你喜欢:

• 人工智能深度学习Caffe框架介绍，优秀的深度学习架构
• 微服务架构体系的深度治理
• 深度学习的未来：神经架构搜索
• ​微服务架构体系的深度治理
• 应对深度学习人才缺口，百度黄埔学院发起深度学习架构师培养计划
• 7大类深度CNN架构创新综述

本站部分资源来源于网络，本站转载出于传递更多信息之目的，版权归原作者或者来源机构所有，如转载稿涉及版权问题，请联系我们。