点击链接即可下载论文原文

引言

在云原生数据库中，内存和计算资源的强绑定常常让人“进退两难”。一边是内存吃紧导致性能抖动，一边是想扩容却必须连带采购多余的 CPU。对云厂商而言，这种资源绑定同样难以高效调度，尤其在客户请求超大内存实例时，往往受限于单机物理内存上限。

这正是云原生数据库面临的“最后一公里”问题：尽管存储已解耦，内存却仍难以独立弹性扩展。为破解这一结构性瓶颈，阿里云提出 PolarDB 分布式内存池（PolarDB DMP），基于 RDMA 构建分布式内存池，推动计算、内存、存储三层彻底解耦。DMP功能在线上广泛应用于行存、列存、多模态存储及KVCache推理加速等场景，尤其在 KV Cache 池化方面，实现了跨节点弹性调度与远程访问，有效提升推理效率。

PolarDB DMP架构

不过，RDMA 本质仍是网络协议，访问远程内存延迟始终高于本地，且常需数据拷贝，带来读写放大和带宽浪费。为进一步提升性能与简化架构，阿里云团队探索基于 CXL（Compute Express Link）的新路径。这篇荣获 SIGMOD'25 工业赛道最佳论文的《Unlocking the Potential of CXL for Disaggregated Memory in Cloud-Native Databases》，正是对这一技术演进的系统呈现，讲述了 PolarDB DMP 从 RDMA 向 CXL 架构升级的全过程，为构建新一代高弹性、低延迟的内存池打开了新的可能。（获奖详情可见《再获殊荣，阿里云PolarDB数据库蝉联SIGMOD最佳论文奖》）

什么是CXL？

CXL（Compute Express Link）是一种新型高速互连技术，用于主机处理器（如 CPU）与设备（如加速器、内存扩展器）之间的低延迟、高带宽通信。它基于 PCIe 物理层，但在协议层之上引入了更多的内存语义支持，使得设备之间可以更高效地共享和访问内存。与 RDMA 相比，CXL 具备更低延迟和更高带宽优势，并支持原生 load/store 语义，无需中间拷贝，大幅降低了系统设计复杂度。CXL 3.0 的缓存一致性能力也为多节点数据库一致性控制带来新可能。尽管目前主流产品仍以 CXL 1.0 为主，论文中所用的硬件平台已采用由 XConn 提供的全球首款 CXL 2.0 Switch，支持 2TB/s 带宽与 16TB 内存挂载，为系统落地奠定了基础。

RDMA的局限性

尽管 RDMA 架构在推动内存解耦方面发挥了重要作用，但在数据库系统中仍存在明显局限。首先是读写放大问题：数据库以页为单位传输数据，即使只访问一小部分，也需整页加载，造成带宽浪费。在某些场景下，本地缓冲池仅占远程内存 10% 时，RDMA 带宽占用已达 6.9 GB/s，而 CPU 利用率仅为 8.3%，效率失衡显著。其次是恢复效率低。尽管部分数据保留在远端内存，但本地缓冲池元数据在崩溃时会丢失，系统仍需依赖传统的日志重放机制，重新加载并应用大量 redo log，导致恢复流程冗长，难以充分利用远程内存加速。最后是扩展性受限。在多核环境中，RDMA 容易受到 doorbell 寄存器争用和缓存干扰影响，导致 IOPS 无法线性扩展，尤其在超过 32 核时效果显著下降。相比之下，CXL 采用原生 load/store 访问，无需协议栈处理，具备更低复杂度和更优的多核扩展能力。

PolarCXLMem的核心系统设计

PolarCXLMem是PolarDB事务与引擎团队设计的基于CXL的分布式内存池，构建于磐久服务器自研硬件平台之上。CXL 的引入不仅是一次接口替换，更带来了数据库系统设计的根本性革新。在 PolarDB DMP 从RDMA向PolarCXLMem的演进过程中，团队围绕三个关键问题展开深入探索：如何构建基于 CXL 分布式内存池池、如何实现快速的故障恢复机制、以及如何支持多主场景下的高效数据共享。这三个设计支点共同支撑起了 PolarCXLMem 的系统能力，也展现了 CXL 架构在数据库领域的深远潜力。

（1）基于CXL的分布式内存池

PolarCXLMem 是 PolarDB 团队设计的基于 CXL 的分布式内存池，延续了 RDMA 架构的基本思路，但在架构设计上进行了关键性的优化。它的核心理念是将数据库的缓冲池，包括数据页与元数据，全部直接构建在 CXL 内存上，而不再依赖本地 DRAM。相比之下，本地内存仅保留轻量级的变量和事务引擎相关的数据结构。所有数据库实例均通过 CXL Switch 连接到统一的 CXL 内存设备，从而可以像访问本地内存一样高效、透明地访问远程内存，无需协议转换或数据搬运。

在内存分配方面，系统设计了专门的 CXL 内存管理器，用于支持多节点间的隔离分配。各节点在数据库启动时通过 RPC 向管理器请求指定大小的内存，管理器返回对应偏移地址供其使用。整个缓冲池在系统初始化阶段完成预分配，并被划分为多个内存块，每块存放一个数据页及其元数据，通过链表结构记录空闲与使用状态。

事务引擎在访问页面时直接使用返回的指针，无需区分其是否驻留在本地 DRAM 或远程 CXL 内存中，极大程度地保留了现有代码与接口的一致性。这种设计不仅完全消除了本地与远程之间的分层结构，而且在实测中表现出较优的性能，尽管 CXL 内存的访问速度略低于本地 DRAM，但已经足以满足数据库缓冲池对时延和带宽的要求。更重要的是，它彻底避免了传统架构中频繁的数据迁移和读写放大问题，节省了宝贵的带宽资源，也降低了对本地 DRAM 的依赖和成本，使得系统在结构上更加简洁，运行上更为高效。

