土法炼钢兴趣小组的算法知识备份

【分布式系统百科】新硬件对分布式系统的冲击

2026-04-13 · #CXL #RDMA #SmartNIC #DPU #持久内存 #新硬件 #分布式系统

文章导航

标签入口
#CXL#RDMA#SmartNIC#DPU#持久内存#新硬件#分布式系统

目录

新硬件对分布式系统的冲击

一个 RPC 调用耗时 500 微秒，其中网络往返占了 490 微秒。一次分布式事务需要两轮 RPC，总耗时超过 1 毫秒。为了掩盖这个延迟，工程师不得不引入批处理、异步流水线、预取缓存——系统复杂度因此翻了好几倍。过去三十年，几乎所有分布式系统的设计都建立在一个核心假设之上：网络比本地内存慢三到四个数量级。Shared-Nothing 架构、基于消息传递的一致性协议、Write-Ahead Log 先写磁盘再更新内存——这些经典设计范式都是对硬件约束的妥协。

但硬件正在发生根本性变化。CXL（Compute Express Link）让跨主机内存访问的延迟降到 200 纳秒量级；RDMA（Remote Direct Memory Access）将远程内存读写压缩到 2 微秒以内；SmartNIC 和 DPU（Data Processing Unit）把网络协议栈、存储虚拟化、加密卸载从 CPU 上剥离出去；持久内存（Persistent Memory，PMem）让内存同时具备 DRAM 的速度和磁盘的持久性。这些新硬件不是简单的性能提升——它们正在瓦解分布式系统设计的基本假设。

本文将系统性地梳理这些新硬件技术及其对分布式系统的冲击，分析它们如何改变延迟层级、通信模型、存储语义和计算架构，并讨论工程实践中的权衡取舍。

新硬件全景

一、当网络不再是瓶颈

1.1 传统的延迟层级假设

在经典的分布式系统教科书中，延迟层级大致如下：

操作 典型延迟
L1 缓存访问 ~1 ns
L2 缓存访问 ~4 ns
本地 DRAM 访问 ~100 ns
NVMe SSD 读取 ~10 μs
以太网 RPC（数据中心内） ~500 μs
跨数据中心 RPC ~50 ms

本地内存访问和网络 RPC 之间存在近 5000 倍的差距。这个差距直接塑造了分布式系统的设计哲学：尽量减少网络通信次数，每次通信尽量携带更多数据，本地能做的计算绝不发到远端。Shared-Nothing 架构、数据分区（Partitioning）、本地缓存（Local Cache）、批量写入（Batch Write）——所有这些技术的本质都是在对抗网络延迟。

1.2 新硬件带来的延迟层级重构

新硬件正在压缩这个延迟层级。更新后的表格如下：

操作 典型延迟 变化趋势
本地 DRAM 访问 ~100 ns 基本不变
CXL 远程内存访问 ~200 ns 新增
PMem 持久内存访问 ~300 ns 新增
RDMA 单边读 ~2 μs 新增
NVMe SSD 读取 ~10 μs 持续下降
传统以太网 RPC ~500 μs 基本不变

值得注意的变化是：CXL 远程内存访问只比本地 DRAM 慢两倍，RDMA 只比本地内存慢 20 倍，而传统网络 RPC 比本地内存慢 5000 倍。这不是渐进式的改进，而是数量级的跃迁。

下图展示了传统路径与 RDMA 路径在一次远程数据访问中的延迟分布对比：

flowchart LR
    subgraph Traditional["传统 TCP/IP 路径 (~500us)"]
        A1["应用层<br/>~1us"] --> A2["系统调用<br/>~2us"]
        A2 --> A3["TCP/IP 协议栈<br/>~5us"]
        A3 --> A4["NIC 发送<br/>~1us"]
        A4 --> A5["网络传输<br/>~5us"]
        A5 --> A6["NIC 接收<br/>~1us"]
        A6 --> A7["TCP/IP 协议栈<br/>~5us"]
        A7 --> A8["系统调用<br/>~2us"]
        A8 --> A9["远端应用处理<br/>~478us"]
    end

    subgraph RDMA["RDMA 单边读路径 (~2us)"]
        B1["应用层<br/>Verb 调用"] --> B2["RDMA NIC<br/>硬件处理"]
        B2 --> B3["网络传输<br/>~1us"]
        B3 --> B4["远端 NIC<br/>DMA 读取"]
        B4 --> B5["网络返回<br/>~1us"]
        B5 --> B6["本地 NIC<br/>写入内存"]
    end

传统路径中，操作系统内核的协议栈处理和远端 CPU 的应用层处理占据了绝大部分延迟。RDMA 路径通过内核旁路和远端 CPU 零参与，将端到端延迟压缩到 2 微秒以内。这种差异的根本原因在于 RDMA 将协议处理完全卸载到网卡硬件，消除了软件栈中最耗时的环节。

1.3 假设崩塌的连锁反应

当网络延迟从微秒级降到亚微秒级，一系列传统设计决策需要重新审视：

RPC 的开销结构变了。传统 RPC 中，网络传输延迟占主导，序列化/反序列化的 CPU 开销可以忽略。但当网络延迟降到微秒级甚至亚微秒级时，序列化、系统调用、上下文切换的开销反而成了瓶颈。这就是为什么 RDMA 要绕过内核——不是因为内核慢，而是因为网络快到内核处理延迟已经不可接受。

批处理的收益下降了。批处理的本质是用吞吐量换延迟——把多个小请求合并成一个大请求，摊薄网络往返的开销。当网络往返开销本身就很小时，批处理增加的排队延迟反而成了净损失。

一致性协议的成本结构变了。Paxos 或 Raft 的一次共识需要至少一轮多数派通信。如果每轮通信耗时 500 微秒，一次共识至少要 1 毫秒。但如果用 RDMA，一轮通信只需 2 微秒，共识延迟可以降到 5 微秒量级。这使得很多”因为共识太慢所以放弃强一致性”的设计决策不再成立。

数据放置策略要重新设计。传统系统中，数据要尽量放在计算节点本地，以避免网络访问。但如果 CXL 远程内存只比本地 DRAM 慢两倍，而本地 SSD 要慢 100 倍，那么远程内存反而比本地磁盘更快。数据放置的最优策略完全不同了。

