关于数据库:如何选择合适的云数据库架构与规格

NineData 联结创始人周振兴（苏普）受邀加入 2023 年 ACMUG 第一站西安站，发表了《云数据库架构与选型》主题演讲。

ACMUG，全称为中国 MySQL 用户组 (All China MySQL User Group)，是 MySQL 和 MariaDB 在中国最大的技术社区，是失去了 Oracle User Group Community、MairaDB Foundation、中国计算机行业协会开源数据库业余委员会等官网认可的社区组织，ACMUG 会邀请国内外顶尖互联网公司和大型企业技术专家，分享其在数据库、大数据、云原生、AIOps 等技术方向上的教训以及最新进展。

以下内容，依据周振兴在【2023 年 ACMUG 第一站西安站】线下演讲内容整顿而成。

AWS 在 2009 年公布第一款云数据库产品 RDS MySQL，阿里云于 2011 年 也公布了本人的 RDS MySQL，到当初，云数据库技术曾经通过了 14 年的倒退。云数据库的架构曾经变得非常复杂，上周则借着 ACMUG（中国 MySQL 用户组）的分享则总结了 AWS 和阿里云 RDS 的次要架构特点，并通过一张架构图汇总，帮忙开发者依据须要在适合的场景抉择适合的架构与规格。

一、AWS：抉择适合的 RDS 架构与规格

1.1 架构与规格大图

该架构图蕴含了高可用架构、CPU 架构抉择、存储类型抉择等内容。该架构图不包含性能、准确的对应关系（如 SQL Server 反对的存储空间大小与 MySQL 有什么差异）等内容，临时不包含 Aurora 架构（后续思考补充）、Custom、Outpost 类型等。

1.2 高可用架构

AWS RDS 的高可用架构包含了单可用区（Single-AZ / Single DB instance）、多可用区（Multi-AZ DB instance）这两种常见类型，RDS MySQL/PostgreSQL 还提供了多可用区集群版（Multi-AZ DB Cluster）。

1.2.1 单 / 多可用区

该选项清晰的形容了实例的在可用区级别的容灾能力：

• 单可用区版本的数据库仅一个实例，没有高可用节点，如果节点失败，则会重启主机或者应用新的节点，整个过程会比拟长。
• 多可用区版本，则默认会应用两个节点，且肯定散布在两个不同的可用区，实例能够实现跨可用区的容灾。当一个可用区呈现故障的时候，实例会产生切换，容灾到另一个可用区。AWS 的多可用区版本，主备之间应用的是存储层（EBS）的物理复制，所以因而其性能也会受到肯定的限度。

1.2.2 多可用区集群版

这是 Amazon RDS 在去年公布新的架构状态，具体参考：AWS RDS 公布三节点状态，哪些业务场景应该抉择？。该状态次要解决原来的“多可用区版本”备节点齐全不可用（绝对老本较高）的问题。

“多可用区集群版”应用了数据库的相似的半同步复制机制（参考零碎参数判断进去的），数据库的事务写入须要至多两个（多数派）写入胜利才胜利，但因为有两个备节点，所以相比“多可用区版本”性能会更好，另外，因为是数据库层的复制，而不是块级别，写入和同步门路会更短，也会让提早更低一些。

该版本，仿佛是以后 Amaozn RDS 主推的版本（从 RDS 创立流程中的默认选项和选项程序来看）。

以后，多可用区集群版是规范模板中的第一个、也是默认选项。

对于该版本的架构、优缺点等相干信息能够参考该文章取得更多具体内容：AWS RDS 公布三节点状态，哪些业务场景应该抉择？

1.3 CPU 架构

