简介：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 都能够并发进行。大大晋升了性能。

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