01阿里云RDS架构和规范大图下图从高可用类型、数据可靠性、资源重用率、规范大小、规范代码等角度，较为完整地概述了当前RDS的主要架构和规范。
从高可用性架构上，可分为单节点(基础版)、双节点(高可用性版)和三节点企业版和集群版(仅限SQL Server AlwaysOn)。从资源共享和隔离的角度，可以分为通用型、独占型、共享型和独占物理机(可以理解为专用独占型)。从磁盘使用量的不同，可以分为云盘版和本地盘版。
目前RDS最大规格是104核CPU，内存768GB。其中，通用型，最高为12核CPU；最大共享CPU是32个核心。
主要架构类型数据库通常是企业业务架构的核心组件，数据库的可用性直接关系到业务可用性。所以，在云数据库架构的选择上，高可用性是首先需要注意的。
从高可用角度，阿里云数据库提供基础版(即单节点)、双节点高可用版和三节点企业版。不同的版本是成本、可用性和数据可靠性之间的平衡：
单个节点通过简单的架构以最低的成本提供基本的可用云数据库服务。双节点高可用版本是一种适合大多数业务场景的模式。这两个节点分布在一个区域的两个可用区域中。出现故障时，切换速度更快，数据有备份，可靠性更高。对于三节点企业版，底层数据通过X-Paxos保持一致。并且使用三个副本(两个数据副本和一个日志)来确保数据可靠性。基础版2.1(即单节点版)阿里云基础版使用阿里云磁盘作为数据库存储，挂载在数据库的计算节点上，实现了存储和计算的分离。这使得当计算节点发生故障时，可以通过重用新的计算节点并重新安装原始数据库存储来启动数据库并恢复故障数据库。因此，当计算节点发生故障时，RPO通常小于1分钟，RTO为5分钟到1小时。当整个可用区域出现故障时，RPO和RTO的值取决于数据库备份的频率。
2.2高可用版本双节点高可用是用户使用最多的版本，也是最常见的数据库架构。数据库由两个节点组成，主节点和备用节点，它们由数据库层的逻辑日志复制。与单节点相比，数据可靠性和服务可用性都有很大提高。由于主备节点都在同一个大区域，日志延迟通常很小，所以单个节点失效时，高可用版本的数据可靠性通常相对较高。注意AWS对应的双节点版本RPO为零，那么阿里云数据库呢？
具体来说，对于阿里云RDS MySQL，阿里云的两个节点都是高可用的，根据选择的参数模板可以分为以下三类：
高性能：sync_binlog=1000，Innodb _ flush _ log _ at _ Trx _ commit=2，异步异步模式：sync_binlog=1，Innodb _ flush _ log _ at _ Trx _ commit=1，异步默认：sync _ binlog=1，Innodb _ flush _ log _ at _ Trx _ commit=1，半同步其中，“高性能”版本和“异步”版本为异步复制。当主节点出现故障时，由于复制是异步的，少量事务日志可能无法传输到备用节点，少量事务可能会丢失。也就是说，为了达到更好的性能，这两个版本在数据库的RPO上做了小小的让步。“默认”版本使用半同步复制，通常具有更高的数据可靠性。但由于半同步可能会有降级场景，这种模式下的数据复制仍然是极端情况，也存在数据丢失的可能。
那么，既然“异步”模式和“高性能”都有数据丢失的风险，那么它们之间有什么区别呢？简单总结，“异步”不太可能造成微小的数据丢失。因为，通过设置sync _ binlog=1，innodb _ flush _ log _ at _ Trx _ commit=1，可以尽可能的保证主节点的数据可靠性。
事实上，高可用版本可以满足大多数业务场景的需求。一方面，相同可用区域内的数据传输延迟非常小，日志传输通常非常流畅。即使主节点出现故障，在实际情况下，通常也没有日志延迟。另外，主节点出现故障后，通常可以通过重启等方式恢复。云厂商的硬件都有比较规范的硬件过度保护和淘汰机制，硬件完全不可用的情况并不多。另外，底层磁盘会使用硬RAID或者软RAID，保证磁盘数据存储的可靠性。即使数据在一台机器上，也会存储在两个磁盘上。
双节点高可用版在一些特殊场景下，还是存在一些数据不可用的风险。比如其中一个节点失效，本地数据量非常大，就需要在新机器上建立一个备用节点。由于数据量较大，重建时间通常会较长。此时主节点将一直运行在单个节点上，如果主节点再次出现故障，将会不可用或丢失数据。如果对数据安全有更高的要求，可以考虑选择“三节点企业版”。
2.3三节点企业版目前只有RDS MySQL有这个版本。三节点企业版使用基于X-Pax OS 4的一致性协议实现数据的同步复制，适用于对数据安全性和可靠性要求较高的场景，比如金融交易数据。在三个节点中，一个节点只存储日志，以达到接近两个节点的成本和价格，达到更高的数据安全性和可靠性。
三节点企业版创建时，可以分布在1~3个可用区域。如果需要跨可用区域的容灾能力，可以划分三个副本。
布于三个可用区，如果需要更高的性能，则可以让三个副本都在同一个可用区。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有着非常大的性能差异。通常，这些差异并不是厂商之前的技术能力导致的，更多的是由于他们在对于安全性和性能的平衡时，选择的不同的平衡点。
03资源复用与规格从资源共享与隔离上，RDS又分为：通用型、独享型和共享型。具体的：
“通用型”适合一般的业务使用场景，但有一定的CPU共享率，也就说是，有一定的概率实例的资源可能会被其他实例争抢而导致性能的波动 。“独享型”则使用完全独享的CPU的资源和内存资源，不会共享其他人的资源，自己的资源也不会被其他人共享，所以，有更稳定的性能。“共享型”则与通用型类似CPU资源会被共享，并且共享率更高，所以性价比更高，同时受到资源争抢的影响的可能性也更大，当前仅SQL Server支持。除了，上述主要规格类型之外，阿里云还提供了“独占物理机”规格，选择该规格的用户可以完全的独占一台物理机的资源：
04数据库专属集群MyBase专属集群MyBase是阿里云推出的一种特殊的形态。可以理解为，是一种全托管RDS与自建数据库的中间形态。在全托管的RDS基础上，提供了两个重大的能力：
允许用户登录数据库所在的主机允许用户配置数据库实例CPU的“超配比”当然，要求是用户一次购买一个非常大的、可以容纳多个RDS实例的“大集群”，专属集群则提供了以上两个能力，以及RDS其他的基本能力，包括安装配置、监控管理、备份恢复等一系列生命周期管理能力。
使用这种规格，用户具备更大的自由度。一方面可以登录主机，观测主机与数据库的状态，或者将自己原有的监控体系部署到专属集群中。另一方面，用户可以根据自己的业务特点，控制集群内的CPU资源的超配比。对于核心的应用，则使用资源完全不超配的集群；对于响应时间没有那么敏感的应用，例如开发测试环境，则可以配置高达300%的CPU超配比，以此大大降低数据库的成本。
05关于本地盘与云盘版阿里云的主要版本都会支持本地SSD和高性能云盘。他们的差异在于计算节点与磁盘存储是否在同一台物理机器上，对于使用高性能云盘的规格，通常是通过挂载一个同地区的网络块设备作为存储。
对于阿里云厂商来说，未来主推的将是云盘版。原因是云盘相对于本地盘来说，有很多的优势：
统一使用云盘版，让云厂商的供应链管理变得简单。如果使用本地盘版本，意味着数据库机型定制性会增强，供应链的困难会增加产品的成本，最终影响价格。另外，简单的供应链也会让产品的部署更加标准化，更加敏捷地实现多环境多区域的部署。使用云盘版，也可以理解为是“存储计算分离”的架构，那么如果计算节点故障，则可以快速通过使用一台新的计算节点并挂载云盘，而实现高可用。这种方式有着非常好的通用性，无论是哪种数据库都可以使用，而无需考虑数据库种类之间的差异。无论是MySQL还是PostgreSQL、Oracle都可以使用这种方式实现高可用。云盘版本身提供了一定的高可用与高可靠能力。云盘本身数据可以通过RAID或者EC算法实现数据的冗余与高可用，并且可以将数据分片到不同的磁盘与机器上，整体的吞吐会更高。云盘版本身是分布式的，可以提供更高的吞吐，通常还可以提供更大的存储空间。例如，各个云厂商的云盘存储都可以提供12TB或32TB的存储空间，基本上可以满足各类业务需要。当然，使用云盘也有一些缺点，例如，相比本地盘，云盘的访问延迟更大，需要通过网络访问，而对于数据库这类IO极其敏感的应用，本地磁盘的IO性能的稳定性通常会更强一些
06关于通用型与独享型的性能独享型规格的资源完全由用户独立使用，价格通常更贵。而通用型则因为部分资源的共享，会导致性能在某些不可预期的情况下发生一些不可预期的波动。而独享型规格也更贵，更多的企业级场景，也会推荐使用独享型，会有很多人会认为独享型的性能也更高。而实际上，如果做过实际测试就会发现，一般来说，相同的规格，通用型的性能与吞吐通常都会更高。
所以，实际情况是，通用型的价格更加便宜，性能也会更好。缺点在于，可能会出现一些不可预期的性能波动，而因为大多数数据库应用都是IO密集型的，所以，实际场景中，这种不可预期的波动并不是非常多。
所以，这两个版本的选择，需要用户根据自己的实际情况去选择。如果，可以接受偶尔的性能波动，则一定是建议选择通用型的；如果应用对数据库的响应时间极其敏感，则应该选择独享型。另外，当前，通用型最大规格仅支持12核CPU，所以对于压力非常大系统，则只能选择独享型。
07关于超配比对于在线数据库应用来说，通常是IO或者吞吐密集型的。CPU资源在很多时候，会有一定的冗余。对于云厂商来说，则可以通过超配CPU的售卖率来降低成本，同时也降低数据库资源的价格，这就是通用型背后重要的逻辑。
而一般来说，可以超配的通常只有CPU资源。磁盘资源虽然可以超配，但是实际使用中，是不能重合的，当用户的磁盘占用增到购买值的时候，资源则不可以共享，这与CPU的超配并不相同。内存资源则更加是独享的，Buffer Pool的通常是满的，无论这些内存页是否被实际使用，数据库总是会尽力在内存中存储尽可能多的数据。
MyBase提供的一个重要配置项，就是可以用户自定义底层资源的超配比，该比率取值从100%~300%。也就是说，一个32核CPU的资源，最多可以分配给12个8核CPU的实例使用，看起来是96=12*8个CPU被使用，即实现了300%的超配比。