二、CXL：共享内存池的崛起

2.1 CXL 协议概述

CXL（Compute Express Link）是一种基于 PCIe 物理层的开放互连协议，由 Intel 于 2019 年发起，目前由 CXL 联盟（CXL Consortium）管理。CXL 的核心目标是在 CPU、加速器和内存设备之间建立高带宽、低延迟、支持缓存一致性（Cache Coherence）的互连。

CXL 定义了三个子协议：

2.2 CXL 协议的演进

CXL 经历了三个主要版本的演进：

CXL 1.0/1.1（2019-2020）：定义了基本的三个子协议，支持单个主机与单个 CXL 设备之间的互连。Type 1 设备（如 SmartNIC）使用 CXL.io + CXL.cache；Type 2 设备（如 GPU）使用全部三个子协议；Type 3 设备（如内存扩展器）使用 CXL.io + CXL.mem。

CXL 2.0（2020）：引入了交换机（CXL Switch），支持多个主机共享 CXL 设备。这是共享内存池的基础——多台服务器可以通过 CXL 交换机访问同一块 CXL 内存。CXL 2.0 还增加了内存热插拔（Hot-Plug）和持久内存刷新（Persistent Flush）等特性。

CXL 3.0（2022）：支持多级交换（Multi-Level Switching）和 Fabric 拓扑，允许构建更大规模的 CXL 网络。引入了背靠背（Back-to-Back）连接，允许两台主机通过 CXL 直接互连而不需要交换机。最关键的是，CXL 3.0 支持硬件级别的全局缓存一致性（Global Coherence），这意味着跨主机的内存访问可以像本地内存一样保证一致性。

2.3 CXL 内存池化与 Pond 系统

CXL 2.0 及以上版本的核心应用场景是内存池化（Memory Pooling）。传统数据中心中，每台服务器的内存是独立的——一台服务器内存不足时无法借用其他服务器的空闲内存，导致内存利用率通常只有 40%-60%。CXL 内存池允许多台服务器共享一个大的内存池，按需分配，内存利用率可以提升到 80% 以上。

Pond 是 Microsoft Research 在 ASPLOS 2023 发表的 CXL 内存池化系统。Pond 的核心设计包括：

分层内存管理。Pond 将内存分为本地 DRAM（Local DRAM）和 CXL 池化内存（Pooled Memory）两层。操作系统通过 NUMA（Non-Uniform Memory Access）接口管理 CXL 内存，将其视为远端 NUMA 节点。应用程序无需修改代码即可使用池化内存——操作系统的页面迁移（Page Migration）机制会自动在本地和远端之间迁移热数据。

性能隔离。多租户环境中，不同虚拟机共享 CXL 内存池可能导致互相干扰。Pond 通过带宽预留（Bandwidth Reservation）和延迟保证（Latency SLO）实现性能隔离。具体做法是在 CXL 交换机上配置每个端口的带宽上限，并通过监控实际延迟来动态调整分配。

弹性伸缩。虚拟机可以在运行时动态扩展或收缩 CXL 内存。Pond 利用 CXL 2.0 的热插拔机制，允许在不停机的情况下增减 CXL 内存区域。

2.4 CXL 对 Shared-Nothing 假设的冲击

过去三十年，Shared-Nothing 是分布式数据库的主流架构。每个节点独占自己的 CPU、内存和磁盘，节点之间只通过消息传递通信。这种架构的优势是扩展性好、故障隔离性强，但代价是跨节点访问数据必须通过网络 RPC，延迟高、编程复杂。

CXL 提供了第三种选择：Shared-Memory-Pool 架构。多个计算节点共享一个 CXL 内存池，可以像访问本地内存一样访问远端数据。这种架构介于 Shared-Nothing 和传统共享内存（Shared-Everything）之间——计算资源仍然是独立的，但内存是共享的。

考虑以下对比：

// 传统 Shared-Nothing：跨节点读取数据需要 RPC
// 延迟：~500μs（网络往返） + 序列化开销
int value = rpc_read(remote_node, key);

// CXL Shared-Memory-Pool：直接读取共享内存
// 延迟：~200ns（CXL 远程内存访问）
int value = *((int *)(cxl_base_addr + offset));

两种方式的延迟差距超过 2000 倍。更重要的是，CXL 内存访问是通过 load/store 指令完成的，可以利用 CPU 的缓存层级、预取机制和乱序执行能力，而 RPC 需要经过完整的网络协议栈。

这种架构变化对分布式系统的影响是深远的。例如，分布式 B+ 树的跨节点遍历不再需要多次 RPC，而是可以通过指针追踪（Pointer Chasing）直接在 CXL 内存上完成。分布式哈希表的探测（Probing）也可以完全在 CXL 内存侧进行，无需与远端 CPU 交互。

2.5 CXL 的挑战与局限

CXL 并非银弹。当前面临的主要挑战包括：

延迟放大。虽然 CXL 远程内存访问的延迟只有 200 纳秒量级，但在多级交换拓扑下，延迟会逐级累加。CXL 3.0 的多级 Fabric 环境中，跨多个交换机的访问延迟可能超过 500 纳秒。

缓存一致性开销。CXL 3.0 的全局缓存一致性需要跨主机进行嗅探，这在大规模集群中可能成为瓶颈。硬件一致性目录（Coherence Directory）的规模随节点数增长，需要消耗额外的内存和带宽。

故障域扩大。CXL 内存池是共享资源，池中的硬件故障可能影响所有连接的主机。与 Shared-Nothing 架构的故障隔离性相比，CXL 引入了新的故障传播路径。

生态成熟度。截至目前，CXL 3.0 的商用硬件仍在早期阶段。CXL 交换机、CXL 内存控制器的产品化进度参差不齐，软件生态（操作系统支持、驱动、管理工具）也需要时间成熟。

三、RDMA：绕过内核的远程内存访问

3.1 RDMA 基础原理

RDMA（Remote Direct Memory Access）允许一台主机直接读写另一台主机的内存，无需远端 CPU 参与，也无需经过操作系统内核的网络协议栈。RDMA 通过以下机制实现低延迟和高吞吐：

