> For the complete documentation index, see [llms.txt](https://mit-public-courses-cn-translatio.gitbook.io/mit6-824/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://mit-public-courses-cn-translatio.gitbook.io/mit6-824/lecture-10-cloud-replicated-db-aurora/10.4-aurora-chu-tan.md).

# 10.4 Aurora 初探

这一部分开始介绍Aurora。整体上来看，我们还是有一个数据库服务器，但是这里运行的是Amazon提供的定制软件。所以，我可以向Amazon租用一个Aurora服务器，但是我不在上面运行我的软件，我租用了一个服务器运行Amazon的Aurora软件。这里只是一个实例，它运行在某个AZ中。

在Aurora的架构中，有两件有意思的事情：

第一个是，在替代EBS的位置，有6个数据的副本，位于3个AZ，每个AZ有2个副本。所以现在有了超级容错性，并且每个写请求都需要以某种方式发送给这6个副本。这有些复杂，我们之后会再介绍。

![](/files/-MFePvsiy7BTHzraaR4e)

现在有了更多的副本，我的天，为什么Aurora不是更慢了，之前Mirrored MySQL中才有4个副本。答案是，这里通过网络传递的数据只有Log条目，这才是Aurora成功的关键。从之前的简单数据库模型可以看出，每一条Log条目只有几十个字节那么多，也就是存一下旧的数值，新的数值，所以Log条目非常小。然而，当一个数据库要写本地磁盘时，它更新的是data page，这里的数据是巨大的，虽然在论文里没有说，但是我认为至少是8k字节那么多。所以，对于每一次事务，需要通过网络发送多个8k字节的page数据。而Aurora只是向更多的副本发送了少量的Log条目。因为Log条目的大小比8K字节小得多，所以在网络性能上这里就胜出了。这是Aurora的第一个特点，只发送Log条目。

当然，这里的后果是，这里的存储系统不再是通用（General-Purpose）存储，这是一个可以理解MySQL Log条目的存储系统。EBS是一个非常通用的存储系统，它模拟了磁盘，只需要支持读写数据块。EBS不理解除了数据块以外的其他任何事物。而这里的存储系统理解使用它的数据库的Log。所以这里，Aurora将通用的存储去掉了，取而代之的是一个应用定制的（Application-Specific）存储系统。

另一件重要的事情是，Aurora并不需要6个副本都确认了写入才能继续执行操作。相应的，只要Quorum形成了，也就是任意4个副本确认写入了，数据库就可以继续执行操作。所以，当我们想要执行写入操作时，如果有一个AZ下线了，或者AZ的网络连接太慢了，或者只是服务器响应太慢了，Aurora可以忽略最慢的两个服务器，或者已经挂掉的两个服务器，它只需要6个服务器中的任意4个确认写入，就可以继续执行。所以这里的Quorum是Aurora使用的另一个聪明的方法。通过这种方法，Aurora可以有更多的副本，更多的AZ，但是又不用付出大的性能代价，因为它永远也不用等待所有的副本，只需要等待6个服务器中最快的4个服务器即可。

![](/files/-MFeUqcl88TOMZS9n1Zu)

所以，这节课剩下的时间，我们会用来解释Quorum和Log条目。论文的表1总结了一些结果。Mirrored MySQL将大的page数据发送给4个副本，而Aurora只是将小的Log条目发送给6个副本，Aurora获得了35倍的性能提升。论文并没有介绍性能的提升中，有多少是Quorum的功劳，有多少是只发送Log条目的功劳，但是不管怎么样，35倍的性能提升是令人尊敬的结果，同时也是对用户来说非常有价值的结果。我相信对于许多Amazon的客户来说，这是具有革新意义的。