分离式内存事务系统全景调研 2026年5月10日

第3章：8 个核心问题地图 —— DM 事务这 12 年都在解什么

把 DM 事务领域所有论文反复出现的 8 个核心问题拆开：atomic IOPS、RDMA RTT、OCC validate、锁布局、索引、MVCC、持久化、故障。每个问题列出主线论文 + 当前 SOTA + 仍未解的部分

DM 事务核心问题 atomic IOPS OCC MVCC 持久化调研

第 2 章按时间线串了 12 年演进，本章换个视角：按问题维度看。DM 事务领域所有论文反复在解的，本质上就 8 个核心问题——atomic IOPS、RDMA RTT、OCC validate、锁布局、索引、MVCC、持久化、故障。每个问题都是一条贯穿 12 年的主线，每个时代都有论文在推进。本章把这 8 条主线展开，给每个问题画一张”问题地图”——它是什么、为什么难、谁在解、当前 SOTA、仍未解的部分。读完你会拿到看任何 DM 论文的”问题坐标系”。

1. 问题 1：atomic IOPS 物理墙

1.1 问题陈述

RDMA atomic 操作（CAS / FAA）在 NIC 内部串行化，单卡有硬上限：

NIC 代际	单 QP atomic Mpps	多 QP 聚合
ConnectX-3	~1	~2.6（饱和）
ConnectX-5/6 Dx	~3	~5–10
ConnectX-7 (TBD)	~5	~10–15

这个上限不能水平扩展——加多个 QP 也不行，因为 NIC 内部只有一个 atomic engine（CX-7 多 engine 但热点地址仍然串行）。

1.2 为什么难

   atomic 路径（NIC 内部）
   ────────────────────
   1. RX engine 解析 atomic op
   2. atomic engine 仲裁同地址访问
   3. PCIe → 主机内存 read 8B
   4. 在 NIC 内做比较
   5. 如匹配 → PCIe write 8B
   6. 生成 response packet
   ──────────────────────
   每个 atomic 至少 2 次 PCIe RTT + NIC 内部仲裁

根本原因：原子性必须串行化，PCIe RTT 是物理常数（~150ns），NIC 一秒能做的 atomic 数量被这个常数 cap 住。

1.3 主线推进史

时代	论文	推进方式
2014	FaRM	用 epoch + lease 减少 atomic 频次
2018	DrTM+H	hybrid verbs → 写不上 atomic 的部分用 two-sided
2022	FORD	doorbell batch 把 atomic 摊到一次 NIC ring
2025	LOTUS	锁提到 CN，atomic 总量从 MN 移走
2026	AURA	动态锁所有权，跟随漂移

1.4 当前 SOTA

AURA（2026）：在 critical field 未知或漂移的工作负载下完全消除 MN atomic（除 fallback 路径）。

1.5 仍未解的部分

⚠️ 开放问题：

跨 DC 场景：OwnerRpc 延迟 >> MN atomic，AURA 反而更慢
异构 NIC 集群：CX-3 + CX-6 混合时 cohort 怎么放
CXL 上的 atomic：CXL.mem 也有 atomic 上限，CXL pool 上的 DM 事务还是新问题

🌟 结论：atomic IOPS 这条主线 12 年还在推进——AURA 解了”动态适应”，但跨 DC / 异构 / CXL 仍是 gap。

2. 问题 2：RDMA RTT 与 batch

2.1 问题陈述

RDMA RTT 是物理上限：

网络	单次 RTT
同机柜	~2µs
同 DC	~5–10µs
跨 DC	~ms

事务延迟 = RTT × op 数量。一个 commit 路径 5–14 次 RDMA op → 10–30µs 单事务延迟。RTT 数量决定了吞吐上限。

2.2 为什么难

OCC commit 路径有大量 op：

   ① RDMA READ × N    (read set)
   ② RDMA READ × N    (validate)
   ③ RDMA CAS  × M    (lock acquire)
   ④ RDMA WRITE × M   (data)
   ⑤ RDMA WRITE × M   (lock release)

如果每个 op 串行 → N + N + M + M + M = 总延迟。

2.3 主线推进史

论文	推进
FaRM	单 op 同步
Design Guidelines	doorbell batch + post 多 WQE
FORD	doorbell batch + cache-line 锁，多 op 一次 doorbell
Outback (NSDI’23)	异步 validation——validate 不阻塞下个事务
Outpost (ASPLOS’24)	流式 validation——多事务流水线

2.4 当前 SOTA

Outpost（2024）：把 validation 阶段做成流水线，吞吐显著提升。

2.5 仍未解的部分

