深度| 每秒1.4亿次！再度刷新TPS记录的PolarDB如何应对双11“尖峰时刻”？

2020年是云原生数据库PolarDB全面支撑天猫双十一的第二年，天猫交易、买家、卖家以及物流等系统在双十一期间基于PolarDB为亿万客户提供了顺滑的体验。同时，PolarDB还刷新了去年由自己创造的数据库处理峰值（TPS）纪录，今年TPS峰值高达1.4亿次/秒，较去年提升了60%。

PolarDB是阿里自研的云原生数据库品牌， 通过独有的存储计算分离、分布式共享存储技术，解决了传统RDBMS容量有限、扩缩容时间长等问题， 在性能、容量、弹性、以及可用性上都有很大的突破：

 存储容量可达100TB，单库可扩展到16个节点，满足企业级大数据存储需求。

 高性能、高弹性、低成本，一写多读，分钟级扩缩容

 多AZ高可用，数据高可靠性。跨AZ六副本，故障快速容灾转移

PolarDB今年下半年发布了MySQL 5.7的兼容版。至此PolarDB成为全球唯一一家兼容 MySQL 所有在役版本的云数据库，可以覆盖更多的业务场景

性能优化

性能对于双十一大促来说是永恒的主题。在天猫的核心交易链路的数据库，在零点峰值场景中，会有大量的数据读写。而每一年随着峰值的增长，数据库会遇到更严峻的挑战。在过去的几年中，随着数据库硬件的不断进化，我们为PolarDB重点优化了索引结构、I/O子系统、锁系统以及事务系统来完成并发性能的提升。

首先是索引结构。众所周知传统的InnoDB 索引在这样的场景下会遇到频繁的页面分裂导致的并发瓶颈。所有的对索引结构的修改都要排队串行执行。为了解决这个问题， PolarDB引入了新的索引结构来替代传统索引，细化索引结构变更时的并发粒度，提升了接近20%的读写性能。新的索引结构使得原本需要将所有涉及索引分裂的页面加锁直到整个分裂动作完成后才释放的逻辑变成逐层加锁。这样原本被索引页面分裂阻塞的读操作会有机会在整个分裂动作中间进来：通过对每个节点增加一个后继链接的方式，使得在分裂的中间状态也可以完成对数据页面的安全的访问，从而提高读取性能。

再接下来是锁系统的优化。 PolarDB和MySQL一样都是采用MVCC的方式看来做事务之间的并发控制， 但是在处理写请求和写请求之间的并发时是通过两阶段的锁来做保护的。大量且频繁的插入更新删除带来了锁系统的负担和并发的瓶颈。 因此PolarDB采取了Partition Lock System的方式，将锁系统改造成由多个分片组成，每个分片中都有自己局部的并发控制，从而将这个瓶颈打散。尤其是在这种大压力的写入场景下明显的提升写入性能。

最后是事务系统。 PolarDB中支持Snapshot Isolation的隔离级别，通过保留使用的Undo版本信息来支持对不同版本的记录的访问，即MVCC。而实现MVCC需要事务系统有能力跟踪当前活跃及已经提交的事务信息。在之前的实现中每当有写事务开始时，需要分配一个事务ID，并将这个ID添加到事务系统中的一个活跃事务列表中。当有读请求需要访问数据时，会首先分配一个ReadView，其中包括当前已分配最大的事务ID，以及当前这个活跃事务列表的一个备份。每当读请求访问数据时，会通过从索引开始的指针访问到这个记录所有的历史版本，通过对比某个历史版本的事务ID和自己ReadView中的活跃事务列表，可以判断是不是需要的版本。然而，这就导致每当有读事务开始时，都需要在整个拷贝过程对这个活跃事务列表加锁，从而阻塞了新的写事务将自己的ID加入。同样写事务和写事务之间也有访问活跃事务列表的冲突。从而活跃事务列表在这里变成一个明显的性能瓶颈，在双十一这种大压力的读写场景下尤为明显。对此，我们将事务系统中的这个活跃事务列表改造成无锁Hash实现，写事务添加ID以及读事务拷贝到ReadView都可以并发进行。大大提升了性能。

全球数据库技术

热缓存技术

双十一对数据库的可用性要求非常高，核心应用在大促期间处于高负载的状态，长时间高负荷的运行不可避免会存在单一节点的故障，如何能快速恢复成为了一个重要的课题。过去的节点故障恢复需要经历相当长的时间的恢复时间，而重启拉起后的系统还需要缓存预热后才能达到最佳访问性能。

