\title{**分布式内存管理**}
\author{杨其臻}
\date{Jun 22, 2026}
\maketitle
在单机系统中，内存管理早已被操作系统与运行时环境封装得近乎透明，开发者只需关注堆栈分配与垃圾回收即可。但当计算规模扩张到数十乃至数百个节点时，原本隐藏在 NUMA 控制器后的带宽与延迟差异会被放大到网络层面，单机内存的容量、带宽与容错能力迅速成为瓶颈。分布式内存管理正是为了跨越这一「内存墙」而生，它既包含狭义上跨节点聚合与共享物理内存的机制，也涵盖广义上的分布式缓存、对象存储、分布式垃圾回收以及持久化内存等技术范畴。本文的目标是为读者提供一条从理论模型到生产实践的完整路径，并给出可落地的评估框架与检查清单。\par
\chapter{背景与挑战}
硬件层面，RDMA 网卡、CXL 总线、NVMe-oF 以及持久性内存 PMem 的出现，让跨节点内存访问在延迟上逐渐接近本地 DRAM，但也带来了全新的语义与功耗问题。软件栈则从传统的 NUMA 感知调度演进为集群级内存池，再进一步走向内存与计算的彻底解耦。这些演进同时放大了若干核心挑战：跨节点缓存一致性协议会引入难以预测的延迟抖动；节点宕机可能导致整块内存数据永久丢失；多租户场景下的地址空间隔离若设计不当，极易造成数据泄露；小对象分配产生的外部碎片会显著降低整体利用率；PCIe 与网卡带宽又往往成为新的瓶颈，使理论加速比难以达到线性。\par
\chapter{分布式内存抽象模型}
在抽象层面，分布式内存系统首先需要在共享内存与消息传递两种范式之间做出权衡。PGAS 模型通过分区全局地址空间让程序员既能像访问本地数组一样读写远程内存，又能显式感知数据局部性。全局虚拟地址空间 GVAS 则进一步把这一概念推广到整个集群，形成统一的虚拟地址映像。内存一致性模型在分布式环境下需要重新映射：顺序一致性要求所有节点看到的写操作顺序完全相同，因果一致性仅保证因果相关的操作顺序，最终一致性则允许短暂的读旧值以换取更高的可用性。这些模型在硬件、系统、编程三个层次上各有体现：CXL 与 PCIe 在硬件层提供缓存一致的内存语义；RMA 原语在系统层暴露单边与双边操作接口；而在编程层，MPI、UPC、Chapel、X10 以及分布式 Rust 分别以不同粒度封装了上述原语。\par
\chapter{远程直接内存访问}
RDMA 是分布式内存管理的基石技术，其核心在于允许网卡在不经过远程 CPU 的情况下直接读写对方内存。标准 Verbs 接口提供了注册、 doorbell 通知与共享接收队列 SRQ 等机制。以一段典型的单边 RDMA 写操作为例：\par
\begin{lstlisting}[language=c]
struct ibv_mr *mr = ibv_reg_mr(pd, buf, size, IBV_ACCESS_LOCAL_WRITE | IBV_ACCESS_REMOTE_WRITE);
struct ibv_send_wr wr = { .wr_id = 1, .opcode = IBV_WR_RDMA_WRITE, .send_flags = IBV_SEND_SIGNALED };
wr.wr.rdma.remote_addr = remote_va;
wr.wr.rdma.rkey = remote_rkey;
ibv_post_send(qp, &wr, &bad_wr);
\end{lstlisting}
这段代码首先通过 \texttt{ibv\_{}reg\_{}mr} 把本地缓冲区注册到保护域，并授予远程写权限；随后构造发送工作请求，将目标远程虚拟地址与远程密钥填入 \texttt{wr.rdma} 字段；最后调用 \texttt{ibv\_{}post\_{}send} 将请求提交到硬件队列。需要注意的是，远程地址与 rkey 必须由对端在连接建立阶段通过带外方式告知，否则会触发远程访问错误。\par
\chapter{分布式共享内存}
在页粒度分布式共享内存 DSM 中，系统将集群内存抽象为一个巨大的共享页表，缺页时通过网络按需拉取远端页面。早期系统如 TreadMarks 与 JIAJIA 采用写时复制与延迟更新协议来降低通信量。对象粒度的 DSM 则进一步把共享单位缩小到语言对象级别，例如 ORCA 通过编译器静态分析对象访问模式，JavaSpaces 则提供基于条目的松耦合共享空间。这些系统都需要在一致性与性能之间反复权衡：页粒度实现简单但容易出现伪共享，对象粒度实现复杂却能获得更高的局部性。\par
\chapter{分布式垃圾回收}
分布式垃圾回收需要在跨节点引用链上建立全局可达性判定。一种常见做法是把本地引用计数与全局标记-清除相结合：本地计数器快速释放无引用对象，全局标记阶段则通过并行遍历所有节点的可达图。为避免全量扫描带来的长时间暂停，系统会采用增量式标记与安全点协调机制。在代码层面，分布式引用计数往往需要为每个对象维护一个远程引用列表，并通过原子操作更新计数：\par
\begin{lstlisting}[language=rust]
fn inc_remote_ref(obj: &DistributedObject, node: NodeId) {
    let mut refs = obj.remote_refs.lock();
    *refs.entry(node).or_insert(0) += 1;
}
\end{lstlisting}
上述 Rust 代码在分布式对象上加锁后，对指定节点的引用计数执行原子递增；对应的递减操作则在远程对象被释放时触发，并可能引发跨节点消息通知。\par
\chapter{内存池与 slab 分配器}
内存池通过预先分配大块连续内存并按对象大小分级，来降低 malloc 的开销。Memcached 的 slab allocator 将内存划分为若干尺寸递增的 slab class，每个 class 内部再用链表管理空闲块。Apache Arrow Plasma 针对列式数据做了进一步优化，引入共享内存与引用计数以支持零拷贝跨进程传递。在分布式场景下，远程 slab 分配协议需要额外处理网络往返与一致性，例如在分配前先向中心协调节点申请令牌，再由本地 slab 满足实际内存布局。\par
\chapter{一致性与缓存协议}
将单机 MESI 协议扩展到分布式环境，需要引入目录协议 DirCC，由中心或分布式目录维护每个缓存行的状态与位置。Lease 机制则允许持有者在租约到期前独占修改，租约续期通过心跳维持；当租约冲突时，Quorum 投票可确保多数派达成一致。以一段伪代码描述 Lease 获取流程：\par
\begin{lstlisting}[language=python]
def acquire_lease(key, duration):
    lease = directory.request_lease(key, duration)
    if lease.granted:
        local_cache[key] = (value, lease.expiry)
    else:
        backoff_and_retry()
