简介：PolarDB由阿里巴巴自主研发的下一代关系型分布式云原生数据库。在兼容传统数据库生态的同时，冲破了传统单机硬件的限度，为用户提供大容量，高性能，极致弹性的数据库服务。

一、背景

传统的关系型数据库有着悠久的历史，从上世纪60年代开始就曾经在航空畛域发挥作用。因为其谨严的强统一保障以及通用的关系型数据模型接口，取得了越来越多的利用，大有一统天下的声势。

2000年当前，随着互联网利用的呈现，很多场景下，并不需要传统关系型数据库提供的强一致性以及关系型数据模型。相同，因为疾速收缩和变动的业务场景，对可扩展性(Scalability)以及可靠性(Reliable)更加须要，而这个又正是传统关系型数据库的弱点。

天然地，新的适宜这种业务特点的数据库呈现，就是咱们常说的NoSQL。然而因为不足强一致性及事务反对，很多业务场景被NoSQL拒之门外。同时，不足对立的高级的数据模型，拜访接口，又让业务代码承当了更多的累赘。数据库的历史就这样经验了否定之否定，又螺旋回升的过程。而这一次，鱼和熊掌咱们都要。

PolarDB就是在这种背景下呈现的，由阿里巴巴自主研发的下一代关系型分布式云原生数据库。在兼容传统数据库生态的同时，冲破了传统单机硬件的限度，为用户提供大容量，高性能，极致弹性的数据库服务。

二、核心技术之共享存储

PolarDB采纳了Share Storage的整体架构。采纳RDMA高速网络互连的泛滥Chunk Server一起向下层计算节点提供块设施服务。一个集群能够反对一个Primary和多个Secondary节点，别离以读写和只读的挂载模式通过RDMA挂载在Chunk Server上。PolarDB的计算节点通过libpfs挂载在PolarStores上，数据依照Chunk为单位拆分，再通过本机的PolarSwritch散发到对应的ChunkServer。每个ChunkServer保护一组Chunk正本，并通过ParallelRaft保障正本间的一致性。PolarCtl则负责保护和更新整个集群的元信息。

Bypass Kernel

PolarDB诞生于2015年，因为RDMA高速网络的呈现，使得网络带宽靠近于总线带宽。PoalrDB作出大胆的假如，那就是将来数据库的瓶颈将由网络转向软件栈本人。因而PolarStore中采纳了大量的Bypass Kernel的设计。首先是新硬件的应用，NVME和RDMA的应用，解脱了IO拜访过程中的用户态内核态交互。

软件设计中，在绑定CPU，非阻塞IO的模式下，通过状态机代替操作系统的线程调度，达到Bypass Kernel的目标。

ParallelRaft

PolarStore中采纳三正本的形式来保证数据的高可用，须要保障正本间的一致性。工业界有成熟的Raft协定及实现，但Raft因为对可了解的谋求，要求程序确认以及程序提交。而正本的确认提交速度会间接影响整个PolarStore的性能。为了取得更好的访问速度，PolarStore提出了ParallelRaft协定，在Raft协定的框架下，利用块设施拜访模式中不便断定拜访抵触的特点，容许肯定水平的乱序确认和乱序提交，如下图所示：在所有曾经确认提案中，那些对前序拜访有拜访Range抵触的提案会被临时Block，而没有抵触的提案会进入Ready状态并commit，commit当前的提案会持续反馈给以后的Scheduler，之前被Block的提案有可能会进入Ready状态，进而持续被提交。

三、核心技术之物理复制

采纳了共享存储的模式之后，Secondary上仍然须要从Primary来的复制逻辑来刷新内存构造，如果Buffer Pool以及各种Cache。然而，因为读写节点和只读节点拜访的是同一份数据，传统的基于binlog的逻辑复制形式不再可用，这时因为逻辑复制因为最终执行程序的变动，导致主从之间不同的物理数据结构。因而DB层基于Redo Log的物理复制的反对是必不可少的：

不同于逻辑复制自上而下的复制形式，物理复制的复制形式是自下而上的，从共享存储中读取并重放REDO，重放过程会间接批改Buffer Pool中的Page，同步B+Tree及事务信息，更新Secondary上的各种内存Cache。除了反对共享存储外，物理复制还能够缩小一份日志写。同时，因为整个复制过程不须要等到事务提交能力开始，显著地缩小了复制提早：

四、交易场景优化

针对双十一峰值交易场景，PolarDB也做了大量优化。

Blink Tree

在峰值交易场景中，会有大量波及热点page的更新及拜访，会导致大量对于这些热点Page的SMO操作，

之前PolarDB在SMO场景下因为B+Tree实现有如下的加锁限度：