持久化路径上的 RTT：PMEM flush 仍然是 1 RTT/事务，没人能压到 0
跨 cohort 协调（AURA）：OwnerRpc 加了一次 RTT，没法 batch（语义不允许）

3. 问题 3：OCC validate 路径

3.1 问题陈述

OCC 三阶段：Read → Validate → Commit。Validate 阶段重读 read set 的版本号——这在 DM 上意味着 |read_set| 次 RDMA READ。

   OCC validate（同步版本）
   ────────────────────
   foreach record in read_set:
       version_now = rdma_read(record.version_addr)
       if version_now != record.version_at_read:
           return ABORT
   return COMMIT

读集大时 validate 是单事务延迟瓶颈——比如 |read_set|=20 → 20 次 RTT。

3.2 为什么难

不能简单 batch——validate 的语义要求”看到完成的写入”，需要 memory order 保证。

3.3 主线推进史

论文	推进
FaRM	同步 validate
FORD	把 version 字段塞进 record 头 → 1 RDMA READ 同时取 data + version
Outback (NSDI’23)	异步 validate——不阻塞下一个事务的 read
Outpost (ASPLOS’24)	流水线 validate
Motor	用 masked CAS 在 commit 阶段同时验证 + 取锁 → 省掉单独的 validate

3.4 当前 SOTA

Motor + Outpost：MVCC 下 validate 几乎隐形（版本字段在 record 内）。

3.5 仍未解的部分

跨 cohort 验证（AURA）：跨 cohort 的 read set 可能要发到多个 owner CN，协调复杂
流水线下的 abort 处理：流水线后期 abort 要回滚多事务

4. 问题 4：锁字布局与 8B 极限

4.1 问题陈述

RDMA atomic 只支持 8B 对齐操作。所有锁信息必须压进 8B：

字段	含义
holder_tx_id	谁持有锁（避免 ABA）
version	用于 OCC 验证
state flags	锁状态（owned / fallback / migrating）
epoch	防 stale

这些信息总和经常超过 8B——必须用各种压缩技巧。

4.2 为什么难

   FORD 锁字（16B aligned，但 atomic 只覆盖 8B）
   ────────────────────────────────────────────
   ┌──────────────────────────────────────┐
   │  lock_word (8B):                      │
   │    bit 0-15:  holder_tx_id           │
   │    bit 16-31: epoch                  │
   │    bit 32-63: flags + version_low    │
   ├──────────────────────────────────────┤
   │  version_high (8B): version_high      │
   │   ↑ 单独的字段，必须用第二次 RDMA       │
   └──────────────────────────────────────┘

挑战：

8B 不够装所有字段
用第二个 word → 增加 op 数
用 masked CAS（只更新 8B 中部分 bit）→ 复杂、需要 NIC 支持

4.3 主线推进史

论文	推进
FaRM	简单 8B holder + version
FORD	cache-line 对齐布局，把 version 摊到第二个 8B
Motor	masked CAS 同时操作多个字段，不增加 op 数
LOTUS	锁在 CN → 字段不受 8B 限制
AURA	同 LOTUS，且加 cohort_epoch 字段

4.4 当前 SOTA

Motor（用 masked CAS）+ LOTUS/AURA（锁在 CN，字段任意大）。

4.5 仍未解的部分

ConnectX-3 不支持 masked CAS → 跨硬件代际兼容
新硬件（CXL）的 atomic 支持 → 还没标准化

5. 问题 5：索引在 DM 上怎么放

5.1 问题陈述

事务系统需要索引——hash / B+tree / LSM 等。DM 上索引的特殊挑战：

索引也在 MN（远端），lookup 要 RDMA RTT
索引更新要保证一致（与数据更新协同）
索引大小可能很大（GB 级），不能 cache 全部

5.2 为什么难

   单机数据库的索引
   ────────────────
   ① 内存中读 root
   ② 内存中读 internal nodes
   ③ 内存中读 leaf
   ④ 拿到 record_addr → 内存中读 record
   ─────────────────────────────────
   总延迟：~50ns（cache hit）
   
   DM 上的索引
   ────────────────
   ① RDMA READ root
   ② RDMA READ internal × log(N)
   ③ RDMA READ leaf
   ④ RDMA READ record
   ─────────────────────────────────
   总延迟：~ (log(N) + 1) × 2µs = 10–20µs

🌟 核心问题：DM 上索引 lookup 有 log(N) 次 RTT——比单机慢 100×。

5.3 主线推进史

