2.3.1　以PolarDB-X为代表的Share Nothing分布式集群

传统的Share Nothing思想，最典型的应用就是基于日志复制的主从结构。这个结构清晰、简单，复制节点往往还能够实现只读查询需求，所以深受业内推崇。但主从结构也有其短板：

（1）主从结构大多是一主多从

想要实现多主，数据的冲突检测机制如何实现，这是一个非常大的问题。最知名的解决方案是Microsoft SQL Server的Merge Replication。这种解决方案往往非常复杂，一旦遇到问题非常难以排查，运维成本非常高，对应用的抗冲突要求也很高。所以大部分主从结构只能增加只读能力，而不能增加写入能力。

（2）主从结构会遇到主从复制延迟，导致不一致读

在基于日志复制的主从结构中，如果遇到大事务，则可能会导致主从复制延迟。这是所有数据库都会遇到的问题，只不过使用物理日志复制的数据库相对会好点，Redo的速度会更快，日志本身也会小一些。而使用逻辑日志复制的MySQL，除了可能遇到大事务，其他一些场景中也可能遇到延迟。比如没有主键，导致Slave的执行计划错误，只读apply log（应用日志）的效率特别低。

（3）主从结构的从节点越多，越容易拖垮主实例

即便强如Oracle，在一主多从的情况下，从节点越多，复制的压力就越大，这也是蚂蚁金服使用分布式数据库替代Oracle的一个重要考量。物理日志复制尚且如此，逻辑日志复制的问题也不可避免，RDS for MySQL一般最多允许创建5个只读实例，这其实限制了这个结构的上限。

为了克服主从结构的短板，提高扩展性，分库分表一直是一个说起来容易，做起来难的话题。业界也有很多类似的中间件，但是它们的稳定性和性能则参差不齐。阿里云的解决方案是以PolarDB-X的水平分片，以中间件+数据库的方式，完整提供一个高并发度的Share Nothing集群。

这显然带来了如下几个好处：

计算能力得到增强，且不受单机资源限制。

存储空间得到增强，且不受单机资源限制。

同时还能保留主从结构的读/写分离优势。

因为可以完全做两套Sharding，Master一套，Slave一套，等于有两套集群，依然可以像以前一样做读/写分离，甚至只读能力强了以后，还能承担一部分分析计算的工作。

接下来，我们依然按照MySQL的服务层和存储引擎层两层结构，来讨论PolarDB-X在这两层中是如何实现分布式的。

2.3.1.1　PolarDB-X分布式事务

不同于直连MySQL，所有的SQL语句完全透传到MySQL内的解析器、优化器、执行器中执行，现在因为底层是分表的，所以需要将逻辑SQL语句转换成多个分库分表的物理SQL语句。这就提出了一个非常大的挑战，即SQL语句重写。

因此在PolarDB-X集群中使用了CN节点，即通过原DRDS中间件技术进行多节点冗余的中心化分发，把逻辑SQL语句分解成多路物理SQL语句，下推到DN节点——实际处理的DN节点，可能是RDS MySQL InnoDB，也可能是X-Engine，甚至以后会实现PolarDB-M引擎，如图2-11所示。

在分布式事务上，DRDS原生已经实现支持2PC、XA和柔性事务，在当前的版本中，实现了CTS全局时钟，可以保证分布式集群的事务体验和单机是一致的，如图2-12所示。

在此基础上，可以完成多副本的一致性读，满足MVCC，如图2-13所示。

2.3.1.2　PolarDB-X存储层

有了服务层的准备工作，接下来就需要做SQL路由，把物理SQL语句打散到不同RDS下的不同分库里。

PolarDB-X和私有化/未私有化RDS是有连接池关系的，即前面的中间件部分会维持一个连接池访问RDS，而不需要使用短连接反复请求。

除了SQL路由，另一个重要的问题是事务一致性。PolarDB-X可以根据RDS的小版本，采用不同的分布式协议，比如MySQL 5.6 基本会使用2PC协议，而MySQL 5.7及以上版本，则会优先使用XA协议。这些协议是透明且自动化的，对于应用程序来说，不需要自己进行XA Prepare或者XA Commit。PolarDB-X 2.0版本已经完全支持MVCC和TSO。

在PolarDB-X 2.0中，我们在存储上做了两层绑定，方便业务优化。

表组（Table Group）：不同表捆绑相同的分片策略，解决join下推以及爆炸半径收敛的问题（比如银行业务涉及10张表，如果三台机器中有一台机器宕机，则需要确保只影响1/3的用户）。

分区组（Partition Group）：不同分片的物理资源隔离（比如银行业务按地域做了数据分区，一个地域业务出现异常，不会影响其他地域），如图2-14所示。

2.3.1.3　HTAP的场景与能力

在HTAP的场景下，现在只需要维护一条链路，CN节点的DRDS能自行分流复杂的SQL语句到AP副本（基于MPP），通过混合负载器进行一致性判断，再返回结果集，如图2-15所示。

有了混合负载器之后，还需要一个能真正进行AP运算的优化器，即CBO，如图2-16所示。

最后，给出阿里云PolarDB-X与相似产品的技术难点分析，如图2-17所示。