AWS RDS发布三节点形态,哪些业务场景应该选择?

去年11月,Amazon RDS推出的新的形态:Multi-AZ Cluster(三可用区三节点)。相比“原来的多AZ”(两个可用区)架构,新的Cluster模式是三节点架构,提供了更低的事务延迟,同时有更好的读扩展能力。国内的云厂商中,阿里云和腾讯云很早就有了三节点形态,一起看看,他们有哪些异同,在实际的业务场景中,哪些情况可以选择这种形态。

AWS RDS三节点(Multi-AZ Cluster)是什么?

这里将其主要特点概括如下:

  • 这是一种3*AZ部署模式,而原来的Multi-AZ是2AZ部署或者单AZ部署。
  • 使用了数据库的逻辑复制,而原来的双AZ使用的是EBS层的复制,这就使得Cluster的副本节点都可以直接提供读能力,有更好的读扩展能力。
  • 使用了类似MySQL半同步的复制技术,事务日志网络到达其中任意一个副本主节点事务就可以提交,所以主节点上的事务延迟会降低,性能会提升(对比基于EBS的两节点)。
  • 支持Graviton 2的规格和NVMe-based SSD存储,可以提供更好的性能。
  • 同时支持MySQL和PostgreSQL两个引擎。

与阿里云、腾讯云数据库三节点的区别

阿里云RDS提供的“三节点企业版”,支持MySQL引擎,通过Paxos协议(或其变种)同步。相比Amazon的方案,其中一个节点使用了日志存储,成本可以更低;三个节点,只有一个节点提供服务。腾讯云MySQL也支持三节点版本,使用了半同步复制,可以选择异步、半同步或者强同步三种模式,也只有一个节点可以提供服务。

相比AWS,阿里云与腾讯云的三节点模式都可以由用户自由选择可用区分布,即可以都在一个可用区,也可以分布在两个或三个可用区,给了客户更强的灵活性。

AWS RDS三节点与两节点的架构差异

官方给出了较为详细的产品架构图,如下:

可以看到,原来的RDS多AZ(两节点)部署,使用了EBS底层同步复制,需要EBS复制完成后,主节点的事务才能提交,也因为是依赖底层复制,所以Failover的时间也会更长一些。当然,这种架构的优势在于简单,任何的数据库都可以使用,所以支持的数据库种类比较丰富。新的“三节点”形态则需要在内核层做一些改造,通用性要更差一些。这也是为什么这种架构目前支持的数据库种类还比较少,因为每一种数据库的支持在日志/复制/事务层都需要一定的改造,而且对于商业闭源数据库可能无法支持。

再补上两个更细致的架构对比图:

为什么AWS的三节点事务延迟更低,读扩展能力更强?

阿里云很早就支持了三节点企业版,相比两节点高可用版本来说,数据安全性更高,其代价是性能也有一定程度的下降、事务延迟也会略微增加。那为什么AWS三节点却声称提供了更低的事务延迟,更强的读扩展能力呢?

阿里云、腾讯云也都有自己的三节点形态。通常在底层使用Paxos(或者变种)的同步日志同步协议进行同步,以阿里云为例,使用了Paxos协议做日志同步,并且其中一个节点为日志节点,所以除了主节点,其他节点也就无法提供服务了(参考:MySQL · 产品特性 · RDS三节点企业版的高可用体系)。阿里云的两节点高可用版本(默认情况下选择的高性能参数模板)选择的async模式的,也就是主备并不是强同步的,而阿里云的三节点企业版则是同步的,所以自然三节点的性能会差一些。

但,AWS的两节点(普通的多可用区模式)默认就是主备强同步的,使用的是EBS层面的物理数据块的强同步复制(参考:Amazon RDS的同步复制是如何实现的 – Life, Database and Cloud Computing)。相比,相比阿里云使用的异步复制,AWS RDS两节点性能”应该”会更差的,当然,其安全性也会更高。AWS RDS的三节点则使用了逻辑复制,并且提供了两个备节点,其中任何一个成功则主库的事务就可以提交了。相比,两节点,数据多了一个“通路”,所以事务延迟可能更低。另外,AWS RDS的两节点使用了EBS层的物理复制,所以导致备节点无法直接提供服务,所以读扩展性也就没有三节点好了。

常见的业务场景

从上面的价格列表和产品功能说明可以看到,三节点相比两节点,提供了更高的灾难容忍级别,都可以接收单个可用区故障,依旧不丢失任何数据,但是价格也贵了约70%。所以,对于数据可靠性和一致性要求更高的场景,例如金融业务或其他有更强合规要求的业务,可以考虑使用该形态。

