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节)。

原创声明,本文系作者授权云+社区发表,未经许可,不得转载。

如有侵权,请联系 yunjia_community@tencent.com 删除。

编辑于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏SAP最佳业务实践

SAP最佳业务实践:ETO–项目装配(240)-6审批 WBS 要素

image.png CJ20N审批 WBS 要素 为确保预先采购(下个步骤),WBS 要素的状态必须为 已释放。 角色项目经理 后勤®项目系统®项目®项目构造...

39760
来自专栏Debian社区

Debian 成为主流 Linux 操作系统的七个原因

Debian也许是历史最悠久的发行版之一,但很显然,它仍可以教其他发行版好几招。要是没有Debian,Linux领域的境况会大不一样,会黯然失色好多。Debia...

10820
来自专栏张戈的专栏

首页快照不更新么?投诉试试吧!

过年在家由于网络问题,半个月都没顾得上博客,回来后又是换空间,又是修改网站名称以及描述等内容,导致百度快照一直停在了 2014-01-23 ,硬是保持了一个多月...

403150
来自专栏CDA数据分析师

Python趣味编程:定时给Ta讲笑话

大四的生活就是这么无聊,我琢磨着也学了这么多东西了,为啥不能用自己的知识来给生活找点乐子呢?我想反正每天都要给Ta问候一声早安,为何不同时讲个笑话呢?如果能写个...

44790
来自专栏架构师之旅

Mysql在大型网站的应用架构演变

写在最前: 本文主要描述在网站的不同的并发访问量级下,Mysql架构的演变 可扩展性 架构的可扩展性往往和并发是息息相关,没有并发的增长,也就没有必要做高可扩展...

20680
来自专栏程序猿DD

初级Java程序员需要掌握哪些主流技术才能拿20K?

傻呀,干嘛不使用全文检索工具lucene或者分布式搜索Elasticsearch来优化搜索服务。

57020
来自专栏SEO

Google新动作:处理重复内容

356100
来自专栏北京马哥教育

24步成为后端开发工程师(2018版)

18050
来自专栏跟我一起学Docker

【番外篇】ETCD学习

etcd是一个开源的、分布式的键值对数据存储系统,提供共享配置、服务的注册和发现。etcd与zookeeper相比算是轻量级系统,两者的一致性协议也一样,etc...

12640
来自专栏腾讯云技术沙龙

邹鹏:Redis数据库云端最佳技术实践

这次过来主要是和大家分享一下,腾讯云上个月正式上线的Redis4.0集群版的相关内容,跟大家分享我们在做集群版的时候有哪些思考,我们怎么去设计整个系统架构,最终...

37570

扫码关注云+社区

领取腾讯云代金券