MIT6.824/lecture-10-cloud-replicated-db-aurora/10.1-aurora-bei-jing-li-shi.md

10.1 Aurora 背景历史

今天的论文是Amazon的Aurora。Aurora是一个高性能，高可靠的数据库。Aurora本身作为云基础设施一个组成部分而存在，同时又构建在Amazon自己的基础设施之上。

我们之所以要看这篇论文，有以下几个原因：

• 首先这是最近的来自于Amazon的一种非常成功的云服务，有很多Amazon的用户在使用它。Aurora以自己的方式展示了一个聪明设计所取得的巨大成果。从论文的表1显示的与一些其他数据库的性能比较可以看出，在处理事务的速度上，Aurora宣称比其他数据库快35倍。这个数字非常了不起了。
• 这篇论文同时也探索了在使用容错的，通用（General-Purpose）存储前提下，性能可以提升的极限。Amazon首先使用的是自己的通用存储，但是后来发现性能不好，然后就构建了完全是应用定制（Application-Specific）的存储，并且几乎是抛弃了通用存储。
• 论文中还有很多在云基础设施世界中重要的细节。

因为这是Amazon认为它的云产品用户应该在Amazon基础设施之上构建的数据库，所以在讨论Aurora之前，我想花一点时间来回顾一下历史，究竟是什么导致了Aurora的产生？

最早的时候，Amazon提供的云产品是EC2，它可以帮助用户在Amazon的机房里和Amazon的硬件上创建类似网站的应用。EC2的全称是Elastic Cloud 2。Amazon有装满了服务器的数据中心，并且会在每一个服务器上都运行VMM（Virtual Machine Monitor）。它会向它的用户出租虚拟机，而它的用户通常会租用多个虚拟机用来运行Web服务、数据库和任何其他需要运行的服务。所以，在一个服务器上，有一个VMM，还有一些EC2实例，其中每一个实例都出租给不同的云客户。每个EC2实例都会运行一个标准的操作系统，比如说Linux，在操作系统之上，运行的是应用程序，例如Web服务、数据库。这种方式相对来说成本较低，也比较容易配置，所以是一个成功的服务模式。

这里有一个对我们来说极其重要的细节。因为每一个服务器都有一块本地的硬盘，在最早的时候，如果你租用一个EC2实例，每一个EC2实例会从服务器的本地硬盘中分到一小片硬盘空间。所以，最早的时候EC2用的都是本地盘，每个EC2实例会分到本地盘的一小部分。但是从EC2实例的操作系统看起来就是一个硬盘，一个模拟的硬盘。

EC2对于无状态的Web服务器来说是完美的。客户端通过自己的Web浏览器连接到一些运行了Web服务的EC2实例上。如果突然新增了大量客户，你可以立刻向Amazon租用更多的EC2实例，并在上面启动Web服务。这样你就可以很简单的对你的Web服务进行扩容。

另一类人们主要运行在EC2实例的服务是数据库。通常来说一个网站包含了一些无状态的Web服务，任何时候这些Web服务需要一些持久化存储的数据时，它们会与一个后端数据库交互。

所以，现在的场景是，在Amazon基础设施之外有一些客户端浏览器（C1，C2，C3）。之后是一些EC2实例，上面运行了Web服务，这里你可以根据网站的规模想起多少实例就起多少。这些EC2实例在Amazon基础设施内。之后，还有一个EC2实例运行了数据库。Web服务所在的EC2实例会与数据库所在的EC2实例交互，完成数据库中记录的读写。

不幸的是，对于数据库来说，EC2就不像对于Web服务那样完美了，最直接的原因就是存储。对于运行了数据库的EC2实例，获取存储的最简单方法就是使用EC2实例所在服务器的本地硬盘。如果服务器宕机了，那么它本地硬盘也会无法访问。当Web服务所在的服务器宕机了，是完全没有问题的，因为Web服务本身没有状态，你只需要在一个新的EC2实例上启动一个新的Web服务就行。但是如果数据库所在的服务器宕机了，并且数据存储在服务器的本地硬盘中，那么就会有大问题，因为数据丢失了。

