本文从可用性、性能、数据一致性三个角度对Aurora是否可以称为“全球化”数据库进行了分析。文章作者来自CockroachLabs，与Aurora存在商业竞争关系，客观性受到潜在影响，但整体上仍有阅读价值。
原文链接：
https://www.cockroachlabs.com/blog/just-how-global-is-amazon-aurora/
许多数据库宣称自己是“全球化的”，虽然没有官方定义，但我们认为这个概念值得拆解。如果某个产品承诺具有全球化能力，那它至少要满足三方面的要求：
全球化的可用性：利用节点在地理分布上的多样性，保证数据可用。它应该始终处于运行状态，能够抵御设施故障和自然灾害。
全球化的性能：支持的策略能够将数据复制到访问频繁（读和写）的地点，实现优的全球延迟。
全球化的一致性：即使全球化分散部署，也能保证数据的一致性
Amazon Aurora
Amazon Aurora 主要采用单区域（singleregion）部署模式。针对读负载较重的场景进行了优化，写操作被限制在单区域内的单主节点（single master node）上。因为全球的写操作都被汇聚到单个区域的一个写节点上，所以无论怎么部署都会遇到延迟的问题。
Aurora的标准实例是用单个写节点处理数据库的全部写操作；同时部署很多读节点，满足读吞吐能力的要求，读节点跨多个AZ（availability zone）但必须在一个区域内。Aurora使用自定义的分布式存储层替代了本地存储，这个存储层由跨多个AZ的SSD存储设备组成。
写数据时会产生6个副本，分布在三个AZ中，每个AZ存储两个副本。当6副本中的4个写入提交后，整个事务就会提交。同时，Aurora使用MySQL或PG作为执行引擎，这个新方法减少了读延迟，还提供了冗余。相对传统自带存储的巨石架构，它更具弹性。
AmazonAurora Global Database
去年底，Amazon推出了Aurora全球化数据库，原有的单区域架构发生了改变，允许将读副本扩展到一个附加区域。扩大了读操作的覆盖范围，减少了到附加区域的地理距离延迟。两个区域间通过存储层的异步复制方式，保证数据的同步。
主实例包括写入节点，第二个实例完全由只读节点构成，所以只是为附加区域扩展了读操作能力。
故障发生时，Aurora 全球化数据库允许将附加区域的一个只读节点提升为主写入节点，这样在发生区域性事件时，能够提供业务连续性。但是，由于区域间是异步复制的，数据存在丢失的可能性，多为1秒钟（RPO不为零），而读节点升级为主写节点耗时多为一分钟（RTO为1分钟）。
Aurora Multi-Master
前俩种配置都依赖于数据的单点写入。这意味着单点故障引发故障转移风险还有一个重要的RTO问题。此外，单点显然限制了写扩展性，全球化应用系统执行操作时，必须容忍与写节点所在区域间的网络往返开销。对那些写节点区域以外的用户来说，这种地理位置造成的延迟将带来显著的性能影响。这是全球化性能的一个大问题
Amazon通过推出多主架构（Multi-Master）来解决这个问题，近在四个区域上市，包括US East (N. Virginia), US East (Ohio), US West (Oregon), and EU(Ireland)。多主架构允许存在第二个写节点，但不允许副本读。这就是说大写入吞吐量翻倍，而代价是大读取的吞吐量显著降低。事实上，一个完整的读操作被割裂到两个节点，由应用程序中来决定到底查询哪个节点。这也意味着，无法向其他区域扩展读取能力。
AWS的文档介绍了多主产品的附加限制和适用场景。多主模式不支持可串行化隔离级别。虽然Aurora不断改进，但架构设计时间久远，当初没有考虑支持跨区域操作的可扩展性。
它的架构可能会将多主模式永远限制在单个区域，因为在每次读操作过程中要与所有写节点通讯，避免超时。这种一致性上的开销会随着写节点的数量同步增加。对多主架构来说，增加支持额外的区域将提升复杂度，同时引入了地理延迟带来性能的显著下降。
Amazon Aurora vs Global availability
全球化企业必然意味着多于两个区域。让我们总结一下，我们上面定义的全球化运营的三个要求来评估Aurora的产品。
首先也是重要的，Aurora几乎不能全球化，它只允许向一个附加区域扩展读副本，而全球化则需要向其他区域开放。
还要注意，当启用附加区域后，向其复制数据会带来费用的增加。所以你必须小心选择部署在哪个区域，确定能够覆盖合理的延迟，并注意你的成本。
这个架构还有很多RPO/RTO的提升空间。当写节点失效时，Aurora在一分钟以内将读节点提升为写节点。RPO非零即意味着数据丢失。如果你的工作场景不能接受这一点，并不适合选择Aurora。
分钟级的RPO适于一些工作场景但不是所有。然而，当一个区域失效，RPO时间还会更长。如果整个区域失效（罕见但有可能），Aurora会很聪明的在第二区域启动一个新的写节点作为主节点。这个过程耗时几分钟，而你无法知道数据的状态。不在线的这段时间，你会丢失数据。一旦主节点上线，需要同步数据和清理问题。
Amazon Aurora vs Global Performance
谈到性能，有两个问题困扰着Aurora。点是上面说到的，依靠单个写入节点应对全球化的写入，第二点是它仅能在一个附加区域扩展读副本（多主模式还不支持）。这个架构面对物理性延迟时，性能会被压缩。
它在一个区域内性能很好，在一个可用区内能够处理故障转移。然而，单个写节点造成了写延迟问题。因为所有的写入都在写节点执行，客户端与该节点的距离决定了延迟时间。让我们考虑一种部署情况，你有一个实例在里士满。东海岸的用户可以低延迟读写，而位于美国另一端的洛杉矶，少要70ms的延迟。
我们可以扩展到另一个区域，两个区域会带来更好的读取性能，但写入依然单线程的，会增加性能开销。刚才的场景还可以满足，但如果你走向全球化呢？如果写入实例在里士满，如何让悉尼用户有可接受的写延迟呢？后，为了真正的全球化部署，你要尽可能让数据靠近使用它的地方。对于真正的分布式数据库，达到毫秒级的读写延迟是非常重要的。由于复杂的法律规定和多样化的合规性要求，用某些机制将数据固定在一个特定物理位置变得非常重要，Aurora并没有提供这种能力。
Amazon Aurora vs Global Consistency
它通过存储层解决数据一致性，也就是6副本中4副本落盘的仲裁机制（quorum）。写入节点上可以设置隔离级别，而标准的MySQL和PG执行引擎是写入节点的一部分。
默认情况下，它提供RC（PG）或RR（MySQL）隔离级别，这可能带来写偏序和脏读问题。进一步说，复制到第二节点 “延迟通常小于1秒”，所以即使在可串行化隔离级别依然存在脏读的风险。
如上所述，AWS已经添加了多主能力，但如果选择这种部署方式，你会丧失Aurora的其他好处，不仅不提供可串行化隔离级别，还会增加性能障碍。
Finally, Cost x Performance
除了扩展性、性能、一致性，全球化数据库的成本也是重要的。为了获得成本数字，我们执行了一些benchmark比对不同类型Aurora实例。
Benchmark是一个棘手的话题，但CockroachLabs是非常认真的。我们竭尽全力保证我们的方法是合理的，并且符合公共标准。我们参考了一些Benchmark，TPC-C是其中之一。
当然没有完美的Benchmark，我们希望至少方向正确。我们对这些问题的讨论持开放态度，强烈建议你制定自己的benchmark。
Aurora能够以很低配置来处理OLTP工作负载。我们在小规模的机器上运行了一个类似TPC-C的工作负载，能够达到TPC-C大吞吐量的85%。
CockroachDB不仅能够提供低价格为OLTP工作负载，还提供了高等级的一致性。通过之前的文章，可以更好的理解这些数字。简单来说，CockroachDB的成本包括三台机器和一个DBA的工资，后者负责监控维护集群。
为了这个比对，我们首先简单调整了TPC-C suite，以便使用与MySQL、PG都兼容的API，但没有修改他们默认的隔离级别。
有趣的是，我们设想的经济方案是运行在小规模机器上的Aurora PG兼容数据库。然而，我们发现账单主要来自I/O开销。我们相信Aurora PG的接口实现并没有像MySQL那样得到同等优化。事实上，Aurora PG运行TPC-C的成本有90%与I/O相关。
所以，在默认隔离级别下，虽然AuroraMySQL需要更大规模的机器，成本却比PG低很多。前面的案例放松了对Aurora隔离级别的要求。所以，我们又在可串行化级别上运行了完整的TPC-C 1k，这也是CockroachDB默认的隔离级别。有人认为更高的隔离级别无疑会破坏性能。然而，对于Aurora来说，使用更多的处理器可以解决这个问题。但这样做的缺点是显著增加了I/O数量。看上去问题根源在Aurora MySQL的死锁机制，它不断地引发事务重启，导致返回磁盘的动作大幅增加。
归根到底，我们不是Aurora专家，所以上面的内容应该谨慎使用。然而，它确实显现出一些关键问题，我们想提供一个切实可行的比较，不仅是架构层面还包括成本。
Two Essential Constraints for a Global Database
真正的全球化数据库是全球化的可用性、性能、一致性，不应该纠结于6路复制。它应该提供可串行化的隔离级别，低延迟，零RPO。真正的全球化数据库要对抗的不是架构约束，而是两个事实。
任何东西都可能失效，需要有所准备。
光速是受限的。
如果你购买的是一个“全球化”数据库，它牺牲了性能、可用性或一致性不是因为这两点而有其他原因，那就要重新评估它是否真的像宣称的那样是“全球化”的。
CockroachDB从开始就被设定为全球化的数据库，我们对这两个挑战有深入的思考和敏锐的观察。每个节点都能作为整个数据库的网关，提供读写访问，同时保证任何规模下的性能可靠与可串行化隔离。