支流的云厂商都逐渐开始提供 X86 和 ARM 架构的 CPU，AWS 在这方面是在这方面动作最早的。在 2018 年 re:Invent 上推出了第一代的 Graviton，2019 年推出了 Graviton 2，2021 年推出了 Graviton 3。能够认为，以后产品曾经有肯定的成熟度，依据 Percona 做的 MySQL 测试，咱们也看到，Graviton 在不同的并发类型，都体现出了与 Intel X86 差不多的性能，并且在高并发（并发数超过 CPU 外围数量）时，Graviton 体现还要更好一些。

性能比拟靠近，老本又更低，所以，目前曾经有不少客户在尝试通过 Graviton 实例降低成本。目前，AWS RDS 也有十分多的 Graviton 的规格供选择。

以后的倡议是：能够思考在局部业务中尝试应用 Graviton 降低成本，依据企业外部的负载状况，再逐渐思考扩大范围应用。

另外，值得一提的是，AWS RDS 提供的最大规格是 db.x2iedn.32xlarge，具备 128vCPU 4096GB，一般来说，企业外部绝绝大多数业务都是满足需要的。

1.4 存储层

接着来看看 AWS RDS 提供了哪些存储类型。

AWS RDS 以后支流的存储类型包含了 gp2、gp3、io1（预留 IOPS 的 SSD），以及一个曾经过期的 HDD 存储。其中：

• gp2 存储定位是实用于开发测试环境，存储大小最大为 64TB，最大 IOPS 为 64000。在购买时，只能选定存储空间，其 IOPS 会依据存储空间进行换算，个别的会是存储空间的三倍，然而有一个上限、也有 64000 的下限。
• gp3 定位是生产环境的 OLTP 利用，gp3 的最大存储空间和 gp2 雷同，然而，gp3 存储能够独自购买 IOPS，即存储空间和 IOPS 是能够离开购买的，这就给用户提供了更大的灵便度。然而，须要留神的是 IOPS 购买的下限 / 上限也与存储有肯定的关系。防止了，购买十分小的存储空间，然而购买十分大的 IOPS 的状况。具体的限度能够参考其文档介绍。所以，gp3 类型的实例，其计费也是依照存储空间和 IOPS 离开计费的。
• gp2、gp3 存储所提供的 SLA 都是 99% 的申请在毫秒级别。
• io1（预留 IOPS 的 SSD）则提供了更高性能的存储，最大存储空间仍旧是 64TB，然而其 IOPS 则能够高达 25.6 万。另外，io1 存储提供的 SLA 也更高，为 99.9% 的申请在毫秒级别。计费也是依照存储空间和 IOPS 离开计费。
• HDD 存储是过期的存储类型，次要为了放弃兼容性而存在，其最大存储空间为 3TB、最大 IOPS 为 1000。

在理论的抉择中，开发测试环境则能够应用 gp2 类型、个别业务应用 gp3 类型，对于外围业务则能够应用 io1 类型。

1.5 规格代码

对于规格代码，国内的云厂商个别不是太强调，也不是太关注。然而 AWS 因为其规格代码十分标准，也十分简洁，所传播的含意也比拟精确，所以很多时候，在提及规格时，大家会应用其规格代码，而不是应用 vcpu 数量和内存大小。

例如，db.m6gd.16xlarge，则能够晓得这是一个数据库实例，64vCPU，256GB 内存，并且为 Graviton 架构的第六代（Graviton 2）实例，并且在本地具备额定的 NVMe SSD。

• 规格代码中的“db”代表了这是一个用于数据库的实例（ec2）；
• {t|m|r|x} 别离代表了突发型实例 t（小规格）、规范实例 m（内存 cpu 比为 4）、内存优化型 r（内存 cpu 比为 8）、内存优化型 x（内存 cpu 比为 16）；
• 跟在其后的，则是 CPU 的迭代；
• 数字之后的可能呈现的字母包含：g、d、n、i 等。g 代表这是一个 Graviton 类型的实例、d 代表该实例本地有额定的、加强的存储资源、n 则代表了额定的网络能力、i 代表这是一个 Intel X86 架构的实例。

1.6 其余

1.6.1 对于“可用区”