Amazon本身有实现了块存储的服务，叫做S3。你可以定期的对数据库做快照，并将快照存储在S3上，并基于快照来实现故障恢复，但是这种定期的快照意味着你可能会损失两次快照之间的数据。

所以，为了向用户提供EC2实例所需的硬盘，并且硬盘数据不会随着服务器故障而丢失，就出现了一个与Aurora相关的服务，并且同时也是容错的且支持持久化存储的服务，这个服务就是EBS。EBS全称是Elastic Block Store。从EC2实例来看，EBS就是一个硬盘，你可以像一个普通的硬盘一样去格式化它，就像一个类似于ext3格式的文件系统或者任何其他你喜欢的Linux文件系统。但是在实现上，EBS底层是一对互为副本的存储服务器。随着EBS的推出，你可以租用一个EBS volume。一个EBS volume看起来就像是一个普通的硬盘一样，但却是由一对互为副本EBS服务器实现，每个EBS服务器本地有一个硬盘。所以，现在你运行了一个数据库，相应的EC2实例将一个EBS volume挂载成自己的硬盘。当数据库执行写磁盘操作时，数据会通过网络送到EBS服务器。

这两个EBS服务器会使用Chain Replication（9.5）进行复制。所以写请求首先会写到第一个EBS服务器，之后写到第二个EBS服务器，然后从第二个EBS服务器，EC2实例可以得到回复。当读数据的时候，因为这是一个Chain Replication，EC2实例会从第二个EBS服务器读取数据。

所以现在，运行在EC2实例上的数据库有了可用性。因为现在有了一个存储系统可以在服务器宕机之后，仍然能持有数据。如果数据库所在的服务器挂了，你可以启动另一个EC2实例，并为其挂载同一个EBS volume，再启动数据库。新的数据库可以看到所有前一个数据库留下来的数据，就像你把硬盘从一个机器拔下来，再插入到另一个机器一样。所以EBS非常适合需要长期保存数据的场景，比如说数据库。

对于我们来说，有关EBS有一件很重要的事情：这不是用来共享的服务。任何时候，只有一个EC2实例，一个虚机可以挂载一个EBS volume。所以，尽管所有人的EBS volume都存储在一个大的服务器池子里，每个EBS volume只能被一个EC2实例所使用。

尽管EBS是一次很大的进步，但是它仍然有自己的问题。它有一些细节不是那么的完美。

• 如果你在EBS上运行一个数据库，那么最终会有大量的数据通过网络来传递。论文的图2中，就有对在一个Network Storage System之上运行数据库所需要的大量写请求的抱怨。所以，如果在EBS上运行了一个数据库，会产生大量的网络流量。在论文中有暗示，除了网络的限制之外，还有CPU和存储空间的限制。在Aurora论文中，花费了大量的精力来降低数据库产生的网络负载，同时看起来相对来说不太关心CPU和存储空间的消耗。所以也可以理解成他们认为网络负载更加重要。
• 另一个问题是，EBS的容错性不是很好。出于性能的考虑，Amazon总是将EBS volume的两个副本存放在同一个数据中心。所以，如果一个副本故障了，那没问题，因为可以切换到另一个副本，但是如果整个数据中心挂了，那就没辙了。很明显，大部分客户还是希望在数据中心故障之后，数据还是能保留的。数据中心故障有很多原因，或许网络连接断了，或许数据中心着火了，或许整个建筑断电了。用户总是希望至少有选择的权利，在一整个数据中心挂了的时候，可以选择花更多的钱，来保留住数据。 但是Amazon描述的却是，EC2实例和两个EBS副本都运行在一个AZ（Availability Zone）。

在Amazon的术语中，一个AZ就是一个数据中心。Amazon通常这样管理它们的数据中心，在一个城市范围内有多个独立的数据中心。大概2-3个相近的数据中心，通过冗余的高速网络连接在一起，我们之后会看一下为什么这是重要的。但是对于EBS来说，为了降低使用Chain Replication的代价，Amazon 将EBS的两个副本放在一个AZ中。