PolarDB今年在存储计算分离架构上继续往前迈进一大步，实现了计算和内存的分离。通过将内存缓冲池从计算节点剥离，让计算节点状态最小化 。计算节点重启后可以快速恢复到重启前的状态，避免大量耗时的缓存预热。传统数据库的错误恢复需要检查点开始扫描所有的redo日志、回放日志、事务恢复等步骤，该过程涉及大量磁盘IO、CPU计算等工作量，其时间往往很长。使用了热缓存技术的PolarDB在计算节点崩溃后，需要恢复的是缓存可能处于不一致的状态，如部分尚未修改完成的缓存页面以及内存结构等。而在CPU缓存分离的架构下只需要新的计算节点来根据各种控制信息和redo日志将这些被污染的内存恢复到一致的状态。因为无需重新构建缓存池，修复工作量小。在常规读写负载下，重启后的数据库最大吞吐下降到原来的5%以下，并在200秒后逐渐恢复正常水平，而利用了热缓存技术的实例几乎无任何性能下降。

跨AZ容灾能力

双十一的核心业务必须要能够跨AZ的容灾， PolarDB提供了跨AZ容灾RPO为0的方案。PolarDB 在存储层（PolarStore）提供3副本的同时，还可以通过自研的 X-Paxos 库提供跨节点、跨机房、跨 AZ 级别的数据同步能力，提供 RPO = 0 的容灾解决方案。这个方案利用 PolarDB 经过多年验证的物理复制技术和 X-Paxos 一致性协议库，提供高可靠、低延迟的数据复制技术。相比于 RDS/MySQL 的逻辑日志复制，PolarDB 在节点切换时，受大事务/DDL 的影响更小，RTO 小于1分钟。同时，这个方案在保证数据冗余的同时，尽量减少部署成本。PolarDB 跨AZ版可以部署Leader，Follower 和 Log 节点。其中 Log 节点只记录日志，不参与选主，不存储数据，部署成本相比于现有架构只增加了 active redo log ，显著降低了部署成本。

并行查询增强

双十一不仅是消费者的盛筵， 也是众多卖家的狂欢。 卖家经常需要实时的查询自己的销售数据以及做一些快速的分析。PolarDB拥有查询引擎，在众多场景下能满足一些即时查询的需求，它充分利用硬件多核优势，并基于COST自动选择并行查询引擎，显著提升了查询性能。今年PolarDB在该方向并没有停止脚步，利用并行查询引擎了优化更多的应用场景。在大规格的实例中， 并行的提升效果尤为显著。

在今年， PolarDB的并行查询新增加了众多场景的覆盖， 有联合(Union)子查询的并行优化，扩展并行查询引擎对联合(Union)子查询的支持；派生表(Derived Table)的并行优化；用户自定义临时表的并行优化；Count的并行优化；Limit的并行优化；条件下推优化，减少数据汇总代价；HASH JOIN 的并行优化，同时优化算子和执行的并行度。

除此之外， POLARDB对GROUP BY / Distinct / SEMI-JOIN / 常量表以及包含Window函数的子查询也做了并行优化，通过利用更多的CPU资源， 有效降低了这些场景下的查询耗时。在标准的TPC-H场景下，POLARDB的并行查询框架取得了非常好的表现。

并行schema变更

在阿里的业务中大量的POLARDB承载了超大规模的数据，然而业务的需求是实时变化的。过去对这些大表做DDL会持续数小时甚至数天，如此之高的延迟是难以容忍的。以创建二级索引为例，过高延迟的DDL操作会阻塞后续依赖新索引查询的DML操作。DDL操作会消耗CPU/Memory/IO资源，对业务DML带来一定的影响，因此用户往往在业务低峰期进行schema变更，但是如果不能确保变更在业务低峰期之内完成会对业务的稳定性产生严重的影响。

我们认为大表DDL运行缓慢的根本原因在于传统的DDL操作是针对单核和传统硬盘设计的。随着多核处理器的日益发展和高速存储的普及，DDL的并行化是可以取得非常好的效果的。

Online DDL分为创建临时表扫描拷贝全量数据加上增量应用期间的变更等几个主要阶段。以增加索引为例需要扫描主键所有记录，生成新的二级索引记录，写入磁盘文件中；对所有二级索引记录进行排序，写入磁盘文件；将有序的二级索引记录插入到新的二级索引中。

POLARDB可以对索引树进行并行扫描、并行多路归并的Merge Sort、并行的Bulk Load索引。 在8core32G规格的实例中针对CPU Bound 和 IO Bound的场景分别进行了测试，都可以达到6-13倍的速度提升。

总结

今年的双十一对PolarDB在性能和功能上提出了更高的要求。 PolarDB在并发性能、跨域、弹性以及可用性上都更进了一步，POLARDB不仅承载着整个阿里集团的实时OLTP数据业务，而且在云上为更为广大的客户提供服务。 我们的目标是将云原生的数据库技术普惠所有的企业客户，帮助客户更好的实现业务价值。

原文链接

本文为阿里云原创内容，未经允许不得转载。