可用区能够了解为一片机房区域。例如，在东京东部的某个机房区域，通常会无数栋机房。一个大区域（Region，例如东京）会有多个可用区。

1.6.2 补充阐明

• 本文内容次要聚焦于应用最多的各个云厂商的 RDS 数据库的架构与选型，并不包含残缺的产品系列；
• 该架构图旨在帮忙大家从整体框架上理解云数据库整体概括，并不是准确的架构图，并不求准确、八面玲珑，例如 RDS MySQL、RDS SQL Server 在很多细节上是不同的，这里并没有体现，这些详情能够参考各个云厂商的相干文档；
• 这里不包含价格、性能相干的内容。

二、阿里云：抉择适合的 RDS 架构与规格

2.1 架构与规格大图

一张图读懂阿里云数据库 RDS 架构与选型

在 v1 版本公布的时候，具体的介绍了阿里云数据库 RDS 次要架构类型、资源复用与规格、数据库专属集群、本地盘与云盘版、通用型与独享型、超配比等内容，这里不再赘述，如果感兴趣能够参考：一张图读懂阿里云数据库架构与选型。

2.2 次要的架构类型

数据库通常是企业业务架构中的外围组件，数据库的可用性与业务可用性间接相干。所以，高可用是云数据库架构选型第一个须要关注的内容。

从高可用角度，阿里云数据库提供了根底版（即单节点）、双节点高可用版、三节点企业版。不同的版本，则是在老本、可用性、数据可靠性之间的均衡：

• 单节点通过简略的架构，以最低的老本提供了根本可用的云数据库服务；
• 双节点高可用版则是适宜绝大多数业务场景的模式，两个节点散布于一个地区的两个可用区，故障时，切换速度较快，数据双正本，可靠性也比拟高；
• 三节点企业版，则通过 X-Paxos 实现底层数据统一，并以三正本（两份数据 + 一份日志）保障数据可靠性。

2.2.1 根底版（即单节点版本）

阿里云根底版应用阿里云云盘作为数据库存储，挂载在数据库的计算节点上，实现了存储与计算的拆散。这使得，计算节点呈现故障的时候，从新应用一个新的计算节点，再从新挂载原来的数据库存储，即可启动数据库，复原呈现故障的数据库。所以，在计算节点产生故障的时候，RPO 通常小于 1 分钟，RTO 则为 5 分钟~ 一小时。当整个可用区产生故障的时候，RPO 和 RTO 的值则依赖数据库备份的频率状况。

2.2.2 高可用版

两节点高可用是用户应用最多的版本，也是数据库最为常见的架构。数据库由主备两个节点组成，通过数据库层的逻辑日志进行复制。相比单节点，无论是在数据可靠性、服务的可用性都有十分大的晋升。因为主备节点都在同一个大 region，日志提早通常都十分小，所以产生单节点故障时，高可用版的数据可靠性通常是比拟高的。留神到，AWS 对应的双节点版本的 RPO 是零，那么阿里云数据库怎么呢？

具体的，对阿里云 RDS MySQL，阿里云的两节点高可用，依据所抉择的参数模板分为如下三类：

• 高性能：sync_binlog=1000, innodb_flush_log_at_trx_commit=2, async；
• 异步模式：sync_binlog=1, innodb_flush_log_at_trx_commit=1, async；
• 默认：sync_binlog=1, innodb_flush_log_at_trx_commit=1, semi-sync。

其中，“高性能”版本和“异步”版本，都是异步复制，在产生主节点故障时，因为复制为异步的，可能会有少部分的事务日志没有传到备节点，则可能会失落少部分事务。也就是说，这两个版本为了实现更好的性能，在数据库的 RPO 上做了小的退让。“默认”版本，应用了半同步复制，通常，数据可靠性会更高。但因为半同步可能会有进化的场景，所以，该模式下数据复制还是在极其的状况下，还会有数据失落的可能性。