零拷贝（Zero-Copy）。传统网络通信中，数据需要从用户空间拷贝到内核空间，再拷贝到网卡缓冲区。RDMA 通过预注册内存区域（Memory Region，MR），让网卡直接从应用的用户空间内存中读取或写入数据，省去了多次拷贝。

内核旁路（Kernel Bypass）。RDMA 的数据路径完全在用户态完成。应用通过内存映射（mmap）直接操作网卡的硬件队列（Work Queue），发送请求不需要系统调用。这避免了系统调用的上下文切换开销（约 2-5 微秒）。

硬件协议卸载。RDMA 的传输协议完全由网卡硬件实现，包括分片、重传、流控、拥塞控制等。CPU 不需要参与协议处理。

RDMA 有三种主要的传输技术：

3.2 RDMA 编程模型：Verbs API

RDMA 的编程模型基于 Verbs API，核心概念包括队列对（Queue Pair，QP）、完成队列（Completion Queue，CQ）和内存区域（Memory Region，MR）。

RDMA 操作分为两类：

双边操作（Two-Sided Operations）：send/recv。发送方调用 send，接收方必须预先 post 一个 recv 请求。双边操作需要双方 CPU 都参与，语义类似传统的消息传递。

单边操作（One-Sided Operations）：read/write/atomic。发送方直接读写远端内存，远端 CPU 完全不参与。发送方只需要知道远端内存的虚拟地址和远程密钥（Remote Key，rkey）。单边操作是 RDMA 的核心优势——远端 CPU 可以完全不知道有人在访问它的内存。

以下是 RDMA 单边 read 操作的伪代码：

// 初始化：注册本地内存区域
struct ibv_mr *local_mr = ibv_reg_mr(pd, local_buf, buf_size,
    IBV_ACCESS_LOCAL_WRITE);

// 构造 RDMA Read 请求
struct ibv_sge sge = {
    .addr   = (uintptr_t)local_buf,
    .length = read_size,
    .lkey   = local_mr->lkey
};

struct ibv_send_wr wr = {
    .wr_id      = request_id,
    .sg_list    = &sge,
    .num_sge    = 1,
    .opcode     = IBV_WR_RDMA_READ,
    .send_flags = IBV_SEND_SIGNALED,
    .wr.rdma = {
        .remote_addr = remote_addr,  // 远端内存地址
        .rkey        = remote_rkey   // 远端内存区域密钥
    }
};

// 发起 RDMA Read（无系统调用，直接写硬件队列）
ibv_post_send(qp, &wr, &bad_wr);

// 轮询完成队列等待结果
struct ibv_wc wc;
while (ibv_poll_cq(cq, 1, &wc) == 0) {
    // 忙等待，延迟约 2μs
}
// 此时 local_buf 已包含远端内存的数据

3.3 FaRM：RDMA 驱动的分布式事务

FaRM 是 Microsoft Research 在 NSDI 2014 和 SOSP 2015 上发表的 RDMA 分布式计算平台。FaRM 的核心贡献是展示了如何利用 RDMA 的单边操作构建高性能分布式事务系统。

无锁远程读。FaRM 的分布式事务在读取阶段使用 RDMA 单边 read，完全不需要与远端 CPU 交互。为了保证读一致性，FaRM 在每个对象头部维护一个版本号（Version Number）。读取过程是：

  1. 通过 RDMA Read 读取对象（包括头部的版本号）；
  2. 检查版本号的锁定位（Lock Bit）——如果被锁定，说明有并发写入，重试；
  3. 在事务提交时，再次检查版本号是否变化——如果变化了，说明数据在读取后被修改，事务中止。

这种方式被称为乐观并发控制（Optimistic Concurrency Control，OCC）——读阶段不加锁，提交时验证。

基于 RDMA Write 的两阶段提交。FaRM 的事务提交使用了定制的两阶段提交（2PC）协议：

整个提交过程中，只有 Commit Primary 阶段需要远端 CPU 参与（轮询日志并应用修改），其他阶段全部通过单边 RDMA 操作完成。FaRM 在 90 台服务器的集群上实现了每秒 1.4 亿次事务的吞吐量。

下图展示了 FaRM 中一次 RDMA 驱动的分布式事务从读取到提交的完整序列：

sequenceDiagram
    participant C as 协调者
    participant P1 as 主节点 A
    participant P2 as 主节点 B
    participant Bk as 备份节点

    Note over C,Bk: 阶段一：执行（乐观读取）
    C->>P1: RDMA Read（读取对象 + 版本号）
    C->>P2: RDMA Read（读取对象 + 版本号）
    P1-->>C: 数据 + version=5
    P2-->>C: 数据 + version=3

    Note over C,Bk: 阶段二：Lock
    C->>P1: RDMA Write（写 LOCK 日志）+ CAS 锁定 version
    C->>P2: RDMA Write（写 LOCK 日志）+ CAS 锁定 version
    P1-->>C: CAS 成功
    P2-->>C: CAS 成功

    Note over C,Bk: 阶段三：Validate
    C->>P1: RDMA Read（重新验证读集版本号）
    P1-->>C: version 未变化

    Note over C,Bk: 阶段四：Commit Backup
    C->>Bk: RDMA Write（写 COMMIT-BACKUP 日志）
    Bk-->>C: 写入完成

    Note over C,Bk: 阶段五：Commit Primary
    C->>P1: RDMA Write（写 COMMIT-PRIMARY 日志）
    C->>P2: RDMA Write（写 COMMIT-PRIMARY 日志）
    Note over P1,P2: 后台线程轮询日志，应用修改，释放锁

    Note over C,Bk: 阶段六：Truncate
    C->>P1: RDMA Write（截断日志）
    C->>P2: RDMA Write（截断日志）
    C->>Bk: RDMA Write（截断日志）

这个序列的关键在于：除了 Commit Primary 阶段由远端后台线程轮询处理外，所有交互均为 RDMA 单边操作，远端 CPU 完全不参与。CAS（Compare-and-Swap）原子操作用于无锁地锁定写集对象，避免了传统分布式锁的开销。整个事务在 RDMA 网络上的端到端延迟仅为数十微秒量级。

3.4 DrTM：RDMA 与硬件事务内存的结合

