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

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

📑 目录

1. 问题 1：atomic IOPS 物理墙
2. 问题 2：RDMA RTT 与 batch
3. 问题 3：OCC validate 路径
4. 问题 4：锁字布局与 8B 极限
5. 问题 5：索引在 DM 上怎么放
6. 问题 6：MVCC 版本管理
7. 问题 7：持久化与 flush 协议
8. 问题 8：故障与恢复模型
9. 问题之间的耦合
自我检验清单
参考资料

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 论文 —— 经典分布式事务的对照

搜索