那么，既然“异步”模式和“高性能”都有数据失落的危险，他们的区别是什么什么呢？简略的概括，“异步”产生渺小数据失落的可能性更小。因为，主备节点通过设置 sync_binlog=1,
innodb_flush_log_at_trx_commit=1，能够最大可能性的保障，主节点的数据可靠性。

事实上，高可用版本是能够满足绝大多数业务场景的须要的，一方面同一个可用区内数据传输提早十分小，日志传输通常都十分通顺，即使主节点产生故障，理论的状况中，通常不会呈现日志提早。另外，主节点失败后，通常能够通过重启等形式复原，云厂商的硬件都有着较为规范的硬件过保淘汰的机制，硬件齐全不可用的状况也并不多。另外，底层磁盘会通过硬 RAID 或者软 RAID 的形式，保障磁盘数据存储的可靠性，数据即使是在一台机器上，也会保留在两块盘上。

两节点高可用版本在某些非凡场景下，数据还是存在一些不可用危险，例如，当其中一个节点产生故障，而本地数据量又十分大时，须要从新在一台新的机器上搭建备节点时，因为数据量较大，重建工夫通常会比拟长，而这时候，主节点则会始终单节点运行，如果可怜主节点再呈现故障，则会呈现不可用或者数据失落。如果，对数据的安全性有更高的要求，则能够思考抉择“三节点企业版”。

2.2.3 三节点企业版

以后仅 RDS MySQL 有该版本。三节点企业版应用了基于 X-Paxos¹ 的一致性协定实现了数据的同步复制，实用于数据安全可靠性要求十分高的场景，例如金融交易数据等。三节点中，有一个节点仅存储日志，以此实现靠近于两个节点的老本与价格，实现更高的数据安全与可靠性。

三节点企业版在创立的时候，能够抉择散布在 1~3 个可用区。如果须要跨可用区的容灾，则能够让三个正本散布于三个可用区，如果须要更高的性能，则能够让三个正本都在同一个可用区。

2.2.4 对于 MySQL 的参数 sync_binlog, innodb_flush_log_at_trx_commit

在阿里云 RDS 的高可用参数模板抉择中，不同的参数模板，最次要的区别就是这两个参数的不同配置。这是 MySQL 和 InnoDB 在数据安全性上最重要的两个参数。双 1 设置（sync_binlog=1,
innodb_flush_log_at_trx_commit=1）是数据安全性最高的配置。

数据库是日志后行（WAL）的零碎，通过事务日志的长久化存储来保障数据的长久化。在个别的 Linux 零碎中，数据写入磁盘的长久化须要通过零碎调用 fsync 来实现，绝对于内存操作，fsync 须要将数据写入磁盘，这是一个十分“耗时”的操作。而下面这两个参数就是管制 MySQL 的二进制日志和 InnoDB 的日志何时调用 fsync 实现数据的长久化。所以，这两个参数的配置很大水平上反映了 MySQL 在性能与安全性方面的均衡。

其中，sync_binlog 代表了，MySQL 层的日志（即二进制日志）的刷写磁盘的频率，如果设置成 1，则代表每个二进制日志写入文件后，都会进行强制刷盘。如果设置成 0，则代表 MySQL 本人不会强制要求操作系统将缓存刷入磁盘，而由操作系统本人来管制这个行为。如果设置成其余的数字 N，则代表实现 N 个二进制日志写入后，则进行一次刷写数据的零碎调用。

innodb_flush_log_at_trx_commit 则管制了 InnoDB 的日志刷写磁盘的频率。取值能够是 0,1,2。