DrTM 是清华大学在 SOSP 2015 上发表的分布式事务系统。DrTM 的核心创新是将 RDMA 与硬件事务内存（Hardware Transactional Memory，HTM）结合，用于构建高性能分布式事务。

HTM 是 Intel TSX（Transactional Synchronization Extensions）等 CPU 扩展提供的功能。它允许程序员将一段代码标记为事务，CPU 硬件自动保证事务的原子性和隔离性——如果事务执行期间检测到冲突（其他 CPU 核心修改了事务读集中的缓存行），硬件自动回滚事务并通知软件重试。

DrTM 的设计思路是：

DrTM 在 TPC-C 基准测试上展示了显著的性能优势：在 6 台服务器的集群上，DrTM 的吞吐量达到了每秒 580 万次 New-Order 事务，约为同期 Silo（单机事务系统）的 5 倍。

3.5 基于 RDMA 的共识协议

RDMA 也在改变共识协议的设计。传统 Paxos/Raft 的每一轮共识需要 Leader 向多数派发送消息并等待回复，涉及至少两次网络往返（Prepare + Accept 或 AppendEntries + 回复）。

NSDI 2016 上的工作展示了如何利用 RDMA 将 Paxos 优化到一轮网络往返（1 RTT）。核心思路是：Leader 通过 RDMA Write 直接将提案写入每个 Follower 的日志区域，然后通过 RDMA Read 读取 Follower 的响应区域来确认写入是否成功。由于 RDMA Write 和 Read 都是单边操作，Follower 的 CPU 不需要参与——Follower 只需要预先注册好内存区域即可。

这种方法将共识延迟从传统以太网上的毫秒级降低到 RDMA 网络上的个位数微秒级。

3.6 RDMA 的工程挑战

RDMA 虽然性能优秀，但在工程实践中面临多个挑战：

队列对（QP）状态的可扩展性问题。每个 RDMA 连接需要一个 QP，每个 QP 在网卡上维护大量状态（发送/接收队列、序列号、拥塞控制参数等）。当连接数增长到数千甚至数万时，网卡上的 SRAM 无法容纳所有 QP 状态，必须将部分状态换出到主机内存，导致性能急剧下降。这被称为 QP 可扩展性问题（QP Scalability Problem）。解决方案包括连接共享（Connection Sharing）、动态连接（Dynamic Connected Transport，DCT）等。

拥塞控制。RoCE v2 运行在无损以太网（Lossless Ethernet）上，依赖 PFC（Priority Flow Control）进行流控。PFC 的问题是它以端口为粒度进行流控——当一个队列拥塞时，PFC 会暂停整个端口的所有流量，导致无辜流量也被阻塞。这种现象被称为 PFC 风暴（PFC Storm），在生产环境中是 RoCE 部署的主要运维难题。DCQCN（Data Center QCN）等端到端拥塞控制算法试图缓解这个问题，但效果仍然有限。

内存注册开销。RDMA 要求通信双方预先注册内存区域（Memory Region），注册过程需要将虚拟地址映射到物理地址并固定页面（Pin Pages），防止操作系统换出。这个过程的开销不小，且固定的内存无法被操作系统交换，增加了内存压力。

编程复杂度。RDMA 的 Verbs API 远比 Socket API 复杂。开发者需要手动管理 QP、CQ、MR 的生命周期，处理异步完成事件，应对网卡固件的各种限制和 bug。调试工具也远不如传统网络成熟。

四、SmartNIC 与 DPU：网络处理的卸载

4.1 从网卡到可编程处理器

传统网卡（NIC）是一个简单的数据搬运工——把以太网帧从网线搬到主机内存，或者从主机内存搬到网线。TCP/IP 协议栈、应用逻辑、安全策略——所有处理工作都由主机 CPU 完成。

SmartNIC（智能网卡）在传统网卡的基础上增加了可编程的处理能力。早期 SmartNIC 主要提供固定功能的卸载引擎（Offload Engine），例如 TCP 校验和计算（Checksum Offload）、TCP 分段卸载（TSO，TCP Segmentation Offload）、虚拟化网络卸载（VXLAN/GRE 封装解封装）。这些功能由专用硬件实现，性能高但灵活性差——只能做预定义的操作。

新一代 SmartNIC 的可编程性大幅增强。它们通常集成了通用处理器核心（如 ARM Cortex-A 系列）、可编程的数据包处理流水线（如 P4 可编程交换芯片）、硬件加速器（如加解密引擎、正则表达式匹配引擎、压缩/解压引擎）和大量的板载内存（DRAM 和 HBM）。这类设备已经超越了”智能网卡”的范畴，业界开始使用 DPU（Data Processing Unit，数据处理单元）来称呼它们。

4.2 主要 DPU 产品

NVIDIA BlueField。BlueField 系列是目前市场上最成熟的 DPU 产品。BlueField-2 集成了 8 个 ARM Cortex-A72 核心、ConnectX-6 Dx 网络引擎（支持 200Gbps 以太网和 RDMA）、硬件加速器（IPsec、TLS、正则表达式、数据压缩）和 16GB DDR4 内存。BlueField-3 进一步升级到 16 个 ARM Cortex-A78 核心和 400Gbps 网络。BlueField 运行完整的 Linux 操作系统，可以部署容器和虚拟机。

AMD Pensando。Pensando（被 AMD 收购）的 DSC（Distributed Services Card）系列专注于可编程数据面。其核心是 P4 可编程的数据包处理引擎，支持灵活的流表匹配和动作执行。Pensando 的设计哲学是”可编程性优先”——尽可能多的功能通过 P4 程序定义，而非固化在硬件中。

Intel IPU（Infrastructure Processing Unit）。Intel 的 IPU 方案强调与 x86 生态的集成。Mount Evans IPU 采用 Intel 的 FPGA 技术，提供高度可定制的数据面处理能力，同时集成了 Xeon 处理器核心用于控制面逻辑。

4.3 AWS Nitro：DPU 的生产验证

AWS Nitro 是 DPU 在大规模生产环境中最成功的案例。Nitro 的设计理念是将虚拟化基础设施的所有”税收”——网络虚拟化、存储虚拟化、安全隔离、监控——从客户 EC2 实例的 CPU 上卸载到专用的 Nitro 卡上。