同一时刻整个B+Tree 有且只能有一个SMO在进行；
正在做SMO的B+Tree分支上的读取操作会被阻塞直到整个smo实现。

针对这个问题PolarDB做了如下优化：

通过优化加锁，反对同一时刻有多个SMO同时进行，这样本来期待在其余分支做SMO的插入操作就无需期待，从而进步写入性能；
引入Blink Tree来替换B+Tree并通过缩小SMO的加锁粒度，将本来须要将所有波及SMO的各层Page加锁直到整个SMO实现后才开释的逻辑，优化成Ladder Latch，即逐层加锁，批改完一层即可放锁而后去加上一层Page锁持续批改。这样本来被SMO阻塞的读操作会有机会在SMO两头进来：通过对每个节点减少一个后继链接的形式，使得在Page Split的中间状态也能够实现对Page平安的拜访，如下图所示，传统的B+ Tree必须通过一把锁来Block整个Page Split过程中对所影响的Page的拜访。而Blink Tree则不须要，即便Split还在进行中，父节点到子节点的链接还没有实现建设，仍然能够通过前一个节点的后继链接找到正确的子节点。并且通过非凡解决确保拜访到正确的Page，从而进步读取性能。

通过这些对B+ Tree的优化，能够实现交易场景PolarDB读写性能晋升20%。

Simulated AIO

InnoDB中有simulated AIO的逻辑，用于反对运行在不蕴含AIO的零碎下，PolarDB下的共享存储文件系统就是没有AIO的，所以采纳的是simulated AIO的逻辑。

然而原版中的simulated AIO是基于本地存储设计的，与分布式存储的个性并不适配。为了进行IO合并，原版的simulated IO设计，将所有异步IO申请依照指标地址进行组织，寄存在同一个IO数组中，不便将指标地址间断的小IO合并成大IO来操作，以晋升IO的吞吐。

然而这个设计与分布式存储是不相适配的，间断的大IO操作，会使得同一时刻，只有一个或大量存储节点处在服务状态，节约了其余存储节点的作用；另外，分布式存储的网络提早较大，高负载下，网络中的Inflight IO会较多，IO组中的IO申请数量也会很多，而这种组织形式下，IO数组中的槽位状态都无序的，往数组中增加IO申请和移除IO申请的开销都很大。

所以，PolarDB在高负载下的性能比拟差且不稳固，为此PolarDB专门对simulated AIO进行了从新的设计，次要包含：

a.正当地抉择IO合并和拆解，充沛利分布式存储的多节点劣势；

b.建设状态有序的IO服务队列，缩小高负载下的IO服务开销。

从新设计下，性能晋升了很多

稳定性也有了很大的晋升

Partitioned Lock System

PolarDB采纳的是2PL + MVCC的并发管制形式。也就是用多版本数据构建Snapshot来服务读申请，从而防止读写之间的拜访抵触。而读写之间的抵触须要通过两阶段锁来保障，包含表锁，记录锁，谓词锁等。每当须要加锁的时候，之前的做法都须要去log\_sys中先取得一把全局的mutex爱护。在峰值的交易场景中，大量的写入会导致这个中央的mutex成为瓶颈。因而PolarDB采取了Partition Lock System的形式，将log\_sys革新成由多个LockSysShard组成，每个Shard中都有本人部分的mutex，从而将这个瓶颈打散。尤其是在这种大压力的写入场景下显著的晋升写入性能。

Lockless Transaction System

PolarDB中反对Snapshot Isolation的隔离级别，通过保留应用的Undo版本信息来反对对不同版本的记录的拜访，即MVCC。而实现MVCC须要事务零碎有能力跟踪以后Active及曾经Commit的事务信息。在之前的实现中每当有写事务开始时，须要调配一个事务ID，并将这个ID增加到Transaction System中的一个沉闷事务列表中。当有读申请须要拜访数据时，会首先调配一个ReadView，其中包含以后已调配最大的事务ID，以及以后这个沉闷事务列表的一个备份。每当读申请拜访数据时，会通过从Index开始的Roll ptr拜访到这个记录所有的历史版本，通过比照某个历史版本的事务ID和本人ReadView中的沉闷事务列表，能够判断是不是须要的版本。

然而，这就导致每当有读事务开始时，都须要在整个拷贝过程对这个沉闷事务列表加锁，从而阻塞了新的写事务将本人的ID退出。同样写事务和写事务之间也有拜访沉闷事务列表的抵触。从而沉闷事务列表在这里变成一个显著的性能瓶颈，在双十一这种大压力的读写场景下尤为显著。

对此，咱们将Tansaction System中的这个沉闷事务列表革新成无锁Hash实现，写事务增加ID以及读事务拷贝到ReadView都能够并发进行。大大晋升了性能。

版权申明：本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。