（2）CXL支持下的快速恢复机制

在传统云原生数据库中，RDMA 架构依赖本地缓冲池进行数据更新，远端内存仅作为数据页缓存。数据库崩溃后，远程缓冲页的元数据随进程一同丢失，系统仍然需要按照传统的恢复流程，读取并应用 redo log 进行恢复，远程内存仅仅作为恢复过程中的I/O加速，整个恢复流程仍然很慢，严重影响系统可用性。由于 RDMA 延迟较高，关键元数据难以放置在远端，进一步限制了恢复机制的效率和设计空间。

PolarCXLMem 的引入突破了这一瓶颈。依托 CXL 内存架构的独立性与持久性，数据库可以将缓冲页与元数据直接保存在 CXL 内存中。即使主机宕机或断电，数据仍可完整保留，为实现“即时恢复”提供了可能。基于此，PolarDB 团队提出 PolarRecv 机制，可在启动时直接扫描 CXL 内存中保留的页面和元数据，重建系统状态。为确保一致性，系统引入一套检测与修复机制，用于处理崩溃过程中的结构异常。关键设计是将页面锁状态一并保存在 CXL 内存中——若页面在崩溃时仍持锁，系统则基于日志回放恢复其内容；若未持锁，说明页面已稳定写入，可直接复用。通过将数据页、元数据和锁状态统一封装为 block 并在恢复阶段自动识别处理，PolarRecv 构建了一个快速、可验证、事务一致的恢复路径。得益于该机制，系统不再依赖漫长的日志回放或缓冲池预热，从根本上加快了恢复流程，也充分释放了 CXL 内存在高可用场景下的持久性与低延迟优势。

（3）CXL内存池上的多主数据共享

除了池化与恢复方面的革新，PolarCXLMem 在云原生多主数据库的数据共享场景中同样展现出巨大潜力。传统 RDMA 架构依赖整页传输实现共享，传输粒度大、带宽消耗高，且存在严重的读写放大问题，难以满足高并发低延迟的共享需求。

PolarCXLMem 支持多个数据库节点在同一 CXL 内存池中就地访问共享页面，避免了数据拷贝。为保障一致性，系统在 CXL 2.0 架构基础上设计了一套轻量级缓存一致性协议。受限于 CXL 3.0 硬件尚未商用，该协议借鉴 PolarDB-MP 架构，引入 Buffer Fusion Server 管理元数据，协调节点间的访问权限。

在这一机制下，节点仅持有页面地址，通过哈希表维护元信息。若访问页面不在本地缓存中，节点通过 RPC 向服务器请求地址。元信息中包含 invalid 与 removal 两个关键标志，分别用于指示缓存失效与页面回收状态。当节点修改页面并释放写锁时，通过 clflush 写回修改，并通知其他节点清除本地缓存。后台线程还会回收长时间未访问的页面，并广播 removal 标志以释放元数据。

该机制使节点可直接在共享内存中访问与更新页面，无需整页拷贝，极大降低了数据同步的粒度与成本。更新时仅需同步被修改的 cache line，带宽占用最小，延迟极低，显著提升了多主架构下的共享效率，充分验证了 CXL 架构在高性能数据库共享访问中的应用潜力。

实验分析

*注：此处仅展示部分场景和负载下的性能结果，更多完整实验分析可参考论文原文。

（1）Pooling场景

在内存池化场景中，下图展示了Sysbench point-select负载下，同一物理机上多个实例共享同一 CXL 内存池。结果显示，RDMA 架构因整页传输导致带宽瓶颈，3 实例时即达到上限（11 GB/s），吞吐量停滞在 110 万 QPS；而 PolarCXLMem 支持就地访问，避免带宽浪费，吞吐量随实例数近线性增长，最高达 360 万 QPS，性能提升至3.3倍，展现出更优的带宽利用率与扩展能力。

（2）Sharing场景

在 PolarDB-MP 多主场景中，下图展示了不同节点数（8/12）和共享比例（20%~100%）下的性能表现。PolarCXLMem 在高共享比例下优势显著：共享比例为 60% 时，8 节点与 12 节点集群性能分别提升 68.2% 与 154.4%；即便在极端的 100% 全共享场景中，仍能带来 34.01% 和 126.09% 的提升，显示出良好的并发处理与一致性能力。

（3）恢复性能

通过模拟数据库进程崩溃，对比不同方案的恢复时间与吞吐恢复速度。在只读负载下，三种方案均能在 2 秒内完成基础恢复，但 PolarRecv 能在 2 秒内恢复 90% 吞吐，而 RDMA 与传统方案分别需 10 秒与 30 秒热启动。在写密集场景中，PolarRecv 仅用 15 秒完成恢复，相比 RDMA 的 73 秒与传统方案的 173 秒，分别提速 4.87 倍与 11.53 倍。

未来展望

这项工作的重要意义并不仅仅在于一次数据库系统架构的升级。它展示了内存资源池化在数据库系统中的可行性与巨大潜力，也预示着未来云原生数据库将全面迈入“计算-内存-存储全面解耦”的时代。随着 CXL 生态逐步成熟，这种新型架构将有望成为云原生数据库的新基石。更重要的是，PolarDB DMP 的价值远不止于传统行存场景。在列存、多模态存储，以及大模型推理中的 KV Cache 池化等新兴领域，它同样展现出广阔前景。未来，PolarDB DMP 有望走出数据库，成为 AI 基础设施中的统一内存底座，实现从数据处理到模型推理的一体化资源管理。