• 其中 1 最严格，代表每个事务实现后都会刷写到磁盘中。
• 如果该参数设置成 0，那么在事务实现后，InnoDB 并不会立即调用文件系统写入操作也不会调用磁盘刷写操作，而是每隔 1 秒才调用一次文件系统写入操作和磁盘刷写操作。那么，在操作系统解体的状况下，可能会失落 1 秒的事务。
• 如果该参数设置成 2，那么，每次 InnoDB 事务实现的时候，都会通过零碎调用 write 将数据写入文件（这时候可能只是写入到了文件系统的缓存，而不是磁盘），然而每隔 1 秒才会进行一次刷写到磁盘的操作。那么，在操作系统解体的状况下，可能会失落 1 秒的事务。相比设置成 0，该设置会让 InnoDB 更加频繁地调用文件系统写入操作，数据的安全性要比设置成 0 高一些。

咱们能够通过下图来了解这两个参数的含意，以及在操作系统中对应的“写入文件系统”与“刷写数据到磁盘”的含意。首先，在数据库的事务处理过程中，会产生 binlog 日志和 InnoDB 的 redo 日志，这两个日志别离在 MySQL Server 层面和 InnoDB 引擎层面保障了事务的持久性。在事务提交的时候，数据库会先将数据“写入文件系统”，通常文件系统会先将数据写入文件缓存中，该缓存是在内存中，这样就意味着，如果产生操作系统级别的宕机，那么写入的日志就会失落。为了防止这种数据失落，数据库接着会通过零碎调用，“刷写数据到磁盘”中。此时，即能够认为数据曾经长久化到磁盘中。

这时，再回头看看阿里云 RDS 的参数模板。在高性能模板中，”sync_binlog=1000,
innodb_flush_log_at_trx_commit=2, async”，代表了在写入 1000 个 binlog 日志后再进行刷写数据到磁盘的操作，InnoDB 的日志则都会先写入文件系统，而后每隔一秒进行一次刷写数据到磁盘。在“默认模式下，“默认：sync_binlog=1, innodb_flush_log_at_trx_commit=1, semi-sync”，则是最严格的日志模式，也就是会保障每个事务日志平安的刷写到磁盘。

日志的刷写模式对性能有十分大的影响。如果不去关注这些参数，就间接去测试不同云厂商的性能，则会发现，云厂商之间的 RDS 有着十分大的性能差别。通常，这些差别并不是厂商之前的技术能力导致的，更多的是因为他们在对于安全性和性能的均衡时，抉择的不同的平衡点。

2.3 资源复用与规格

从资源共享与隔离上，RDS 又分为：通用型、独享型和共享型。具体的：

• “通用型”适宜个别的业务应用场景，但有肯定的 CPU 共享率，也就说是，有肯定的概率实例的资源可能会被其余实例争抢而导致性能的稳定。
• “独享型”则应用齐全独享的 CPU 的资源和内存资源，不会共享其他人的资源，本人的资源也不会被其他人共享，所以，有更稳固的性能。
• “共享型”则与通用型相似 CPU 资源会被共享，并且共享率更高，所以性价比更高，同时受到资源争抢的影响的可能性也更大，以后仅 SQL Server 反对。

除了，上述次要规格类型之外，阿里云还提供了“独占物理机”规格，抉择该规格的用户能够齐全的独占一台物理机的资源：

2.4 数据库专属集群 MyBase

专属集群 MyBase 是阿里云推出的一种非凡的状态。能够了解为，是一种全托管 RDS 与自建数据库的两头状态。在全托管的 RDS 根底上，提供了两个重大的能力：

• 容许用户登录数据库所在的主机；
• 容许用户配置数据库实例 CPU 的“超配比”。

当然，要求是用户一次购买一个十分大的、能够包容多个 RDS 实例的“大集群”，专属集群则提供了以上两个能力，以及 RDS 其余的根本能力，包含装置配置、监控治理、备份复原等一系列生命周期治理能力。

应用这种规格，用户具备更大的自由度。一方面能够登录主机，观测主机与数据库的状态，或者将本人原有的监控体系部署到专属集群中。另一方面，用户能够依据本人的业务特点，管制集群内的 CPU 资源的超配比。对于外围的利用，则应用资源齐全不超配的集群；对于响应工夫没有那么敏感的利用，例如开发测试环境，则能够配置高达 300% 的 CPU 超配比，以此大大降低数据库的老本。

