Aurora Serverless v2 架构解析

作者:吴炳锡

        如果Aurora v1是数据库中革命性一个版本,但在Aurora Serverless V2这里也只能说是V1是一个实验性的版本,V2才算是真正的成熟。这里从AWS Invent大会获得的资料来解析一下Aurora Serverless V2。该架构感觉也是给数据库行业揭开了一个新的篇章。

        官宣: Amazon Aurora Serverless v2 目前为预览版,可以在不到一秒的时间内完成扩展,瞬间将处理能力从数百个事务扩展到数十万个事务。在扩展过程中,系统会以极为精细的增量调整容量,从而确保恰好提供应用程序所需的数据库资源量。您无需管理数据库容量,并且只需为您的应用程序使用的容量付费。与按照峰值负载来预置容量相比,您最高可以节省 90% 的数据库成本。

Aurora’s architecture

        Aurora Serverless v2从架构上看有三个组件:RDS proxy , Query Layer 和Storage layer三层。三层服务相对独立实现, 只有Query layer是基于第三方的开源代码实现。

 

RDS Proxy

         RDS Proxy也可以说为Router Layer。实现上非常轻量。Router Layer可以理解为是一个Proxy但具备连接池和流控的作用。支持MySQL,PostgresSQL协议。 

         Proxy只是简单的处理连接请求及把请求路由到正确的Query进程之外还有两个目的:

        1. 从原始的数据库中剥离出来,形成连接成的Serverless架构更易伸缩 。

        2. 会话保持后面的存储节点或是Query层重启,也可以保持客户端的连接不断开。

        路由层还可以跟踪数据库的连接分析数据库的使用及性能情况以便实现自动扩容,这种对于Serverless架构把接入层独立出来非常的重要。在一些版本中Aurora还支持通过HTTP Data API请求SQL,该设计就是基于router层来得的益处。

        对于写操作,也可以直接通过Primary 节点处理,对于Primary节点就处于一种非serverless架构下(如果不经过Proxy可能最大的问题就是没有写节点的高可用保障)

 

Query层

        可以称query layer为数据库层,这个是主要的事务处理及计算实现的组件。通过Router层和Query层相连,同时接触Router层传递的SQL并执行,读取写入存储层的的数据和索引。

        Query layer是直接借签使用开源的PostgreSQL和MySQL的代码,这部分代码基本没有变化,所以在使用Aurora时也要注意一下和那个版本的特性匹配(目前看MySQL是5.7的)在经典的software-as-a-Service的架构中一般是一个API支持多版本请求,但Aurora中只支持固定的版本对所有用户服务(避免多版本,让开发更轻松)。在自动扩展和自动故障转移方面更多的和自已托管的开源数据库方案一样。

        在Aurora集群中同时只有一个写实例,可以支持多个read-only实例(目前支持15个)。和使用MySQL的Master/Slave一样的。

        Query进程是跑在Vm中,所以选择合理的配置,可以让Query层获得更好的性能。这点更加体现了Serverless架构设计中,把计算层重的地方单独剥离出来,独立部署的好处了。

 

 

Storage层

         Aurora中Storage层使用云上高速S3块存储构建。存储层使用Log-Structured  engine原生分布式设计。 同个Region中6副本,至少保证写4份才算成功。

在Aurora中Storage层控制数据在Region中及多Region中复制,该复制通过存储层实现的。这复制不同于传统的OS RDS通过RDMS自身的Query处理。

         在Aurora中为了保证数据的强一致性,不管在哪个Region中的读写事务(或是强一致性的读),写事务必须由路由到主进程处理。读操作可以走其它Reader进程,读取的数据最终都是一致的(从技术来讲Aurora也可以做到Multi-primary的对外服务模型,但有可能破坏数据的一致性)

         由于这个限制,在Aurora中读写事务会随着Client和主进程之间的物理离增大而变的响应时间增长。针对这个问题Aurora在设计上引入了process-to-process的转发请求,尽可能的命中Local数据请求命中返回,但这个不能从根本上避免所有的强一致性的事务必须走主进程请求的性能问题。另外强一致的事务并发请求在主进程请求中也没有隔离。

         为了高可用,每个Aurora Region为每个数据库保持6个副本,每个AZ中保存2个副本。从而来减少故障对于应用的最小影响:

  • 在不同的AZ中总共丢掉两个副本,用户是感知不到的。

  • 在同一个AZ中丢失两个副本,则该AZ的请求用户会感知延迟增大,因为在这个AZ的请求自动转迁移到其它AZ中,但这个数据库依然可以提供写操作。

  • 如果丢失三个副本将会让数据库进入只读模式,能写入,但数据不会丢失。

  • 如果丢失4个副本整个集群可能不可用,且有可能造成数据丢失

 

--------------------------------

      可能解析有误,直接把油管地址放出来自取:https://www.youtube.com/watch?v=PQHZrtIgdiA 。欢迎交流。 

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章