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 条评论
登录 后参与评论

相关文章

来自专栏IT大咖说

2018,换个角度看微服务监控与性能优化

摘要 主要介绍分布式监控的基本概念及方法,java技术栈相关监控机制,性能监控、业务监控、异常监控、性能数据分析在融数微服务平台的实践及应用。 ? 微服务监控 ...

3299
来自专栏服务端技术杂谈

重构系统的套路-提高并发能力

比如我们在某段业务逻辑中加了一个同步写kafka的操作,tp99瞬间多了30毫秒,这样在整个监控曲线看起来非常扎眼,于是我们需要将这个同步改成异步。

692
来自专栏北京马哥教育

基础拾遗--【转】性能测试的主要概念和计算公式

PS:下面是性能测试的主要概念和计算公式,记录下: 一.系统吞度量要素: 一个系统的吞度量(承压能力)与request对CPU的消耗、外部接口、IO等等紧...

2838
来自专栏互联网高可用架构

互联网性能与容量评估的方法论和典型案例5 性能评估参考标准

2194
来自专栏前端架构

系统吞吐量、用户并发量、Tps与Qps的星际大战

最近一直被这两个名词困扰,查阅很多资料,对于Web应用而言,有的地方说Qps等同于Tps,也有的地方说Qps等同于并发数。

621
来自专栏云计算D1net

云存储安全问题首当其冲 三个步骤不可少

目前市场上仍然存在大量的中小型企业由于缺少投入,管理水平较低,而在数据资源的管理上缺乏有效的管理机制,迫切需要实现基本的文档集中存储、传递与共享,云存储应运而生...

2055
来自专栏云计算D1net

私有云架构建设, 你做好准备了吗?

私有云基础架构的构成要素 随着越来越多的企业设定了构建内部云服务的目标,规划和构建企业内部云服务平台就成为IT部门的职责。每个企业都有自己特有的环境和具体的目标...

3166
来自专栏后台系统海量服务

自适应柔性模型

“弃车保帅”, 是对柔性的一个最形象的描述。但是传统的柔性,一般存在各种缺陷。

1395
来自专栏微服务生态

看来微服务就是一把双刃剑

微服务是银弹吗?自2014年“微服务”一词真是越来越火,不谈Microservices彷佛就out了,那么我们先来看微服务具有哪些特点:

661
来自专栏微服务生态

跟着小程来学微服务--微服务思想

一直对微服务非常感兴趣,因为公司的架构改造正好有机会能够接触微服务,买来一些书,请教了很多微服务大牛同时自己也做了很多总结,写成了80页ppt,算是我对微服务的...

634

扫码关注云+社区