2.5 对于本地盘与云盘版

阿里云的次要版本都会反对本地 SSD 和高性能云盘。他们的差别在于计算节点与磁盘存储是否在同一台物理机器上，对于应用高性能云盘的规格，通常是通过挂载一个同地区的网络块设施作为存储。

对于阿里云厂商来说，将来主推的将是云盘版。起因是云盘绝对于本地盘来说，有很多的劣势：

• 对立应用云盘版，让云厂商的供应链治理变得简略。如果应用本地盘版本，意味着数据库机型定制性会加强，供应链的艰难会减少产品的老本，最终影响价格。另外，简略的供应链也会让产品的部署更加标准化，更加敏捷地实现多环境多区域的部署。
• 应用云盘版，也能够了解为是“存储计算拆散”的架构，那么如果计算节点故障，则能够疾速通过应用一台新的计算节点并挂载云盘，而实现高可用。这种形式有着十分好的通用性，无论是哪种数据库都能够应用，而无需思考数据库品种之间的差别。无论是 MySQL 还是 PostgreSQL、Oracle 都能够应用这种形式实现高可用。
• 云盘版本身提供了肯定的高可用与高牢靠能力。云盘自身数据能够通过 RAID 或者 EC 算法实现数据的冗余与高可用，并且能够将数据分片到不同的磁盘与机器上，整体的吞吐会更高。
• 云盘版本身是分布式的，能够提供更高的吞吐，通常还能够提供更大的存储空间。例如，各个云厂商的云盘存储都能够提供 12 TB 或 32 TB 的存储空间，基本上能够满足各类业务须要。

当然，应用云盘也有一些毛病，例如，相比本地盘，云盘的拜访提早更大，须要通过网络拜访，而对于数据库这类 IO 极其敏感的利用，本地磁盘的 IO 性能的稳定性通常会更强一些。

2.6 对于通用型与独享型的性能

独享型规格的资源齐全由用户独立应用，价格通常更贵。而通用型则因为局部资源的共享，会导致性能在某些不可预期的状况下产生一些不可预期的稳定。而独享型规格也更贵，更多的企业级场景，也会举荐应用独享型，会有很多人会认为独享型的性能也更高。而实际上，如果做过理论测试就会发现，一般来说，雷同的规格，通用型的性能与吞吐通常都会更高。

所以，理论状况是，通用型的价格更加便宜，性能也会更好。毛病在于，可能会呈现一些不可预期的性能稳定，而因为大多数数据库利用都是 IO 密集型的，所以，理论场景中，这种不可预期的稳定并不是十分多。

所以，这两个版本的抉择，须要用户依据本人的理论状况去抉择。如果，能够承受偶然的性能稳定，则肯定是倡议抉择通用型的；如果利用对数据库的响应工夫极其敏感，则应该抉择独享型。另外，以后，通用型最大规格仅反对 12 核 CPU，所以对于压力十分大零碎，则只能抉择独享型。

2.7 对于超配比

对于在线数据库利用来说，通常是 IO 或者吞吐密集型的。CPU 资源在很多时候，会有肯定的冗余。对于云厂商来说，则能够通过超配 CPU 的售卖率来降低成本，同时也升高数据库资源的价格，这就是通用型背地重要的逻辑。

而一般来说，能够超配的通常只有 CPU 资源。磁盘资源尽管能够超配，然而理论应用中，是不能重合的，当用户的磁盘占用增到购买值的时候，资源则不能够共享，这与 CPU 的超配并不相同。内存资源则更加是独享的，Buffer Pool 的通常是满的，无论这些内存页是否被理论应用，数据库总是会尽力在内存中存储尽可能多的数据。

