高见：PolarDB for MySQL是阿里巴巴自研的新一代云原生关系型数据，PolarDB集群版采用存储和计算分离的架构，集群中有一个主节点可读可写和至少一个只读节点。
随着PolarDB for MySQL引擎客户的不断增加，大规模头部客户不断涌入，部分头部客户业务体量规模庞大，使得目前PolarDB for MySQL引擎的一写多读架构在特定场景下，写性能出现瓶颈。
本次PolarDB for MySQL多主架构集群版的发布，实现了集群架构从一写多读到多写多读升级，以及写性能的横向扩展，让用户购买的资源得到了最大化的利用。
下面让我们来听一下市场的声音，客户在什么业务场景下遇到了哪些痛点，需要通过云原生的多主架构来解决？
君远：众所周知，PolarDB for MySQL以其100%兼容MySQL、高性能、高稳定性、高弹性、大存储、HTAP等优势能力，受到国内外数据库客户的青睐，在关系型数据库市场占据了重要的位置。
从在业务发展初期，数据量和并发访问量较小的情况下，客户利用PolarDB的写节点可以轻松满足各类业务数据的存储和读取。
随着业务发展，业务复杂度、数据量、并发访问量逐步增加，当前PolarDB规格已经不能满足业务需求情况下，客户需要升配PolarDB的写节点规格，来支撑数据量和并发访问量的快速增长。
此方案的优势是操作简单、业务无需改造、升配时间短；不足之处是写节点受限于本地服务器资源规格上限。
目前PolarDB单节点最大规格是88核710GB，如果客户业务上出现高并发、复杂读流量场景，读流量和写流量也会互相影响，导致业务受损。在这种业务场景下，很多客户需要增加读节点，利用读写分离提高系统的读承载能力，以确保客户支持更多的业务、更多数据、更多的访问量。
PolarDB为解决读节点延迟而读不到最新数据的问题，通过数据库代理提供最终一致性、会话一致性、全局一致性等多级读一致性能力，以满足客户在不同场景下对一致性级别的要求。
通过一写多读和读写分离一致性级别，PolarDB满足了大部分客户对数据库扩展性的需求。但是当客户希望横向扩展写能力、需要写隔离、支撑写业务的快速切换时，读写分离就有些力不从心，需要数据库能提供写扩展能力来满足业务需求。
不少客户在业务发展初期为开发降低开发成本和架构成本，以及部分to B客户为了产品输出、部署简单，采用多个业务模块存储在一套数据库的方式，PolarDB有不少客户就是这样的。
随着业务业务持续发展，数据量、访问量持续增加，不同业务模块的写特点也有可能不同，对数据库写TPS的诉求越来越高，会面临以下问题：
各业务模块共同的并发写诉求单个写节点已经不能承载；
在业务高峰期A业务的并发写可能会影响B业务的写入；
写节点异常导致业务整体异常，无法及时恢复；
通过垂直升配提高写容量的成本越来越高。
通过垂直升配、读写分离能解决部分写扩展问题，在性价比、稳定性、成本方面存在不少问题，客户更期待一个平滑扩展、高弹性、高稳定性、高性价比的数据库写扩展方案来支撑数据库写性能的横向扩展。
高见：面对这些场景和痛点，PolarDB for MySQL的多主架构是如何解决的呢？
江疑：多主技术一直被誉为是数据库技术中皇冠上的明珠。早在云时代开始之前，能够实现多主写扩展技术的只有头部的两大商业数据库，其他开源数据库都无法做到这一点。这两大厂商也因此在数据库市场最核心的银行、金融、电信等领域占有垄断性的市场。
而其他商业或者开源数据库则主要以单主的一写多读形态存在，当需要写扩展的时候，往往通过购买多个单主数据库集群，并通过中间件或者ShareNothing的分布式数据库技术，将多个单写数据库分片聚合在一起，来实现写扩展。
云时代到来以后，各个头部云厂商都提供了云原生数据库的形态，PolarDB国内第一个云原生数据库。云原生数据库在传统数据库的技术上和云的基础设施进行了融合，例如PolarDB通过和分布式存储PolarStore的融合，使得其在弹性、读扩展、存储容量上面有了大幅度的提升。
但是和云时代之前一样，云原生数据库在一开始还是难以突破多主技术的壁垒，当业务数据库增长达到单机上限瓶颈的时候，目前主流的方案还是只能通过多个单主集群拆分业务，中间件拆分数据，ShareNothing分布式数据库拆分数据等传统方案进行。
这些传统方案都存在如下的显著瓶颈：
微观上都是通过拆分数据到多个单主集群/单主分片实现，当需要进行横向扩展是需要进行数据物理拆分和迁移，这种迁移非常的费时，有点类似传统数据库上扩只读节点那样需要迁移数据，并没有充分的利用云的基础设施的能力。同时拆分子业务和拆分数据分片的方案，难免都会遇到不同的业务/分片流量不均，或者短时间的分片流量突增，而由于分业务和分片只能通过迁移数据扩展，容易引发局部容量瓶颈导致的稳定性故障；
当业务通过拆分到多个单主节点以后，如果需要进行全局的数据查询，业务往往需要一个额外的聚合库来进行聚合查询。这时就需要一个多链路的同步机制和一个额外的包含所有数据的大容量存储来支持。此时不单存储成本和容量都会直接翻倍，而且同步链路的延迟和稳定性也会让业务同学焦头烂额；
由于传统的拆分子业务和拆分数据分片的方案，每个单主节点和分片都包含一部分数据，因此需要一个独立的备节点来解决这个节点的高可用问题，而这个备节点大部分情况下是浪费的，或者最多提供一些延迟读请求。
那么PolarDB MySQL的多主架构是怎么来解决这些问题的呢？
PolarDB多主架构是基于第一代云原生架构的PolarDB一写多读架构实现的，是第一种实战的第二代云原生架构。他继承了一代云原生架构的存储和计算分离的技术，在大规模分布式存储的基础上实现了多个写节点共享同一份存储的多主技术突破，主要分为以下几点：
使得一个数据库最大可以支持32个写节点，用户可以通过动态秒级的添加/删除写节点来实现横向弹性扩展，扩缩整个集群的读写能力，而无需干扰现有业务；
用户可以秒级跨写节点迁移读写流量，来实现多个子业务和数据分片的读写均衡；
PolarDB多主架构在业内第一次实现了可以横跨多个主节点的全局RO功能。在不增加额外存储的同时，实现高效的汇聚查询，为用户解决了独立聚合库的大难题；
PolarDB多主架构实现了主主互备能力，每一个子业务/数据分片主节点都不需要在额外有一个备节点来实现高可用。当某一个主节点宕机时，多主架构通过动态选择其他低负载主节点接管宕机主节点流量，实现集群内再平衡。和云原生数据库相比，计算成本就直接降低到原来的1/2了；如果和自建/托管数据库相比，计算/存储成本均降为原来的1/2。
那么PolarDB MySQL的多主架构是怎么突破的这个多主技术瓶颈的呢？
难点一：没有一个的统一的分布式元数据管理系统。
多主架构支持库表及流量跨主节点切换，必然需要一套可以多点读写的分布式元数据体系，使得多个节点看到的库表结构均是完全一致的，并可以同时访问和修改。多主架构采用了PolarFusion技术，实现了在多个主节点上元数据的数据页的内存直接同步，实现了多节点强一致的分布式元数据体系，支撑了整个多主架构的秒级动态扩缩容，跨主节点秒级切流，本地DDL等功能，是整个多主架构的基石。
难点二：秒级切换流量。
多主架构的多个核心优势均体现在跨主节点的流量秒切上面，而数据库的流量运行，不单需要访问数据存储本身，同时涉及到内存中缓存的数据页面，特别是脏页；涉及到多种必不可少的额外信息例如undo log，redo log，统计信息等等，这些信息都是耦合在一起的，并且各有各的不同点，需要在切流的时候针对其特点进行妥善的处理，来支撑秒级切流。
难点三：一体化的事务系统。
多主架构下，跨越主节点的并发访问，在流量切换下的事务一致性，全局RO的事务定序，历史数据的有序purge都需要有一个分布式的事务系统来协调和处理这些在单机上很容易解决的问题。多主架构设计了跨越多个主节点的全局事务管理系统，解决所有集群维度的事务/流量协调。
高见：基于该架构的加持，多主架构集群版实现了三大技术优势：
1. 线性扩展
多主架构集群与标准的PolarDB集群版不同，标准集群版支持1个读写节点和最多15个只读节点，全部的写入操作指向唯一的读写节点，而多主架构集群版打破了这种限制，所有数据库实例节点都具备了读写的能力。
根据阿里云实验室的测试数据，多主架构集群版随着节点的增加，集群整体并发读写能力得到了极大的提升，性能扩展可以说是线性提升。相对于友商的多主架构最大支持4节点扩展，PolarDB的多主架构集群版最多可支持32个节点同时写入，极限性能有了数倍提升，最大程度满足用户超高并发下的严苛性能要求。
2. 快速弹性
传统主备数据库架构下，增加节点需要全量复制数据，节点弹性的时间依赖数据量大小，从小时到天级不等，无法应对突增的业务性能要求。分表分库的分布式架构下，增加节点需要数据Re-Balance，迁移部分数据到新增的节点上，这个过程和数据量及新增节点数强相关，也需要花费较长时间提前规划维护窗口。PolarDB多主架构集群中所有读写节点共享同一份数据，增加节点做弹性扩展时，无需数据搬迁，5分钟生效，数据库跨节点动态调度，秒级完成切换，轻松应对不确定的业务增长。
3. 降低成本
传统数据库架构下，业务系统为了维持高可用，采用自建或者RDS数据库服务方式时，通常会选择主备架构。备节点无法提供服务或仅提供少量的读服务，造成资源闲置，成本高昂。PolarDB多主架构集群的节点间互为备份，故障场景下可以快速切换由其他节点接管业务，无需专门的备节点。相对于传统自建方式或者RDS的主备方式，可节省约一半的计算节点费用，存储费用也会相对减少。
有了这些优势，相信多主架构集群版可以为用户提供更优质更具性价比的数据库服务。
高见：PolarDB for MySQL的多主架构集群版已经做了灰度发布，前面已经有很多重量级的客户进行了功能的试用，并且有部分客户已经将生产业务搬到了多主架构集群版上。那么客户真实的使用情况如何，能不能解决客户的问题，我们来听一下来自客户的反馈。
君远：在我服务的客户里有一类企业服务商客户，他们的业务特点和开发模式非常适合多主架构集群版。其中一个客户，业务上有一个基础平台系统和五六个核心业务系统。不同业务系统之间以及业务系统和基础平台之间有数据交互，他们云上的数据库架构是基础平台和业务系统的库做垂直拆分，采用这样的架构出于满足写扩展和写隔离的诉求，有十几个核心数据库实例，这些数据库之间由于业务侧需求，有跨库数据访问的诉求，通过数据复制工具进行不同数据库之间的数据复制，形成了复杂的级联复制链路，大大增加了维护数据库成本和维护成本，同时由于复制链路不稳定，当数据复制延迟是业务侧服务会一定程度上受损。
为解决这些问题，该客户提出用一套高规格、多实例数据库来承载基础平台系统和业务系统数据库的规划，来降低开发难度、降低输出数据库成本、降低部署难度、提高健壮性和稳定性。该需求的核心诉求是写扩展、写隔离、开发简单、跨数据库节点聚合查询数据。
首先，希望数据库方案支持写扩展和写隔离，能快速扩展写节点，同时支持写隔离用于隔离基础平台和业务系统的高并发写，以免在业务业务的高峰期出现写争抢以及出现A业务的写影响了B业务，在功能、性能、容量上满足各业务模块对并发写的诉求；其次，需要能支持不同数据库的跨节点数据库数据聚合查询，降低业务侧的开发难度；第三，如果其中一个数据库写节点出现异常，希望可以快速切换和恢复。
在客户提出这个需求的时候，我们也在规划多主架构集群版产品形态，基于客户的需求和客户进行了多轮共创。写扩展和写隔离是多主架构集群版核心能力，可以天然满足客户需求；跨数据库节点的数据聚合查询，我们在考虑多种实现方式以及方案交付及时性权衡后，提出用全局读节点来满足客户的跨数据库聚合查询的诉求，并且可以通过智能代理进行智能分流，不需要客户针对不同节点进行业务适配，客户在理解了我们的技术实现后表示可以满足业务需求。
对于数据库写节点异常快速切换的能力，我们提供了两个方案：
方案一：基于共享存储在不同写节点切换数据库；
方案二：提供备用standby节点进行高可用切换。
客户觉得第一个方案更适合他们的业务需求。至此多主架构集群版产品能力完美适配客户的业务需求，并在客户的预期时间点正式发布。
江疑：刚才我已经提到了PolarDB的多主架构在架构层面的技术突破，使得PolarDB完成了从一代云原生的一写多读架构到二代云原生的多写多读的多主架构转换。接下来我详细介绍下，多主架构的几个核心功能的技术内幕。
1. 主主互备
主主互备是多主架构的核心竞争力的技术点，在降本增效的大势下，如果我们能将计算和存储的成本直接减半，而不影响性能，这无疑有巨大的吸引力。那么主主互备就是这样的功能点。
主主互备打破了传统数据库甚至云原生数据库大规模数据集群形态想永远都是多个一主一备的架构，直接在不牺牲性能和高可用的前提下，裁剪掉了备节点，成本直接减半。那为什么只有PolarDB多主架构能做到呢？
最核心的就是多主架构下，多个主节点的存储是物理打通的，任何一个主节点，都可以同时作为其他主节点的备节点。这在单主架构下是无法实现的，这个架构突破给多主架构带来了巨大的成本优势。
当然主主互备有非常多的技术挑战：
首先虽然多个主节点共享存储，但是大家都独立的redo log等，当一个主节点crash的时候，是需要recovery的，而不是能直接的切流到其他主节点，这时候我们需要其他主节点有在运行态帮助crash节点实现recovery的能力，而这个能力无论是工作量还是技术挑战都非常复杂，我们是云厂商中第一家拥有这个能力的数据库；
其次主主互备中需要存活探测，流量探测，流量切换，流量再平衡等复杂流程，相对于原来的简单主备切换，需要有一个分布式的高可用管理系统，这个架构也是我们第一次在业内实现。
2. 全局只读节点
全局RO是PolarDB多主架构的另外一个核心创新点和优势点。在多主架构下，分布式共享存储上存储了多个主节点的所有数据，这给全局RO的实现提供了可能。在多主架构下，我们不再需要用多流和并的方式把多个单主小集群的数据汇聚到一个独立的汇聚库中，而天然存在一份包含所有数据的存储集群。当然全局RO同样存在多个核心功能挑战：
多流物理复制：全局RO不是只要能访问到全局的存储数据就能实现，在访问数据的同时，全局RO同样需要感知到所有主节点最新的更新信息，并且在内存中对多个主节点的更新数据进行同步，这对于事务系统是一个巨大的挑战；
分布式事务一致性读：多个主节点的修改，在同一个RO节点上如何定序，如何保证事务读的ACID，这都需要有一个分布式事务一致性读的机制，在主节点上进行事务写入的时候，就进行协调。
高见：我们看到，多主架构集群版很好的解决了用户的扩展问题，非常适合用户将大量零散数据库进行聚合，相对于传统方式成本也有了大幅的降低。本次是多主架构集群版正式发布的第一个版本，产品功能还有很大的成长空间，后面也会不断的演进优化，那么产品研发团队近期主要是在做哪些方面的优化，主要的方向是哪些？
江疑：PolarDB多主架构集群版的演进思路有以下三个方面：
1. 多主架构未来需要加强的方向：
目前高可用已经支持了主主互备，之后我们会把这套做的更自动，结合秒级切换的体系，把它的高可用做成一个无感的高可用，把备节点都全部的优化掉；
在全局RO的基础上支持跨节点的订阅读。可以在一个主节点上读到另一个主节点的数据；
支持分布式表。把一个分布式表的多个分区放到多个RW上，然后来实现一个透明的显能力扩展。
支持分布式事物。因为跨区的分布式事务相关的需求还是非常强烈的。
2. 多主架构和Serverless的融合，按需扩缩主节点；
3. 在多主架构上实现行级多写的突破，PolarDB Cloud RAC。
高见：PolarDB for MySQL多主架构集群功能已经全面上线，可以在新购页面系列中选择“多主架构集群版”选择该功能，当前该功能已支持8.0以上内核版本。更多购买方法、使用说明请参见官网。