论文	推进
RACE (ATC’20)	DM 上的高效 hash 索引（开放寻址 + RDMA-friendly bucket）
Sherman (SIGMOD’22)	DM 上的分布式 B+tree，hierarchical lock
XStore (OSDI’20)	RDMA-aware learned index，预测减少 RTT
SMART (FAST’24)	DM 上的 LSM-tree，CN 侧 compaction

5.4 当前 SOTA

索引类型	SOTA
Hash	RACE
B+tree	Sherman
Learned	XStore
LSM	SMART

5.5 仍未解的部分

图索引：DM 上没人做过
多模索引（同时支持多种查询）
索引与事务协同（索引更新如何无缝融入 OCC commit）

6. 问题 6：MVCC 版本管理

6.1 问题陈述

支持 SI（Snapshot Isolation）需要 MVCC——保留多个历史版本，事务读到一致快照。DM 上 MVCC 的特殊挑战：

版本表怎么放（单 record 内 inline vs 单独 chain）
版本 GC 怎么做（MN 不主动 GC）
一致快照怎么协调（多 CN 看到一致的版本视图）

6.2 为什么难

   MVCC 必备能力
   ────────────────
   1. 写不阻塞读（reader 看老版本）
   2. 一致快照（事务整个生命周期看同一个 snapshot）
   3. GC（删除不再被任何事务引用的老版本）
   
   DM 限制
   ────────────────
   1. ✓ MVCC 设计上写不阻塞读
   2. ✗ 一致快照需要全局 ts → 用什么时钟？
   3. ✗ MN 不主动 GC → CN 必须协调

6.3 主线推进史

论文	推进
FaRM	单版本（不支持 SI）
FORD	单版本（同上）
Motor	首次完整 MVCC——一致版本表 + masked CAS
AURA × Motor 合体（开放）	锁分离 + MVCC

6.4 Motor 的核心设计

   Motor 一致版本表
   ────────────────
   ┌────────────────────────────────────────┐
   │ Record ID                              │
   ├────────────────────────────────────────┤
   │ Version chain:                         │
   │   v_n:   ts=42  | tx_id=...  | data_n │
   │   v_n-1: ts=40  | tx_id=...  | data_n-1│
   │   v_n-2: ts=38  | tx_id=...  | data_n-2│
   │   ...                                  │
   ├────────────────────────────────────────┤
   │ active reader cnt（用于 GC 决策）        │
   └────────────────────────────────────────┘

事务用 ts 选择”≤ ts 的最大版本”作为快照基准。

6.5 当前 SOTA

Motor（OSDI’24）—— 第一个完整 DM MVCC。

6.6 仍未解的部分

GC 延迟：CN 主导 GC 导致版本堆积
MVCC + 锁分离协同：Motor + AURA 合体没人做过
Cross-DC MVCC：全局快照协调代价巨大

7. 问题 7：持久化与 flush 协议

7.1 问题陈述

事务系统需要 durability——commit 后数据不丢。DM 上持久化的特殊挑战：

MN 不主动 flush（只有 CN 知道哪些数据需要持久化）
PMEM 的 flush 协议复杂（cache flush + memory barrier）
多副本一致性需要协调

7.2 为什么难

   单机数据库的持久化
   ────────────────
   1. 写 WAL → fsync → 返回 OK
   2. OS 保证 write 顺序
   
   DM 上的持久化
   ────────────────
   1. CN 写 RDMA → 数据到 MN 主机内存
   2. MN 主机内存 → ??? 怎么保证落到 PMEM
   3. CN 如何知道 flush 完成
   4. 多副本一致性谁来协调

7.3 主线推进史

论文	推进
FaRM	epoch + lease，不严格持久化
Clover (ATC’20)	客户端主动管理 PMEM flush
FORD-PMEM	集成 PMEM 写路径
Plor (ATC’23)	加速 PMEM 日志

7.4 客户端主动 flush 协议

   CN 持久化协议
   ────────────────
   1. RDMA WRITE data → MN
   2. RDMA WRITE flush flag → MN（特殊地址）
   3. MN 收到 flush flag → CPU 触发 PMEM flush
   ↑ 这里仍然需要 MN 一点 CPU 参与（轻量级）
   
   或：
   1. RDMA WRITE data
   2. RDMA READ flush_complete flag → MN
   ↑ 用 NIC 的 ordering 保证 read 在 write 之后

7.5 当前 SOTA

Plor（ATC’23）—— PMEM 日志写入加速。

7.6 仍未解的部分

跨副本一致性：多 MN 之间的 PMEM 状态同步
CXL 持久化：CXL.mem 上的持久化协议
fsync 之外的 durability 模型：RDMA-native durability

8. 问题 8：故障与恢复模型