Nitro 系统由三类专用硬件组成：

Nitro Card for Networking。处理所有网络功能：VPC（Virtual Private Cloud）网络、安全组（Security Group）规则匹配、弹性网络接口（ENI）、Elastic Load Balancing 的部分逻辑。传统 Xen 虚拟化中，这些功能运行在 Dom0 的软件协议栈中，消耗大量 CPU 周期。

Nitro Card for EBS。处理 EBS（Elastic Block Store）卷的 I/O 路径：加密/解密、远程存储协议、I/O 调度。EBS 卷的数据在传输和存储时都经过 AES-256 加密，加解密由 Nitro 卡的硬件加速器完成。

Nitro Security Chip。负责硬件信任根（Hardware Root of Trust），确保固件完整性，防止主机 CPU 上的任何软件（包括管理程序）访问客户虚拟机的内存。

Nitro 的工程效果是显著的：早期 EC2 实例需要将多达 30% 的 CPU 资源用于虚拟化开销，Nitro 将这部分开销卸载到专用硬件后，客户可以使用几乎全部的 CPU 资源运行自己的工作负载。这也使得 AWS 能够提供”裸金属”（Bare Metal）实例——客户直接运行在物理硬件上，无虚拟化开销，同时仍然受 Nitro Security Chip 的安全保护。

4.4 KV-Direct：SmartNIC 上的键值存储

KV-Direct 是 Microsoft Research 在 SOSP 2017 上发表的系统，展示了如何在 FPGA-based SmartNIC 上实现高性能键值存储（Key-Value Store）。KV-Direct 的核心思想是把键值操作完全卸载到 SmartNIC 上——键值对存储在主机内存中，但所有的查找、插入、删除操作由 SmartNIC 上的 FPGA 逻辑执行。主机 CPU 完全不参与。

KV-Direct 的数据路径是：

  1. 客户端通过 RDMA Send 将键值操作请求发送到 SmartNIC；
  2. SmartNIC 上的 FPGA 解析请求，计算哈希值；
  3. FPGA 通过 PCIe DMA 读取主机内存中的哈希表桶（Hash Bucket）；
  4. 如果找到目标键，通过 PCIe DMA 读取或写入对应的值；
  5. FPGA 通过 RDMA Send 将结果返回给客户端。

整个过程中主机 CPU 完全空闲。KV-Direct 在单个 SmartNIC 上实现了 1.22 亿次/秒 的 GET 操作和 0.78 亿次/秒 的 PUT 操作（小值场景），这个吞吐量超过了同时期基于 CPU 的高性能 KV 存储（如 MICA）。

4.5 可编程网络与共识卸载

SmartNIC 和可编程交换机的出现催生了一个新的研究方向：将分布式系统的核心逻辑（如共识协议）卸载到网络设备上执行。

NetPaxos 利用可编程交换机（P4 交换机）在数据包转发的过程中同时执行 Paxos 协议的部分逻辑。具体来说，交换机在转发提案消息时，同时在本地维护 Acceptor 状态并进行投票。由于交换机处理数据包的延迟在纳秒级别（远低于服务器上的软件处理），NetPaxos 将共识延迟降低了一个数量级。

这种”网内计算”（In-Network Computing）的范式有一个本质优势：数据包无论如何都要经过交换机，在转发的同时”顺便”做一些计算，不增加额外的延迟。但挑战也很明显——P4 交换机的计算模型受限于匹配-动作（Match-Action）流水线，只能处理简单的逻辑，复杂的应用逻辑仍然需要在服务器上执行。

4.6 DPU 的架构影响

DPU 对分布式系统架构的影响体现在”关注点分离”（Separation of Concerns）：

这种分离的好处不仅是性能——它还提供了更强的安全隔离。DPU 上的安全策略对主机 CPU 上的软件是透明且不可篡改的。即使主机操作系统被攻破，DPU 上的安全策略仍然有效。

在分布式系统的语境下，DPU 使得以下设计成为可能：

五、NVM 与持久内存：存储层的革命

5.1 Intel Optane DC Persistent Memory

Intel Optane DC Persistent Memory（PMem）是基于 3D XPoint 技术的持久内存产品，于 2019 年随 Intel 第二代 Xeon Scalable 处理器发布。PMem 的物理形态是标准 DDR4 DIMM，直接插在内存总线上，通过 CPU 的内存控制器访问。

PMem 的核心特性包括：

字节寻址（Byte-Addressable）。与传统 SSD 的块设备接口不同，PMem 支持字节粒度的读写，应用程序可以通过 load/store 指令直接访问 PMem 上的数据。

非易失性（Non-Volatile）。PMem 上的数据在断电后不会丢失。这意味着 PMem 同时具备 DRAM 的访问方式和磁盘的持久性。

大容量。单条 PMem DIMM 的容量可达 512 GB，远大于同期 DRAM 的单条容量（通常 32-128 GB）。一台双路服务器最多可以安装 6 TB 的 PMem。

PMem 有两种工作模式：

Memory Mode（内存模式）。PMem 作为主内存使用，本地 DRAM 作为 PMem 的缓存。应用程序无需修改代码即可使用更大的内存空间。但在这种模式下，PMem 的持久性被放弃——数据仍然是易失的。

App Direct Mode（应用直接模式）。PMem 作为持久存储暴露给应用程序。应用通过 DAX（Direct Access）文件系统直接 mmap PMem，通过 load/store 指令读写。在这种模式下，应用可以利用 PMem 的持久性，但需要自己保证崩溃一致性（Crash Consistency）。

5.2 PMem 对 Write-Ahead Log 的影响

Write-Ahead Log（WAL）是几乎所有数据库和分布式系统保证持久性和崩溃恢复的核心机制。WAL 的基本原理是：在修改内存中的数据之前，先将修改记录写入持久化的日志文件。如果系统崩溃，可以通过重放日志恢复到崩溃前的状态。

传统系统中的 WAL 流程：

  1. 将修改操作序列化为日志记录；
  2. 将日志记录写入磁盘（或 SSD）并调用 fsync 确保持久化；
  3. 更新内存中的数据结构。

