云上的数据库怎么做？浅析AWS上Aurora的设计理念

本文来自个人微信公众号：奔跑中的蜗牛

要提升个人能力，研究大型互联网公司的架构是相当有必要的，今天给大家分享一篇论文。Amazon在SIGMOD 2017发表了论文《Amazon Aurora: DesignConsiderations for High Throughput Cloud-Native Relational Databases》，里面包含的内容很多，建议每一个关注分布式系统的技术人员都应该仔细读一遍。

Aurora是什么？

Aurora是AWS上的分布式关系型数据库，早在2014年，在AWS re:Invent大会上，AWS就宣布推出Amazon Aurora。这是一个面向亚马逊关系数据库服务（RDS）的兼容MySQL的数据库引擎，Aurora完美契合了企业级数据库系统对高可用性、性能和扩展性、云服务托管的需求。目前的Aurora可跨3个可用区的6-路复制、30秒内便可完成故障转移、同时具备快速的crash recovery能力。在性能方面，Aurora现在比RDS MySQL 5.6和5.7版本快5倍。

Aurora整体的架构设计

Aurora的架构并不是类似于Google Spanner的NewSQL数据库，而是一种基于mysql实现的数据库，复用了很多mysql的功能，因此mysql的用户可以完美的切换到Aurora。相对于NewSQL数据库，Aurora显得并没有那么惊艳，但是却非常实用。

Aurora的设计理念是“日志就是数据库”，不只是在Aurora的设计理念中，在很多分布式系统中，日志代表的意义都非同一般，可以说，日志就是一切，Aurora的设计者认为，当前海量数据处理的主要瓶颈已经从计算、存储IO转移到了网络IO，在分布式场景下，只要网络IO足够，很多分布式系统的架构设计都可以重新考虑，为了解决网络IO的问题，Aurora将计算和存储分离，也就是说数据库把所有的日志和存储从mysql中剥离出来，放到S3上，通过将重做日志记录写入存储层，系统可以将网络的IOPS减少一个数据量级。查询处理、事务、缓存等数据库的核心功能都还是在计算层的mysql实例中处理，但是持久化、备份恢复等能力都已经移到了S3上。

降低写次数

 

我们都知道传统数据库有写放大问题，也就是本来一条记录，到数据库层面，要写各种日志（redolog、undolog、binlog），数据要写4分，至少要进行4次网络IO，并且有3次是串行的，这就是性能差的原因。Aurora的整个方案可以理解为CQRS模式，也就是写的时候只要写入队列即返回，读的时候走缓存。

 如图所示，它涉及以下步骤： 

（1）接收日志记录并添加到内存中队列， 

（2）持久化记录，并给客户端返回， 

（3）归类日志，并确认有哪些丢失了， 

（4）通过GOSSIP协议与其他节点交互， 

（5）将日志记录合并到新数据页， 

（6）定期将日志和新页存储到S3， 

（7）定期垃圾收集旧版本， 

（8）定期验证页面上的CRC码。 只有1、2步需要串行，后面都是异步的。

怎么实现扩展性及高可用

 

如图所示，Aurora由3个跨AZ（可以理解为同城的数据中心）的实例组成，一个主实例和多个副本实例（可以扩展到15个），写只能通过主实例，读则可以通过任何实例进行，主实例与副本实例或者存储节点间只传递redo日志和元信息。每个AZ存储两个副本，主实例并发向6个存储节点和副本实例发送日志，当4/6的存储节点应答后，则认为日志已经持久化，不必等待6个节点全部返回。注意，Aurora提供了6副本能力，但是并没有分片。 去年Aurora发布了multi-master，允许多节点写入，但是并没有相关的设计描述放出来。

Aurora的设计目标是要满足以下场景， 

1、如果三个AZ中有一个AZ挂掉还可以写 

2、如果三个AZ中有一个AZ挂掉，另外两个没有挂掉的AZ中有一个实例挂掉了，不影响读，且不会丢失数据 

很明显，根据Quorum协议，是满足要求的，W=4，R=3，N=6，满足W+R>N，且满足2W>N,是为了解决写冲突，两次写入必须有交集，这样才能在写的过程中解决写冲突。

 仔细研究发现，如果在三个AZ存储5份数据，写3份，读3份，实际上也能满足以上要求，并且节点数更少，通信的压力也更小，那么为什么要6节点呢？就是为了满足上面第2个要求，“如果三个AZ中有一个AZ挂掉，另外两个没有挂掉的AZ中有一个实例挂掉了，不影响读”，另外，当某个节点出现故障的时候，Aurora能够快速恢复，在10Gbps网络下（有钱任性），一个10G的分片可以在10s内恢复，也就是说当一个AZ出现了问题，另外两个没有挂掉的AZ中有一个实例挂掉了，对写的影响只有10s。

本文由笔者根据论文总结，不免有疏漏之处，仅供参考，论文中还有很多有意思的点，读者可以自行研究。

论文地址：https://www.allthingsdistributed.com/files/p1041-verbitski.pdf