MyBase 提供的一个重要配置项，就是能够由用户自定义底层资源的超配比，该比率取值从 100%~300%。也就是说，一个 32 核 CPU 的资源，最多能够调配给 12 个 8 核 CPU 的实例应用，看起来是 96=12* 8 个 CPU 被应用，即实现了 300% 的超配比。

超配比，有时候也会被称为超卖率。

2.8 ARM 架构实例反对

阿里云数据库在去年 11 月发表推出基于 ARM 架构的 RDS 实例，能够向用户提供更高性价比。依据 ARM 芯片的定位，个别性价比更高，然而性能下限相比于 x86 的芯片要差一些。所以，如果数据库实例压力不是很大，而又思考老本升高，则能够思考尝试 ARM 架构的 RDS。

另外，zhoujy 在去年 11 月份对该实例进行测试，相干的数据库能够参考：MySQL 该用哪种 CPU 架构服务器。

以后，基于 ARM 的 RDS 实例上线工夫还不是很长，如果是生产环境的话，倡议做较为全面的测试后再上线。

2.9 RDS MySQL 集群版

在 2022 年底，阿里云 RDS MySQL 公布了集群版。该产品状态相似于 AWS 提供的“Multi-AZ Cluster”，场景也比拟相似。比照最罕用的双节点高可用版本，该”集群版”将其备库的连贯地址提供了进去，间接能够用于用户业务，帮忙用户升高应用老本。另外，也能够思考将主库的局部流量间接迁徙到备节点，升高主库压力，晋升主库的可用性。

如果，在业务场景中，应用了 1~2 个只读实例的，则能够思考间接应用该集群版本来代替原有的只读实例。老本能够失去十分大的升高。

2.10 Serverless 实例

RDS Serverless 是一种优于按量付费、包年包月的资源应用的模式。它提供了自动化的弹性扩缩容，用户无需提前选定规格，后端会依据零碎压力进行主动升降配，并依据理论应用计费，当然，用户能够设置 Serverless 实例的最大和最小规格，限度资源最大使用量和最低的服务能力。

对于峰谷显著的业务零碎，该模式一方面能够在须要时提供很高的资源规格应答压力，另一方面能够在低峰时升高资源使用量，最终降低成本。

也留神到，最近阿里云数据库也介绍了客户“微财”应用 Serverless 实例构建云上灾备的案例。应用 Serverless 构建云端低成本的灾备，的确是一个十分好的场景，一方面满足了客户底层本的诉求，另一方面客户本地的实例如果真的出问题，仍旧能够十分疾速的接管。

对于更多 Serverless 测试能够参考：实测阿里云 RDS Serverless。

2.11 其余

• 本架构图次要反映阿里云数据库 RDS 的次要架构；
• ARM CPU 仅局部数据库局部规格反对，以后仅 MySQL、PostgreSQL 反对；
• “集群版”仅 MySQL 和 SQL Server 反对；
• 不同数据库的不同的版本，反对的架构和规格都有不同，这里并没有体现进去；
• 不同的区域反对的数据库、版本均可能不同；
• 该图的实现失去了阿里云 RDS 团队的帮忙，在此一并表示感谢；
• v1 版本公布于 2022 年 5 月；v2 版本公布于 2023 年 2 月。

三、阿里云 RDS vs AWS RDS 选型差别

AWS 和阿里的数据库产品各自都倒退了很长时间，所处的市场环境、客户场景都有很大的不同，所以，其产品状态也有很多不同的中央，即使是看似雷同的名称其含意也可能不同。这里整顿，阿里云和 AWS RDS 产品的一些差别，以便帮忙大家更好的抉择产品：

3.1 根底版 vs 单可用区版本

无论是在阿里云还是 AWS，这两个版本都是代表了单节点的架构。然而：

