cs-6.824第10讲 Amazon Aurora

程序员小x2024年11月5日大约 8 分钟分布式系统分布式系统

cs-6.824第10讲 Amazon Aurora

今天要讲的论文来自Amazon的Aurora,探讨如何构建高性能、可靠的数据库,将其作为Amazon的云基础设施的一部分,也是建立在Amazon所提供的基础架构之上。

讲解Aurora的原因是它是Amazon非常成功的一项云服务。许多客户都在使用它。论文中提到其在交易吞吐量上实现了35倍的速度。

本文探讨了利用通用存储实现性能和容错性的极限,因为这样极限会产生瓶颈,因此Aurora放弃了通用存储。一开始使用的是Amazon自身通用的存储基础设施,但是发现不满足需求,进而构建了完全针对特定应用的存储系统。

Aurora的演进过程。

起初,Amazon推出的云服务旨在支持那些利用Amazon硬件及其机房搭建网站的用户,命名为EC2。亚马逊拥有庞大的服务器机房,在服务器中安装虚拟机监控程序,然后将虚拟机出租给客户。客户在租用虚拟机之后,就可以在上面部署网络服务器、数据库以及应用程序。

web    DB
ec2    ec2
   
    VMM

每一台虚拟机都会分配一个物理磁盘,租给客户的虚拟机会分得该磁盘的一部分。

EC2特别适合于网络服务器。

使用EC2的另一大应用是数据库,因为一个网络由一组无状态的web服务器组成,每当它们需要访问持久性数据时,就会与后端数据库进行通信。

           web      DB
c1         ec2      ec2


c2         ec2      ec2


c2         ec2      ec2

如果实际运行web服务器的硬件崩溃了,完全不用担心,因为它本身不保持任何状态,你只需要在新的EC2上重新启动一个新的web服务器。如果数据库实例的EC2发生崩溃而不可用,且数据存在本地磁盘上,那么这是一个严重的问题。

Amazon提供了一种大规模的数据存储方案,即S3。你可以定期对数据库的状态取快照,将其存储在S3中,以此为备份和灾难恢复只用。但这种周期性快照的方式意味着,你将丢失发生在定期备份之间的更新内容。

EBS- Elastic Block Store

使用EBS之后,运行在EC2实例上的数据库拥有了一个存储系统,该系统实际上能够在其依赖的硬件发生崩溃或损坏时幸存。 如果这台物理服务器宕机,您只需要启动另一个EC2实例,启动数据库,将之前的EBS挂载在就可以。

EBS不是一个共享系统,一个EBS只能被一台EC2挂载。EBS卷是在亚马逊庞大的存储服务器集群上实现的,这些服务器配备了数百块硬盘。

尽管EBS是一个进步,但它仍存在一些问题:

  • 如果你在EBS上运行数据库,最终会导致大量数据通过网络传输。它很大程度上受到了网络限制。
  • EBS的容错性并不够强,出于性能考虑,amazon总是将EBS卷的两个副本放在同一个数据中心内,如果单个服务器崩溃,比如你使用的两个EBS服务器中的一个发生故障,不必担心,可以切换到另一个上。但如果整个数据中心瘫痪,就没有任何应对方案。

典型数据库的设计

事务

事务就是一种将多个操作打包的方式,并声明这一系列操作对于任何读取或者写入该数据的,对于其他人来说呈现出原子性。因此,你可能会遇到这样的情况,假设我们正在运营一家银行,并希望在不同账户之间转账。

例如一笔银行转账,其事务可能如下所示:

BEGIN
    x = x + 10
    y = y -10
END

这些系统通常的实现方式,事务在访问每项数据之前都会进行加锁。例如上面的例子,在事务期间,对x和y都会进行上锁,只有在事务最终提交之后才会进行释放。

Aurora:

磁盘上还有一个预写式的日志,WAL, 而预写式日志式系统能够容错的关键部分。数据库通常拥有一个页面缓存,这些页面是从磁盘中读取的,且式从磁盘中读取的,且是最近使用过的。当你执行一个事务时,x=x+10, 数据库会读取x所在的数据页,在此基础上增加10,但截至目前为止,在事务提交之前,它仅仅在本地缓存中进行修改,并未写入磁盘。由于数据库希望预先声明完整的交易,以便在系统崩溃之后及恢复期间,软件仍可访问该交易信息,所以在数据库需要在修改磁盘上的实际数据页之前,首先需要添加该交易的日志条目。因此在提交事务之前,它必须按照顺序,将一组完整的预写日志条目放置在磁盘的预写日志中,以描述数据库的所有修改。

假设x和y的初始值分别是500和750,我们现在要执行这个事务,在提交之前,以及在写入页面之前,数据库通常至少会添加三条日志,其中一条日志表明我正在修改x,其旧值为500?

学生提问:为何需要存储旧值,而非直接让x变为5和10?

回滚操作时需要用到。Aurora确实采用了撤销/重做日志记录机制,以便能够撤销部分已应用的事务。

如果数据库能够成功地将事务日志记录写入磁盘,并标记提交记录以示完成,那么它就有权向客户端回复,客户端确信其事务将永久可见。如果数据库服务器没有发生崩溃,则最终,其缓存中的x和y记录的值将更新为510和740。最终会将更新的数据写入磁盘上的实际位置,覆盖这些B树节点或其他内容。

RDS服务

RDS可以在多个可用区中进行复制,如果整个数据中心发生故障,你可以恢复数据库内容而不会遗漏。RDS的配置提供了更好的容错能力,因为拥有了一个完整且最新的数据库副本。 这个过程开销是极大的。 Mysql比Aurora慢的原因,基本上是在较慢的网络链接上发送了大量数据。

Aurora

Aurora拥有6个副本,分布在三个可用区之中。写操作要发送到这六个副本的每一个。(为什么不慢呢?)

Aurora通过网络传播的只有日志记录,那是成功的关键,日志记录通常而言是小的,而数据库写磁盘时通常是的页面为单位的,这些数据相对而言比较大。

但是由于EBS是一个通用的存储,它并不认识mysql的日志,因此Aurora放弃了通用存储,而开发了专用存储设备。

另一点,系统无需等待所有六个副本确认写入操作,数据库便可继续运行。只需要达到4台,数据库便可持续运行,这种法定人数方法,减少了开销。

法定人数(Quorum)

希望在某一个AZ失效的情况下,依然能够可以写,在一个可用区失效外加另一台服务器失效的情况下,仍然能够读。

希望即使存储服务器出现顺势慢速或短暂不可用的情况下,系统仍然可以持续运行。

如果某个存储服务器发生故障,那么在下一个存储服务器出现故障之前,具有快速复制的能力。

通常来说法定人数属于简单的读写系统,存储系统,它们一般不直接支持更复杂的操作,

N 副本

W 写 R 读

R+W > N

这里获取了R个读取的结果,如果这些值不相同该如何处理。

投票机制并不能工作,因为数量不一定是偶数。 添加版本号机制。

希望在某一个AZ失效的情况下,依然能够可以写,在一个可用区失效外加另一台服务器失效的情况下,仍然能够读。

N=6, W=4 , R=3

Loading...