这个流程的瓶颈在于步骤 2——即使使用 NVMe SSD，fsync 的延迟也在 10 微秒级别，且写放大（Write Amplification）严重。

PMem 从根本上改变了 WAL 的设计空间：

场景一：WAL 放在 PMem 上。日志写入的延迟从 SSD 的 10 微秒降到 PMem 的 300 纳秒。更重要的是，PMem 支持字节粒度写入，不需要对齐到 SSD 的页面（通常 4 KB），消除了写放大。持久化操作从 fsync 系统调用变成了 clflush/clwb 指令（将 CPU 缓存行刷到 PMem），开销小得多。

场景二：数据结构本身放在 PMem 上。如果数据结构直接存储在 PMem 上，修改操作本身就是持久的——不再需要 WAL。数据结构的每次更新通过 clflush/clwb 指令原地持久化，省去了日志写入和日志重放的开销。

但场景二引入了一个新问题：崩溃一致性。CPU 的缓存和存储缓冲区（Store Buffer）可能重排写入顺序——程序中先写的数据可能后于后写的数据到达 PMem。如果在部分写入持久化后系统崩溃，PMem 上的数据结构可能处于不一致状态。

5.3 PMem 数据结构与崩溃一致性

为了保证崩溃一致性，PMem 编程需要显式控制写入的持久化顺序。Intel 提供了以下 CPU 指令：

基于这些原语，PMem 数据结构的典型更新模式是：

#include <libpmemobj.h>

// 使用 libpmemobj 的事务接口更新 PMem 数据结构
TX_BEGIN(pop) {
    // 在事务内部修改持久内存中的数据
    // libpmemobj 自动记录 undo log

    // 分配持久内存节点
    TOID(struct tree_node) new_node = TX_NEW(struct tree_node);
    D_RW(new_node)->key = 42;
    D_RW(new_node)->value = 100;

    // 修改已有节点的指针
    TX_ADD_FIELD(parent, child);
    D_RW(parent)->child = new_node.oid;

} TX_ONABORT {
    // 事务中止时，libpmemobj 自动回滚所有修改
    fprintf(stderr, "transaction aborted\n");
} TX_END

FPTree（VLDB 2016）是一种 PMem 优化的 B+ 树。FPTree 的设计思路是：

FPTree 的叶子节点使用 fingerprint（键的哈希值的一个字节）来加速键的查找——先比较 fingerprint，只有 fingerprint 匹配时才比较完整的键。这减少了 PMem 上的随机访问次数。叶子节点内部使用无序存储，插入时追加到空闲位置，用一个 bitmap 标记哪些位置有效。这种设计避免了排序插入时的数据搬移，减少了 PMem 的写入量。

BzTree（VLDB 2018）是另一种 PMem 优化的 B+ 树。BzTree 的创新点是使用 PMwCAS（Persistent Multi-Word Compare-and-Swap）原语来实现无锁的节点修改。PMwCAS 允许原子地修改 PMem 上的多个字段，同时保证崩溃一致性。BzTree 的所有节点（包括内部节点）都存储在 PMem 上，无需重建。

5.4 PMem 编程框架

Intel 提供了 PMDK（Persistent Memory Development Kit）作为 PMem 编程的标准框架。PMDK 包含多个库：

以下是使用 libpmem 实现简单的持久化写入的代码示例：

#include <libpmem.h>
#include <string.h>
#include <stdio.h>

int main(int argc, char *argv[]) {
    char *pmemaddr;
    size_t mapped_len;
    int is_pmem;

    // 将持久内存文件映射到地址空间
    pmemaddr = pmem_map_file("/mnt/pmem0/myfile",
                              4096,                // 文件大小
                              PMEM_FILE_CREATE,     // 不存在则创建
                              0666,                 // 文件权限
                              &mapped_len,
                              &is_pmem);

    if (pmemaddr == NULL) {
        perror("pmem_map_file");
        return 1;
    }

    // 写入数据到持久内存
    const char *data = "persistent data";
    if (is_pmem) {
        // 使用优化的持久内存拷贝（自动执行 clwb + sfence）
        pmem_memcpy_persist(pmemaddr, data, strlen(data) + 1);
    } else {
        // 回退到普通拷贝 + msync
        memcpy(pmemaddr, data, strlen(data) + 1);
        pmem_msync(pmemaddr, strlen(data) + 1);
    }

    printf("data persisted: %s\n", pmemaddr);

    pmem_unmap(pmemaddr, mapped_len);
    return 0;
}

5.5 Optane 的终结与经验教训

2022 年 7 月，Intel 宣布停产 Optane 产品线。这一决定震动了整个持久内存研究社区——大量基于 Optane PMem 的学术研究和工业应用失去了硬件基础。

Optane 停产的原因是多方面的：

市场规模不足。PMem 的目标场景——需要超大内存但又需要持久性的工作负载——市场规模有限。大多数应用要么使用标准 DRAM + SSD 的组合就能满足需求，要么直接使用大容量 DRAM。

成本竞争力下降。随着 DRAM 价格持续下降和容量持续增长，PMem 的成本优势逐渐消失。同时，NVMe SSD 的延迟也在持续降低（新一代 SSD 的读延迟已经降到 3 微秒以内），进一步压缩了 PMem 的市场空间。

编程复杂度高。PMem 编程要求开发者理解 CPU 缓存层级、写入排序、崩溃一致性等底层细节。大多数应用开发者不愿意为了一个特定硬件学习如此复杂的编程模型。

Optane 的终结为新硬件采纳提供了一个重要教训：硬件创新的成功不仅取决于技术本身，还取决于生态系统的成熟度、市场规模和编程模型的易用性。即使技术本身是优秀的，如果软件生态跟不上，或者市场规模不足以支撑持续投入，硬件产品仍然可能失败。

不过，PMem 的学术遗产是持久的。围绕 PMem 发展出来的崩溃一致性理论、持久数据结构设计范式、混合 DRAM/PMem 内存管理技术，在 CXL 内存和未来的新型非易失内存（如 STT-MRAM）上仍然适用。

六、新硬件如何改变分布式系统的基本假设

前面四节分别介绍了 CXL、RDMA、SmartNIC/DPU 和 PMem 这四类新硬件。本节将从更高的视角，分析它们如何共同改变分布式系统的基本假设。