• 阿里云的“根底版”，强调“根底”，所以均为小规格，最大只有 12v CPU，也没有高可用节点，所以也就只能在一些小场景，如测试环境，中应用。
• AWS 则强调是“单可用区”版本，并不一定是小规格，其最大规格也能够到 128v CPU，所以其应用场景要更宽泛。例如，局部剖析业务节点应用，该类型可能须要十分强的计算能力，然而能够承受肯定水平的可用性问题。

3.2 阿里云高可用版 vs AWS 多可用区版

这两个版本都是各自厂商的支流版本，是合乎大部分 OLTP 业务场景的。但两个厂商的实现各有一些不同，阿里云应用的是数据库层的逻辑复制，AWS 应用了 EBS 层的同步物理复制。阿里云 RDS MySQL 在数据保护上，则提供了“高性能”、“异步模式”、“默认”等参数模板，能够让用户在数据保护和性能之间进行肯定均衡和抉择，而 AWS RDS 则应用了 EBS 的同步物理复制，最大限度的爱护事务平安。

3.3 阿里云 ARM vs AWS Graviton

阿里云 RDS 的 ARM 规格上线工夫比拟短，如果要思考在生产环境应用，还是倡议做较为充沛的业务测试。相比，AWS Graviton 实例曾经上线有 3 年工夫，也有很多的应用案例，绝对要更加的稳固。另外，AWS Graviton 实例在性价比上的确更加显著，这一点，无论是第三方的测试还是官网颁布的一些数据，都失去了证实。所以，如果局部业务，思考降低成本，则能够尝试应用 AWS Graviton 实例。

3.4 ESSD vs gp2/gp3/io1

ESSD 的性能下限是更高的，目前 ESSD PL-X 类型曾经宣称提供了 300 万的 IOPS 能力。AWS RDS 所应用的 io1 最大 IOPS 则是 25.6 万。始终以来，AWS RDS 被诟病比拟多的是其依照 IOPS 计费的简单逻辑，尽管，看似产品细节十分粗疏，然而理论让用户抉择和应用的时候很困惑，另一面，阿里云和其余云厂商都以存储空间计费，更加简略，并提供与存储空间大小为肯定比率的 IOPS 能力。

AWS 存储的一个长处是，其提供了十分明确的 IOPS SLA，io1 规格，其 SLA 是 99.9% 的 IO 申请响应工夫是毫秒级，这反馈了 AWS 能够向用户提供十分稳固的 IOPS，而不是仅仅简略的最求 IOPS 下限。

3.5 资源共享 vs 突发型

AWS 在小规格的版本提供了突发性能型实例，能够提供肯定的 CPU“超用”（购买了 2v CPU，理论应用更多 v CPU）能力，同时，其“超用”和限度的规定都十分明确。

阿里云则为了更好的性价比，则向用户提供了“共享型”、“通用型”、“独享型”，让用户在性能稳定性就义十分十分小的状况下，取得更高性价比的实例规格。另外，阿里云提供的 MyBase 规格，更能够本人定义“超卖”比率，让用户依据本人的业务类型和特点进行自定义的配置。阿里云的“独享型”资源则全副由用户独立应用，也能够保障十分好的性能稳定性。

3.6 规格代码

AWS 的规格代码十分简洁、精确，含意清晰，并且有十分好的连续性。从规格代码中很容易理解到该规格的特点、大小等个性。

四、最初

阿里云和 AWS 两家的云厂商的数据库服务都通过了十来年的倒退，他们在各自的市场和场景下，都十分好的满足了他们客户的诉求，本文档旨在帮忙大家可能从整体框架加上理解两家厂商次要数据库产品 RDS 的架构。所以在介绍中省略了十分多的细节内容，也就义了肯定的精确性，这些内容能够参考各种厂商的文档，这里不做赘述。

周振兴（苏普），NineData.cloud 联结创始人，Oracle ACE（MySQL 方向），数据库畛域畅销书《高性能 MySQL》第三、四版的译者，曾任阿里云数据库资深专家。