\end{lstlisting}
这段代码向目录服务请求带时长的租约，若成功则把值与过期时间一并写入本地缓存；若失败则执行退避重试，避免雪崩效应。\par
\chapter{容错与持久化}
内存快照通过写时复制技术，在不阻塞业务线程的前提下生成一致性镜像。NVM Logging 把事务日志直接写入持久性内存，结合 WAL 与定期 Checkpoint，可在毫秒级恢复窗口内重建内存状态。代码中常见的模式是将关键数据结构标记为「易失」或「持久」，并在事务提交时调用持久化原语：\par
\begin{lstlisting}[language=c]
pmem_persist(&header, sizeof(header));
pmem_drain();
\end{lstlisting}
上述两行代码先调用 \texttt{pmem\_{}persist} 将 header 结构刷入持久域，再调用 \texttt{pmem\_{}drain} 确保平台写缓冲区排空，从而满足持久化内存的事务语义。\par
\chapter{安全与隔离}
在多租户环境中，内存加密与地址空间隔离是防止数据泄露的关键。AMD SEV 与 Intel TDX 在硬件层面为每个虚拟机提供独立的内存加密密钥，MKTME 则允许操作系统为不同进程分配不同密钥。Capability 模型进一步把地址访问权限编码为不可伪造的令牌，只有持有正确 Capability 的代码才能解析对应内存地址，从而在语言运行时层面实现细粒度隔离。\par
\chapter{典型系统剖析}
RAMCloud 通过全内存存储与高速 RDMA 网络实现了微秒级随机访问，其日志结构化设计把磁盘仅作为备份介质。FaRM 把 RDMA 与事务内存结合，采用乐观并发控制与两阶段提交，在高负载下仍能保持低延迟。Gamut 与 Leap 则是 CXL 内存池的早期原型，利用 CXL 2.0/3.0 的内存语义实现跨节点缓存一致。工业界系统如 Alluxio 把内存作为分布式文件系统缓存层，Apache Ignite 与 Hazelcast 提供分布式缓存与计算一体化能力；Google Spanner 的 Tablet Server 在内存中维护锁表与 MVCC 版本链；AWS Lambda SnapStart 则通过 Firecracker 虚拟机级内存快照实现冷启动优化。新兴硬件如 Samsung CXL Memory Module 与 Microsoft Azure HBv4 系列 CXL 内存池，正在把上述技术推向生产环境。\par
\chapter{工程实践 checklist}
容量规划时，经验值建议将内存与网络带宽比例控制在 4:1 至 8:1 之间，以避免网络成为瓶颈。延迟敏感路径应优先使用轮询而非中断，并开启 HugePage 以减少 TLB miss。监控指标需覆盖远程访问延迟 p99、内存碎片率以及分布式 GC 暂停时间。故障演练脚本应覆盖节点 kill、网卡 down 以及内存 ECC 错误等场景，以便验证容错路径的有效性。成本模型则需对比本地 DRAM、分布式内存池与 SSD 在每 GB-month 维度上的综合拥有成本，从而为架构选型提供量化依据。\par
\chapter{未来趋势与研究方向}
存算分离与内存解耦正成为主流方向，CXL 结合 DPU 可在保持缓存一致性的前提下实现内存池的弹性伸缩。持久性内存与分布式事务的结合需要进一步优化 eADR 域与 WAL 落盘路径。AI 训练场景下，分布式 KV Cache 与激活值管理面临新的延迟与显存碎片挑战。安全领域，机密计算、内存加密与远程证明的融合将决定多租户内存池的落地速度。编程模型方面，分布式 Rust 与语言级 DSM 有望把分布式内存语义下沉到类型系统，降低开发者心智负担。\par
分布式内存管理本质是在网络上重新实现单机内存层次结构。给读者的三条落地建议如下：首先在小规模集群上完成 RDMA 原型验证，再评估是否引入 CXL；其次用 Lease 加版本号解决一致性问题，待系统稳定后再逐步引入完整事务；最后建立端到端延迟与带宽预算表，而非仅关注吞吐指标。只有把理论模型、硬件特性和工程约束放在同一张图上，才能在分布式内存这条路上走得更远。\par