6.1 假设一：网络是慢的

传统假设：网络延迟比本地内存慢 3-4 个数量级（100 纳秒 vs 500 微秒），因此系统设计必须最小化网络往返次数。

新现实：RDMA 将远程内存访问延迟压缩到 2 微秒，CXL 进一步降到 200 纳秒。网络延迟与本地内存访问的差距从 5000 倍缩小到 2-20 倍。

设计影响：

6.2 假设二：内存是易失的

传统假设：DRAM 掉电数据丢失，因此必须通过 WAL + fsync 保证持久性。每次写操作至少涉及一次磁盘或 SSD 写入。

新现实：PMem 和未来的非易失内存技术提供字节寻址的持久存储，延迟仅为 SSD 的 1/30。

设计影响：

6.3 假设三：CPU 处理一切

传统假设：所有的计算——应用逻辑、网络协议栈、存储驱动、安全策略——都由主机 CPU 执行。

新现实：SmartNIC/DPU 将基础设施逻辑从 CPU 卸载到专用硬件，主机 CPU 只运行应用逻辑。

设计影响：

6.4 假设四：Shared-Nothing 是唯一可行的架构

传统假设：由于网络延迟高，共享存储/共享内存的架构在扩展性上不可行。每个节点必须独占自己的资源，通过消息传递通信。

新现实：CXL 3.0 支持跨主机的缓存一致共享内存，延迟仅为本地内存的 2 倍。这使得共享内存池（Shared Memory Pool）架构在技术上可行。

设计影响：

6.5 硬件-软件协同设计原则

上述四类新硬件的共同启示是：分布式系统设计不能脱离硬件特性。“硬件无关”（Hardware-Agnostic）的系统设计在性能敏感的场景下越来越不可行。硬件-软件协同设计（Hardware-Software Co-design）正在成为主流方法论。

协同设计的核心原则包括：

感知硬件特性。系统软件必须感知底层硬件的性能特征（延迟、带宽、原子性保证等），并据此调整数据结构和算法。例如，RDMA 的原子操作粒度是 8 字节，基于 RDMA 的锁设计必须考虑这个约束。CXL 的缓存一致性粒度是 64 字节缓存行，基于 CXL 的共享数据结构必须注意伪共享（False Sharing）问题。

分层卸载。将不同层次的功能卸载到最适合的硬件上执行：网络处理卸载到 SmartNIC/DPU，数据持久化利用 PMem 的字节寻址能力，远程数据访问使用 RDMA 绕过内核。每一层的设计都要考虑该层硬件的约束和能力。

渐进式适配。不要试图一次性利用所有新硬件特性。先在最大的性能瓶颈上引入新硬件（例如先用 RDMA 替换关键路径上的 RPC），验证效果后再逐步扩展。保留回退到传统方案的能力——当新硬件的行为不符合预期，或者在特定场景下性能反而下降时，能够切回传统方案。

6.6 新的研究方向

新硬件催生了一系列新的研究方向：

CXL-aware 分布式数据结构。如何设计能够充分利用 CXL 共享内存的分布式索引、哈希表、队列？CXL 内存的 NUMA 特性（延迟取决于拓扑距离）如何影响数据放置？

RDMA-native 共识协议。如何设计从一开始就假设 RDMA 可用的共识协议，而不是在传统协议上”贴补丁”？单边 RDMA 操作的语义与传统消息传递不同，协议设计的起点也不同。

异构计算的编程模型。当计算分布在 CPU、DPU、GPU、FPGA 上时，如何提供统一的编程模型？当前每种设备有自己的编程接口（RDMA Verbs、CUDA、P4、Verilog/HLS），开发者需要同时掌握多种技能。

新型容错机制。CXL 内存池引入了新的故障模型——内存池故障影响所有连接的主机。如何在共享资源的环境下实现高效的容错？

七、实践指南：新硬件的工程权衡

7.1 何时采用新硬件

新硬件不是万能的。以下场景适合引入新硬件：

延迟敏感的关键路径。如果系统的 P99 延迟受限于网络 RPC 或磁盘 I/O，RDMA 或 PMem 可以提供数量级的改进。典型场景包括实时交易系统、在线推荐引擎的模型服务、分布式数据库的事务提交路径。

CPU 成为瓶颈。如果 CPU 的大部分时间花在网络协议栈、加解密、压缩等非业务计算上，DPU 卸载可以释放 CPU 资源。AWS Nitro 的成功表明，在虚拟化环境中 DPU 卸载的收益是确定的。

内存利用率低。如果数据中心的内存利用率低于 50%，CXL 内存池化可以显著提高资源效率。微软的研究表明，CXL 内存池化可以将内存利用率从 50% 提升到 80% 以上。

以下场景不建议盲目引入新硬件：

吞吐量导向而非延迟导向的系统。批处理系统（如 MapReduce、Spark）的瓶颈通常在于数据规模而非单次操作延迟。RDMA 的低延迟优势在这类场景中收益有限。

已经足够快的系统。如果现有系统的延迟已经满足 SLA 要求，引入新硬件只会增加运维复杂度而不会带来用户可感知的改进。

小规模部署。新硬件通常需要专用的网络设备（如 InfiniBand 交换机、CXL 交换机）和运维技能。小规模部署下，这些固定成本无法摊薄。

7.2 部署复杂度与运维考量

新硬件的部署远比软件升级复杂：

网络基础设施。RDMA（尤其是 RoCE v2）对网络环境有严格要求：无损以太网需要配置 PFC 和 ECN；交换机需要支持特定的缓冲区管理策略；网络拓扑需要保证低延迟的路径。PFC 风暴是 RoCE 部署中最常见的运维问题——一个配置错误可能导致整个交换域的网络瘫痪。

固件管理。SmartNIC/DPU 运行自己的固件和操作系统，需要独立的固件更新、配置管理和监控。固件 bug 可能导致难以诊断的系统行为异常。

调试工具缺乏。新硬件的调试工具远不如传统 CPU/网络成熟。RDMA 的错误信息通常很不直观（一个含糊的状态码），CXL 的性能分析工具还处于早期阶段。

