概览
Aurora是AWS提供的Relational Database Service之一，面向OLTP型业务场景。
核心思想
数据处理的性能瓶颈已经从存储和计算转移到了网络。
解决方案
将RedoLog从内核下推到Aurora的多租户可扩展存储服务。
介绍
存算分离
在现代分布式云服务中，弹性和可扩展性大多通过存算分离实现，上层无状态，下层共享分布式存储。
分布式存储的引入使得IO操作能够并发执行，但有好处也有坏处，由于本地IO到网络IO的转变，使得系统性能会受到网络环境的限制。
除此之外，传统数据库架构的2PC、3PC分布式事务协议，由于对网络环境要求较高，将不再适用于共享分布式存储架构。
内核拆解
Aurora一样是使用存算分离架构，为了解决上述问题，将RedoLog下推到存储层，上层只需要向存储层写RedoLog，减少网络IO，并且RedoLog的相关功能如故障恢复、备份还原，由存储层异步处理。
WAL落到存储层的好处？
- 容错性更好。
- IOPS更低。
- 异步复制与恢复。
大规模系统的持久性
Aurora采用Quorum实现存储层的持久性，设节点总数为T，每次写入N个节点，每次读取M个节点，有Quorum的约束，N+M>T成立，又因为每次写入需要感知到上一次的写入，因此N>T/2成立。
仔细思考，Quorum保证了写入的数据一定会被读取到。
地域和可用区
云计算公司的机房一般会划分为好几个地域（Region），例如华北一个机房，华东一个机房。每一个地域又分为若干个电力和网络等互相隔离的可用区（AZ），相同Region的AZ之间可以内网互通。
节点部署在相同的AZ中，网络时延更低；部署在不同的AZ中，容灾能力更好。在Auraro中，使用3个AZ，每个AZ持有2个副本，写4读3的方案。
分段存储
如果在一个错误发生，并在该错误修复前又发生了一个错误，那么Quorum很可能被打破，通过降低修复错误的时间可以降低打破Quorom的概率，Aurora通过分段存储解决这个问题。
将数据库卷拆分为若干个10GB大小的数据段，每个段有6个副本，称这6个副本为一个Protection Group，平均分布在3个ZA上。分段后每段空间更小，恢复数据的速度也就更快。
日志即数据库
上面提到的Quorum+Group模型，IO会被复制放大，同时大量的IO会产生同步等待，即便使用链式复制，也要面对同步延迟的问题。
传统数据库的写入会先修改数据页，接着记录WAL，而在Aurora中，数据库层面不会改动数据页，只会记录WAL，日志应用程序会在后台异步的应用WAL生成数据页。
上图结构中，主实例记录日志到存储层，等待6个副本中的4个响应成功，副本负责将日志应用到数据页。虽然这样同样6倍放大了写操作，但大大降低了网络负载。
一致性原理
因为有了日志，所以就不再需要2PC来做一致性了，而是可以通过异步的方式保持状态一致性。在Aurora中，每个副本维持两个值：VCL和CPL，分别表示已应用的最大日志序列号，和已达成共识的最大日志序列号。并在恢复的时候对大于VDL（小于等于VCL的最大的CPL）的日志进行截断。
写到这不禁想起了Raft，这不和lastCommitted和lastApplied什么的是一样的么？
关于读操作会不会读不到最新数据的问题，Auraro为读操作也关联了一个LSN（日志序列号），通过日志的顺序应用确保读的数据页是最新的。
End
本文主要说了share disk、6副本、WAL这些东西，不是很细，主要是怕写多错多，更细的可以看看原文。非专业文章，如有错误万望指出。