另外,相比阿里云和腾讯云,AWS RDS的三节点则有更广泛的适用场景。除了上述金融类场景外,普通的、读压力非常大(且介绍一定的延迟)的业务场景也可以使用,理论上,AWS RDS三节点价格虽然贵了70%,但是读的能力应该是原来的3倍左右。所以,如果是读密集型的场景,该形态的性价比还是比较高的。如果,业务恰好数据一致性要求非常高,合规上要求三可用区,又有比较大的读扩展性要求,那么就是这个形态的完美场景了。

创建与使用AWS RDS三节点

在创建RDS的时候,只需要选择Multi-AZ DB Cluster选项就可以了。实例完成创建后,可以看到集群有三个节点,分别在三个可用区。

在完成实例创建之后,该集群提供了三个Endpoint给用户使用。Multi-AZ Cluster提供两类Endpoint:

  • 集群写入的Endpoint、集群只读的Endpoint
  • 单个写实例的Endpoint、单个只读实例的Endpoint(两个)

其中,集群级别的Endpoint是稳定的,在集群发生切换时,这两个Endpoint形态不会改变。而单实例级别的Endpoint则会随着切换后,角色发生变化(如从可写到只读),这些Endpoint应该尽量用作诊断,而不是实际业务。

另外,集群只读Endpoint会将流量发送到两个读节点中的一个(The reader endpoint connects to either of the two reader DB instances, which support only read operations),所以,读取的数据可能会出现延迟。

有了两节点,又做三节点,是在卷吗?

在两节点情况下,如果一个节点发生灾难需要重建,通常当数据量较大的时候,这个重建时间会比较长,这时候主节点通常都是以单节点的方式提供服务,如果重建时间超过十小时,那么仅单节点提供服务的风险还是比较高的。

从架构演进来看,国内云厂商做三节点和AWS RDS做三节点的逻辑是不一样的。国内厂商是因为,两节点数据可靠性有一些瑕疵(换来的是高性能),在此基础上推出三节点解决这个瑕疵(付出的代价也是性能)。

而AWS RDS的两节点的数据可靠性已经非常高了(付出了性能的代价),而三节点是通过逻辑复制、并且新增一个复制节点的方式(两个节点中任意一个复制成功则成功)提升了可靠性的同时,是提升了性能的。所以,AWS RDS的三节点,相比自己的两节点,性能更好了,读扩展能力更好了,适用的场景也更加广泛。

一些补充说明

  • 阿里云RDS的两节点形态,提供了三种参数选择:
    • 一种是异步,高性能:sync_binlog=1000, innodb_flush_log_at_trx_commit=2, async
    • 一种是同步(使用了半同步技术)
    • 另一种是异步,但是设置了”双1″,单个节点安全性更高

在本文档的描述中,为了简化,提到阿里云两节点形态时,通常是指默认的第一种形态,也就是异步高性能模式。

  • 腾讯云的按量付费会在使用第4天和15天之后,计费价格会大幅度下调,所以上面按量付费价格并不能直接比较。
  • 华为云RDS暂时不支持三节点形态。
  • 在Amazon RDS站点中,Multi-AZ Cluster形态有时也被称为“Readable standby instances”。
  • 为了控制主节点和备节点的延迟,可以通过参数rpl_semi_sync_master_target_apply_lag控制,当延迟达到该参数设置的值的时候,RDS会通过流控的方式限制主节点的写入。
  • 虽然,文档中并没有明确指出,但是猜测Multi-AZ Cluster应该是基础MySQL的半同步做的实现,相比其他一致性协议,这种实现,在读取数据的如果从standby读取,那么就会有不一致。所以,需要一致性读,则需要总是从写节点读取数据。

参考

2 responses to “AWS RDS发布三节点形态,哪些业务场景应该选择?”

  1. sherrichen

    有个地方没有看明白,想请教一下
    “使用了数据库的逻辑复制,而原来的双AZ使用的是EBS层的复制,这就使得Cluster的副本节点都可以直接提供读能力,有更好的读扩展能力。”
    这个地方原来的双AZ使用EBS物理复制的,为什么不能提供读的能力呢? 而且理论上性能会比cluster模式的复制性能更好

  2. “EBS物理层复制”是发生在存储层,与数据库没有直接关系。一般来说,在存储复制过程中,数据库是无法正常启动的,所以也就没办法提供任何数据库业务。

Leave a Reply

Your email address will not be published. Required fields are marked *