这是我参与8月更文挑战的第17天，活动详情查看：8月更文挑战

📢欢迎点赞：👍 收藏 ⭐留言 📝 如有错误敬请指正，赐人玫瑰，手留余香！

📢本文作者：由webmote 原创，首发于【掘金】

📢作者格言：生活在于折腾，当你不折腾生活时，生活就开始折腾你，让我们一起加油！💪💪💪

🎏 序言

最近在调研AWS云上提供的Aurora for mysql，Aurora是一种与 MySQL 和 PostgreSQL 兼容的关系型数据库，专为云打造，既具有传统企业数据库的性能和可用性，又具有开源数据库的简单性和成本效益。

虽然AWS网站上也有不少介绍，但想弄懂它，还是要花费不少精力的，因此记录如下，有相关需要的可以节省部分时间。

🎏 1.基本特点

这款数据库，是基于AWS提供的自研引擎构建，其有下列特点：

广告做完了，如果有人想购买AWS服务，不要联系我，联系我也没有折扣。

看图好说话，一图胜万言。

Aurora架构与MySQL RDS的单主集群相比较有这些区别：

mysql的IO需要完成日志、binlog、data、帧文件、Double-Write等相关操作，其既需要写到本地存储，又需要同步到副本实例。
Aurora简化了IO操作，其仅仅写入LOG文件到存储卷即可，当然主副同步的时候也节省了大量数据，仅仅应用帧文件和日志即可。虽然没有直接写数据，但针对db实例来说，Data是不可或缺的，因此在Aurora的存储卷部分，会单独开启线程管理从Log解析为Data部分的工作。
Aurora的读写和MySql也是不同的，其采用了Quorum的6节点协议模式，在存储卷投票写完4个后，才算完成数据的写入，而读取的投票需要获取3个，也即需要读取3个存储节点，并且一致才行。其采用了分布式一致算法，确保数据能达到读写强一致性。
Aurora的读写主节点和只读副本节点均共享底层的存储卷，存储卷在3个不同的可用区内，保证了数据的多活特性。

5. Aurora的只读副本同步数据来自主节点或临近节点的数据同步拷贝，拷贝的数据直接应用到mysql的数据缓存区，保证了副本快速的更新数据，当然在必须的时机，也需要同步来自存储卷的数据，这取决于其内置的算法。

和大多数的主从副本一样，从副本在数据的同步上和主节点之间有一定的延迟。AWS的延迟保证是小于100ms，一般平稳保持在10ms左右。

因此如果使用读写分离的场景，高一致性要求的事务应该只走主节点。要求不高的可以走只读副本。

全部步骤都是异步，写性能的延迟主要在步骤1和步骤2。

在单主模式的DB集群下，DB存储是单独的虚拟存储卷，DB实例和DB只读副本构建这个之上，因此秒开实例是比较容易的，因为没有数据复制被需要。实例只有一个，在需要的时候可以被扩展。

这里仅仅介绍了单主模式。

在多主模式集群下，所有DB实例均可读写，目前最大支持4个。

多主模式不支持单个实例读写其他只读的策略。

某个DB实例不可用后，没有故障切换处理机制，因为其他db实例直接接管写操作。

为了区分这种可用性，AWS称它是持续可用，以区分单实例的高可用。

多主集群需要处理写冲突，为了减轻用户负担，也可以开启多主强一致开关，可以开启先写后读，这种模式牺牲了部分性能。

例行小结，理性看待！

结的是啥啊，结的是我想你点赞而不可得的寂寞。😳😳😳

👓都看到这了，还在乎点个赞吗？

👓都点赞了，还在乎一个收藏吗？

👓都收藏了，还在乎一个评论吗？