8.1 问题陈述

DM 上的故障类型：

CN 故障：进程 crash、network partition
MN 故障：节点宕机、PMEM 损坏
网络故障：partition、丢包、抖动

DM 上的恢复挑战：

MN 不能主动恢复（无 CPU）
锁状态必须能恢复（特别是 LOTUS / AURA 的 CN-side 锁）
数据一致性必须保留

8.2 为什么难

   MN 故障的复杂性
   ────────────────
   单机数据库：DB 进程 crash → 重启 → recover 从 WAL
   DM:        MN 节点 down → 谁来 recover？
              MN 上的锁字 / 版本表都丢失（如果非 PMEM）
              CN 持有的"过期"锁状态怎么办

8.3 主线推进史

论文	推进
FaRM	epoch + lease + Paxos-based config service
FORD	类似 FaRM
Motor	epoch + 一致版本表
Plor	PMEM 持久化日志
LOTUS / AURA	CN-side 锁的恢复（fallback 到 MN）

8.4 故障模型分类

模型	假设	代表系统
Crash-stop	节点 crash 后不再返回	FaRM / FORD
Crash-recover	节点 crash 后能恢复（PMEM）	Plor
Byzantine	节点可能恶意（不在 DM 范围）	-
Network partition	网络分区，节点活但不通	LOTUS / AURA（用 fallback）

8.5 当前 SOTA

FaRM-style epoch + lease + Paxos config service——经典做法仍是主流。

8.6 仍未解的部分

多 MN 故障：单 MN 故障容易，多 MN 同时 down 还没好的处理
CN-side 状态丢失（AURA）：owner CN crash 时 cohort state 丢失
跨 DC 故障：partition 检测和恢复

9. 问题之间的耦合

8 个问题不是独立的，存在多组耦合：

9.1 主要耦合关系

   问题 1 (atomic IOPS)
        │ 耦合于
        ▼
   问题 4 (锁字布局) → 锁字大小决定 atomic 能否压进 8B
   
   问题 1
        │ 耦合于
        ▼
   问题 6 (MVCC) → MVCC 多版本 + 一致快照可能减少锁争用 → 减少 atomic
   
   问题 2 (RTT)
        │ 耦合于
        ▼
   问题 3 (validate) → validate 是 RTT 大户
   问题 5 (索引) → 索引 lookup 是 RTT 大户
   
   问题 7 (持久化)
        │ 耦合于
        ▼
   问题 8 (故障恢复) → 持久化策略决定恢复模型

9.2 一个完整的设计权衡

设计一个 DM 事务系统时必须同时考虑：

   选 MVCC（解决问题 6）
       ↓ 增加版本表 → 增加问题 7（持久化代价）
       ↓ 减少锁争用 → 缓解问题 1（atomic IOPS）
   
   选锁分离（解决问题 1）
       ↓ 增加 CN-side 状态 → 增加问题 8（故障恢复）
       ↓ 减少 MN atomic → 缓解问题 1
   
   选异步 validate（解决问题 2/3）
       ↓ 增加 abort 处理复杂度 → 增加问题 8（故障恢复）

🌟 核心洞察：DM 事务设计是一个全局优化问题——任何单点优化都可能在另一个维度引发新问题。这就是为什么这个领域还有这么多 paper 在做。

9.3 未来 SOTA 的合体方向

理想的 DM 事务系统应该同时解决：

atomic IOPS（AURA 的锁分离）
MVCC（Motor 的一致版本）
异步 validate（Outpost 的流水线）
持久化（Plor 的 PMEM 日志）
高效索引（Sherman 的 B+tree / SMART 的 LSM）

还没有论文做了所有这些——这是开放方向（详见第 9 章）。

✅ 自我检验清单

📚 参考资料

关键论文（按问题）

问题 1 atomic IOPS：FaRM, DrTM+H, FORD, LOTUS, AURA 问题 2 RTT：Design Guidelines, FORD, Outback, Outpost 问题 3 OCC validate：FaRM, FORD, Motor, Outback, Outpost 问题 4 锁字布局：FaRM, FORD, Motor (masked CAS) 问题 5 索引：RACE, Sherman, XStore, SMART 问题 6 MVCC：Motor 问题 7 持久化：Clover, FORD-PMEM, Plor 问题 8 故障恢复：FaRM, Motor, Plor

综述

A Survey on Disaggregated Memory (Wang et al., 2023)

行业讨论

Anuj Kalia 的 RDMA 系列 —— 问题 1/2/3 必读
Spanner / Cockroach 论文 —— 经典分布式事务的对照

搜索