人才储备。掌握 RDMA 编程、PMem 编程、DPU 开发的工程师比传统软件工程师稀缺得多。团队的技术栈切换需要大量的学习和实践投入。

7.3 供应商锁定风险

Optane 的停产为整个行业敲响了警钟。依赖单一供应商的专用硬件存在重大风险：

降低供应商锁定风险的策略包括：

抽象层隔离。在应用与硬件之间引入抽象层。例如，不要直接使用 RDMA Verbs API，而是通过 libfabric 等抽象层编程，以便在 InfiniBand、RoCE、iWARP 之间切换。

保留回退路径。关键系统应该能够在没有新硬件的情况下继续运行（可能性能下降但功能不受影响）。例如，RDMA 路径失败时自动降级到 TCP 通信。

关注开放标准。CXL 作为开放标准，由多家厂商（Intel、AMD、ARM、Samsung、SK Hynix 等）共同推进，供应商锁定风险较低。相比之下，依赖某一家厂商的专有实现风险更高。

7.4 渐进式采纳策略

对于大多数团队，建议采用渐进式策略引入新硬件：

第一阶段：评估与原型。在实验环境中部署新硬件，使用代表性工作负载进行基准测试。确认性能改进是否符合预期，识别潜在的运维挑战。这个阶段的目标是建立团队的技术认知和实践经验，而不是投入生产。

第二阶段：关键路径优化。在生产环境中选择一个延迟最敏感的路径（如数据库的事务提交路径），用新硬件替换。保留回退到传统方案的能力。通过 A/B 测试量化改进效果。

第三阶段：架构演进。在第二阶段验证成功后，逐步扩大新硬件的使用范围。从单点优化扩展到架构级变化——例如从 Shared-Nothing 演进到 Shared-Memory-Pool，或者将基础设施层全面卸载到 DPU。

第四阶段：下一代系统。从零开始设计面向新硬件的系统——不是在现有系统上”贴补丁”，而是在系统架构的起点就考虑新硬件的特性。FaRM、DrTM 等系统就是这种”从零设计”的典范。

7.5 成本分析框架

引入新硬件的决策需要全面的成本分析。以下是一个简化的分析框架：

硬件成本。包括网卡/DPU 本身的采购成本、配套的交换机和线缆成本、机架空间和电力成本。InfiniBand HDR（200Gbps）网卡的价格约为 RoCE 网卡的 3-5 倍，InfiniBand 交换机更是远贵于以太网交换机。

运维成本。包括固件管理、配置管理、故障排查、性能调优的人力成本。新硬件的运维经验需要时间积累，早期的故障排查时间通常远超预期。

开发成本。包括学习新编程模型、重构现有代码、开发测试工具的时间和人力。RDMA 编程的学习曲线陡峭，一个有经验的网络程序员通常需要 3-6 个月才能熟练掌握 RDMA Verbs API。

机会成本。投入在新硬件上的资源如果用于优化现有软件栈，可能也能带来显著的性能提升。在决定引入新硬件之前，应该先确认软件层面的优化空间已经穷尽。

风险成本。供应商停产、技术路线变更、人才流失等风险都需要量化评估。Optane 的教训表明，这些风险不是理论上的——它们确实会发生。

参考文献

  1. A. Dragojević, D. Narayanan, O. Hodson, and M. Castro. “FaRM: Fast Remote Memory.” NSDI, 2014. https://www.usenix.org/conference/nsdi14/technical-sessions/dragojevi%C4%87

  2. CXL Consortium. “Compute Express Link Specification.” https://www.computeexpresslink.org/

  3. Y. Li et al. “Pond: CXL-Based Memory Pooling Systems for Cloud Platforms.” ASPLOS, 2023. https://dl.acm.org/doi/10.1145/3575693.3578835

  4. C. Wei et al. “Fast In-Memory Transaction Processing Using RDMA and HTM.” SOSP, 2015. https://dl.acm.org/doi/10.1145/2815400.2815419

  5. Intel. “Intel Optane DC Persistent Memory.” https://www.intel.com/optane

  6. B. Li et al. “KV-Direct: High-Performance In-Memory Key-Value Store with Programmable NIC.” SOSP, 2017. https://dl.acm.org/doi/10.1145/3132747.3132756

  7. D. Firestone et al. “Azure Accelerated Networking: SmartNICs in the Public Cloud.” NSDI, 2018. https://www.usenix.org/conference/nsdi18/presentation/firestone

  8. D. Oukid et al. “FPTree: A Hybrid SCM-DRAM Persistent and Concurrent B-Tree for Storage Class Memory.” VLDB, 2016. https://dl.acm.org/doi/10.1145/2882903.2882939

  9. J. Arulraj et al. “BzTree: A High-Performance Latch-free Range Index for Non-Volatile Memory.” VLDB, 2018. http://www.vldb.org/pvldb/vol11/p553-arulraj.pdf

  10. A. Dragojević et al. “No Compromises: Distributed Transactions with Consistency, Availability, and Performance.” SOSP, 2015. https://dl.acm.org/doi/10.1145/2815400.2815425

  11. I. Calciu et al. “Rethinking Software Runtimes for Disaggregated Memory.” ASPLOS, 2021. https://dl.acm.org/doi/10.1145/3445814.3446713

  12. H. Li et al. “1-RTT Paxos using RDMA.” NSDI, 2016 (Workshop).

  13. M. Shahrad et al. “Serverless in the Wild: Characterizing and Optimizing the Serverless Workload at a Large Cloud Provider.” USENIX ATC, 2020. https://www.usenix.org/conference/atc20/presentation/shahrad

  14. Intel. “Persistent Memory Development Kit (PMDK).” https://pmem.io/pmdk/

上一篇：可靠广播
下一篇：存算分离架构

同主题继续阅读

把当前热点继续串成多页阅读，而不是停在单篇消费。

2026-04-13

【分布式系统百科】Dynamo 论文精读：最终一致性的工业级范本

2007 年，Amazon 在 SOSP 会议上发表了《Dynamo: Amazon's Highly Available Key-value Store》论文，这篇论文彻底改变了分布式存储系统的设计思路。与追求强一致性的传统数据库不同，Dynamo 选择了一条完全不同的道路：牺牲一致性，换取可用性和分区容错性。这个设…

By .