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

第2章：12 年演进时间线 —— 从 FaRM 到 AURA

把 DM 事务领域 2014–2026 的 12 年系统性串成 5 个时代：奠基、消化重构、专项突破、MVCC 持久化、锁分离 + 控制面。每个时代列代表论文 + 它做了什么 + 留下什么 gap

DM 事务演进时间线 FaRM FORD Motor LOTUS AURA 调研

DM 事务从 2014 年的 FaRM 开始，经过 12 年走到 2026 年的 AURA。这条线上的 30 多篇论文不是孤立的——它们是一个问题驱动的演化序列：FaRM 提出一个问题、解一部分、留下 gap；FORD 接 gap、又解一部分、再留新 gap；如此往复直到 AURA。本章把这 12 年压成 5 个时代，每个时代列代表论文 + 它做了什么 + 它留下什么。读完你应该能徒手画时间线，看任何 DM 论文都能说出”它接的是哪一篇 paper 的 gap”。

1. 时间线总览

   2014        2017       2020         2023        2026
   ─┬───────────┬───────────┬───────────┬───────────┬─→
    │           │           │           │           │
   FaRM        DrTM+H      FORD        Motor      AURA
    │           │           │           │           │
   时代 1       时代 2       时代 3       时代 4      时代 5
   奠基        消化重构    DM 事务专项   MVCC 持久化  锁分离+控制

时代	时间	主线问题	代表论文（精选）
奠基	2014–2017	”DM 事务能不能做？“	FaRM, DrTM, FaSST, Design Guidelines, InfiniSwap
消化重构	2018–2020	”怎么做得更好？“	DrTM+H, LegoOS, RACE, NAM-DB
DM 事务专项	2020–2022	”工程级深挖”	FORD, Sherman, Clover, XStore
MVCC 持久化	2022–2024	”MVCC + 持久化”	Motor, SMART, Outpost, Outback, Plor
锁分离 + 控制面	2025–2026	”锁不要放 MN”	LOTUS, CREST, AURA

🌟 关键观察：每个时代都有一篇标志论文——FaRM / DrTM+H / FORD / Motor / LOTUS-AURA。精读这 5 篇，加 8 篇辅助论文，覆盖领域 90% 思想。

2. 时代 1：奠基（2014–2017）

2.1 时代主问题：“DM 事务能不能做？”

2014 年之前，RDMA 主要被用在 HPC（MPI / GPU 通信）。把它用到事务系统是新尝试——很多基本问题没人回答过：

单边 RDMA 能否实现 OCC？
atomic 原语够不够支持锁？
网络抖动会不会破坏一致性？

2.2 FaRM（NSDI’14）—— 奠基者

做了什么：

首次系统性证明 RDMA 单边 OCC 可行
设计了 commit 路径：READ + CAS + WRITE 组合
提出 cache-line 对齐的锁字布局
用 epoch + lease 处理故障

关键设计：

   FaRM commit 路径
   ────────────────
   1. Read phase:    多次 RDMA READ 取 read set
   2. Lock phase:    RDMA CAS 取 write set 的所有锁
   3. Validate:      RDMA READ 重读 read set 版本
   4. Commit:        RDMA WRITE 落数据
   5. Unlock:        RDMA WRITE 写 lock = 0

留下的 gap：

Gap	后续工作
atomic IOPS 没特别优化	FORD（FAST’22）：cache-line 锁 + doorbell batch
单版本 → 长事务受影响	Motor（OSDI’24）：MVCC
锁全在 MN → 写热点撞墙	LOTUS（2025）：锁提到 CN
协议复杂、性能”够用但不极致”	DrTM+H：hybrid verbs

2.3 DrTM（SOSP’15）—— RDMA + HTM

做了什么：

在 FaRM 基础上加 Intel HTM（Hardware Transactional Memory）
本地事务用 HTM 加速，跨节点用 RDMA + OCC
“硬件事务 + 网络事务”协同

关键 insight：HTM 在本地 cache 内的事务非常快（无锁），跨节点必须用 RDMA。两类事务协议要一致——这是 DrTM 的核心贡献。

留下的 gap：

HTM 受 cache 容量限制（事务大时 abort）
HTM 在 Intel 后续 CPU（Skylake 之后）默认禁用
协议复杂，工程化难

🍎 历史意义：DrTM 启发了”分层事务”思想，但 HTM 的硬件局限让它没成主流。DrTM+H 用 hybrid verbs 替代 HTM 的思路才真正落地。

2.4 FaSST（OSDI’16）—— two-sided 反直觉论证

做了什么：

论证 RDMA SEND/RECV（two-sided）在某些场景比 one-sided 快
关键：远端 server 能 batch 多个请求，单边 op 没法 batch

反直觉点：

   one-sided：CN 直接 RDMA READ → 1 次 RTT，但 server CPU 不能 batch
   two-sided：CN SEND → server batch 处理 N 个 SEND → 1 次 RTT 处理 N

🌟 历史地位：FaSST 不是主流（DM 哲学要求 MN passive），但它定义了”什么时候 one-sided 不够好”——这是后续 DrTM+H 做 hybrid 的理论基础。

2.5 Design Guidelines for High Performance RDMA Systems（ATC’16）

做了什么：

Anuj Kalia 等人系统总结 RDMA 系统设计经验
列出 atomic 路径慢的原因（NIC 内部仲裁）
给出 doorbell batch、QP 数量、MR 大小的最佳实践

🌟 必读论文：任何要做 RDMA 系统的工程师都该精读这篇——它把”为什么 RDMA atomic 是瓶颈”讲得最清楚。

2.6 InfiniSwap（NSDI’17）—— DM 概念落地早期

做了什么：

RDMA-based 远端 swap，把空闲服务器的内存当 swap 用
不是事务系统，但是第一个工程化 DM 系统

为什么重要：

证明 RDMA 远端内存在 production 工作负载下可用
启发了后续所有 DM 工作

2.7 时代 1 总结

到 2017 年底，DM 事务已经回答：“能做”。但还没回答：“怎么做得好”——所有系统的吞吐都受限于 atomic IOPS / 协议复杂度，性能离理论上限还远。

3. 时代 2：消化与重构（2018–2020）

3.1 时代主问题：“怎么做得更好？”

时代 1 解决了”能做”，时代 2 开始深挖工程细节：怎么调度 verbs、怎么布局 MR、怎么设计索引、怎么让协议更快。

3.2 DrTM+H（OSDI’18）—— Hybrid verbs 调度

做了什么：

同时用 one-sided 和 two-sided
根据操作类型选 verbs：读用 one-sided，写/lock 用 two-sided
论文给出选择策略：低冲突 → one-sided，高冲突 → two-sided

关键 insight：没有”最优 verbs”，只有”对当前操作最优 verbs”。这个观点深刻影响了后续工作。

3.3 LegoOS（OSDI’18）—— Disaggregated OS 概念奠基

做了什么：

把 OS 拆分为 process monitor / memory monitor / storage monitor
每个 monitor 跑在独立硬件上
进程可以”借”远端内存

为什么重要：

不是事务系统，但给 DM 一个完整的设计哲学
后续 DM 论文几乎都引 LegoOS 作为概念源头

🍎 直觉：LegoOS 是”把 OS 拆成 LEGO 积木”——CPU、内存、存储各自一块。FORD/Motor/AURA 都是在这个哲学下做事务版本。

3.4 RACE（ATC’20）—— DM 上的 hash 索引

做了什么：

设计在 DM 上工作的高效 hash 索引
关键挑战：单 RDMA RTT 内完成 lookup

为什么重要：

索引是事务系统的基础——FORD/Motor 都得有索引
RACE 给出了 DM hash 索引的标准做法（开放寻址 + RDMA-friendly bucket layout）

3.5 NAM-DB（VLDB’20）—— NIC-attached database

做了什么：

把整个数据库引擎部署在 NIC-attached server 上
走”半 DM”路线（详见第 1 章 §7.5）

为什么重要：

探索了”在 NIC 边上跑应用 CPU”的可能性
后续 SmartNIC 路线的早期参考

⭕ 互补：NAM-DB 不是主流 DM，但SmartNIC 在 ConnectX-7+ 上越来越强——未来”半 DM”可能复兴。

3.6 时代 2 总结

到 2020 年底，DM 工程层面的”基础库”已经齐备：verbs 调度策略、索引设计、MR 布局。接下来只需要”把它们组装成完整的事务系统”——这就是时代 3 的工作。

4. 时代 3：DM 事务专项（2020–2022）

4.1 时代主问题：“工程级深挖”

时代 3 是 DM 事务爆发期——多篇 milestone 论文在 2-3 年内集中产出。每篇都把某个具体子问题做到工程极限。

4.2 FORD（FAST’22）—— 单版本 DM 事务的工程极限

做了什么：

cache-line 对齐锁布局（16B 锁字 + version + flags）
doorbell batch 把多 op 摊到一次 NIC ring
把 commit 路径压到 ~5–10µs
在 c6525-25g 上跑出 ~250 KTPS / 2 CN

关键设计：

   FORD lock layout（16B aligned）
   ────────────────────────────────
   ┌──────────────────────────────────┐
   │  lock_word (8B)                  │
   │  ┌──────┬──────┬──────────────┐  │
   │  │tx_id │epoch │ flags        │  │
   │  │(16b) │(16b) │ (32b)        │  │
   │  └──────┴──────┴──────────────┘  │
   ├──────────────────────────────────┤
   │  version_word (8B)               │
   └──────────────────────────────────┘
   16B = 一个 cache line 的一部分

为什么重要：

后续所有 DM 事务系统的 baseline
CREST 仓库内置 FORD 作为对比 baseline（Comparisons/myford）—— CREST 自身是 from scratch 实现，不是 fork 自 FORD
工程层面”单版本 DM 事务能做到多快”的答案

4.3 Sherman（SIGMOD’22）—— DM 上的分布式 B+tree

做了什么：

在 DM 上实现分布式 B+tree 索引
解决 RDMA-based tree traversal 的延迟问题
引入”hierarchical lock”（不同层级用不同锁策略）

为什么重要：

B+tree 是 OLTP 的核心数据结构
DM 上之前主要是 hash（RACE），Sherman 让 B+tree 也可行

4.4 Clover（ATC’20）—— DM 上的快速持久化 KV

做了什么：

用 PMEM + RDMA 实现持久化 KV
关键：客户端主动管理持久化（MN 不主动 flush）

为什么重要：

揭示”DM + 持久化”的核心矛盾——MN 不主动 flush 怎么保证 durability
后续 FORD-PMEM / Plor 都接这个 gap

4.5 XStore（OSDI’20）—— RDMA-aware learned index

做了什么：

把 ML-based learned index 移植到 RDMA
用预测模型减少 RDMA RTT 数

为什么重要：

是 ML for systems 在 DM 上的早期尝试
启发了后续 ML + DM 协同的方向

4.6 时代 3 总结

到 2022 年底，DM 事务的工程级实现已经成熟。FORD 是这个时代的标志论文——后续所有 DM 系统都在它的 baseline 上做改进。

5. 时代 4：MVCC 与持久化（2022–2024）

5.1 时代主问题：MVCC + 持久化

时代 3 主要做单版本（FORD）。但生产 OLTP 经常需要 SI（Snapshot Isolation）—— 这要求 MVCC。MVCC 在 DM 上是个新问题：版本表怎么放、GC 怎么做、合并怎么做。

5.2 Motor（OSDI’24）—— MVCC + 一致版本表

做了什么：

在 DM 上实现 MVCC
设计”一致版本表”——所有 CN 看到一致的版本视图
支持 SI 隔离级别
用 masked CAS 同时验证多个字段

关键设计：

   Motor 版本表
   ────────────────
   ┌────────────────────────────────────────┐
   │ Record key                             │
   ├────────────────────────────────────────┤
   │ Version chain (most recent first):     │
   │  v_n: ts | tx_id | data_ptr | flags   │
   │  v_{n-1}: ...                         │
   │  v_{n-2}: ...                         │
   │  ...                                   │
   └────────────────────────────────────────┘

为什么重要：

第一个完整工程化的 DM MVCC
引入 masked CAS 的工业用法（多字段原子验证）
后续 SI 类 DM 系统的 baseline

留下的 gap：

版本表 GC 仍然是 CN 主导（MN 不参与）→ GC 延迟
锁仍然在 MN → atomic IOPS 还是上限

5.3 SMART（FAST’24）—— DM 上的 LSM-tree

做了什么：

在 DM 上实现 LSM-tree
关键：compaction 在 CN 侧做（MN 不参与）
处理 RDMA 上的 SST 文件流式写入

为什么重要：

LSM 是 NoSQL 的标准存储结构（RocksDB / Cassandra 风格）
DM 上之前没人做过，SMART 填补了这个 gap

5.4 Outpost（ASPLOS’24）—— DM 上的流式 OCC

做了什么：

“流式 validation”——多个事务的 validate 阶段流水线
减少 RDMA RTT 浪费

关键 insight：传统 OCC 每个事务独立 validate（同步等待），流水线后吞吐显著提升。

5.5 Outback（NSDI’23）—— 异步 RDMA OCC validation

做了什么：

把 validation 阶段做成异步
利用 NIC 的 doorbell 非阻塞特性

为什么重要：

再次证明”RDMA 异步化”是性能利器
Outpost 是 Outback 的进一步发展

5.6 Plor（ATC’23）—— DM 持久化日志加速

做了什么：

用 RDMA 加速 PMEM 上的事务日志写入
关键：客户端主动管理 flush 序列

为什么重要：

DM + 持久化的工程级解决方案
后续 FORD-PMEM 路线的参考

5.7 时代 4 总结

到 2024 年底，DM 事务在协议复杂度上已经做到很高（MVCC + 流式 OCC + 持久化）。但atomic IOPS 物理墙始终没人正面解。这就是时代 5 的主线。

6. 时代 5：锁分离 + 控制面（2025–2026）

6.1 时代主问题：把锁从 MN 移走

时代 1-4 的所有系统锁都在 MN——FaRM / FORD / Motor 一脉相承。这意味着 atomic IOPS 物理上限始终是天花板。时代 5 第一次正面挑战这个假设。

6.2 LOTUS（arXiv’25）—— 静态锁分离

做了什么：

第一次系统性证明”锁可以离开 MN”
应用提供 critical field（如 TPC-C 的 wid）
按 critical field hash → 每个值固定分配给一个 CN
commit 时本地取锁，不用 RDMA CAS
100ms 反应式调整

关键收益：

指标	MN-only	LOTUS
远端 atomic CAS / commit	~3	0
atomic IOPS 上限影响	严重	消失

留下的 gap：

必须应用提供 critical field（不通用）
静态切分 + 反应式（漂移工作负载下退化）
没有形式化的迁移协议
实验仅覆盖单机房同代 NIC

6.3 CREST（开源 DM 事务系统）—— 针对高冲突倾斜负载

⚠️ 诚实声明：CREST 仓库 README 没有标注具体发表会议 / 年份。本章按”开源 DM 事务系统”对待，引用时以仓库为准。本路线之前出现过 “ASPLOS’26” 字样，是不准确的，已经修正。

做了什么（基于 README + 源码核对）：

自实现 from scratch（不是 fork 自 FORD）
协议：OCC + masked-CAS commit（必须 OFED 4.9-7.1.0.0，因为 masked atomic 仅此版本暴露）
MVCC（带 RecordVersion + write_ts，不是单版本）
cell-level CC：支持 record-level + cell-level 两档，细粒度减少 false conflict
column-level rw 追踪：仅传输被修改的列，减少 RDMA 字节流量
CN-side 优化：AddressCache + ENABLE_LOCAL_EXECUTION + ENABLE_REDO_LOG，状态机里有显式 LOCALIZATION 阶段（把热点 record 拉到 CN 本地）
4 类 workload：TPC-C / SmallBank / TATP / YCSB
仓库自带 FORD / Motor 对比 baseline（Comparisons/myford Comparisons/mymotor）

留下的 gap：

锁仍在 MN，atomic IOPS 物理墙仍存在 → LOTUS / AURA 接这个 gap
cell-level CC 是协议优化，不是架构改造
倾斜负载有效，但均匀负载下相比 FORD 复杂度溢价

6.4 AURA（2026, 本路线主体）—— 动态锁所有权 + 闭环控制

做了什么：

接 LOTUS 的 gap：critical field 未知 / 漂移时怎么办
在线学习 cohort（不需要应用先验）
5ms 闭环控制
形式化 4 阶段迁移协议（freeze-drain-handoff-publish）+ 4 不变式

完整章节见模块十五。

   2014 FaRM:   首次撞上 → "我们用 epoch 缓解"
   2018 DrTM+H: hybrid verbs → "可以选不同路径绕开"
   2022 FORD:   doorbell batch → "压榨 NIC 上限"
   2025 LOTUS:  锁提到 CN → "从根上避免 MN atomic"
   2026 AURA:   动态锁所有权 → "在线适应不同工作负载"

🌟 观察：这条主线 12 年还没”解完”——AURA 也只是更广覆盖，cross-DC 等场景仍然受限。

7.2 主线 2：MVCC 与一致版本

   2014 FaRM:   单版本（不支持 SI）
   2022 FORD:   单版本（同样不支持 SI）
   2024 Motor:  MVCC + 一致版本表 → 第一次完整支持 SI
   未来:        MVCC + 锁分离协同？AURA × Motor 的合体？

7.3 主线 3：持久化与故障

   2014 FaRM:   epoch + lease
   2020 Clover: PMEM + RDMA 客户端管 flush
   2023 Plor:   PMEM 日志加速
   未来:        CXL pool + 持久化协议

7.4 主线 4：索引

   2020 RACE:    hash
   2022 Sherman: B+tree
   2024 SMART:   LSM
   未来:         learned index？图索引？多模索引？

8. 时间线 ASCII 图（带 gap 链）

   2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024  2025  2026
   ─┬────┬────┬────┬────┬────┬────┬────┬────┬────┬────┬────┬────┬────┬─→
    │    │    │    │    │    │    │    │    │    │    │    │    │
   FaRM DrTM      Design       LegoOS         FORD    Motor       LOTUS AURA
                  Guidelines    DrTM+H        Sherman SMART       CREST
                  FaSST                        Clover  Outpost
                                  RACE         XStore  Outback
                              InfiniSwap                Plor
                              NAM-DB

   主线 1 (atomic IOPS):
   FaRM ───────── DrTM+H ──────────── FORD ────────────────── LOTUS ── AURA
   "epoch"        "hybrid"           "batch"                  "lock"   "dynamic"
   
   主线 2 (MVCC):
   ........... 单版本 ......................... Motor ───────────────────────→
                                               "一致版本表"
   
   主线 3 (持久化):
   ............................... Clover ────── Plor ────────────────────→
                                   "PMEM"        "log"
   
   主线 4 (索引):
   ........................... RACE ──── Sherman ──── SMART ───────────────→
                               hash      Btree        LSM

🍎 观察：四条主线几乎独立演化——少数论文同时推进多条（如 Motor 同时推 MVCC 和索引）。这就是为什么 DM 事务领域虽然只有 12 年但论文这么多。

FaRM (Dragojević et al., NSDI’14)：USENIX 链接
DrTM (Wei et al., SOSP’15)
FaSST (Kalia et al., OSDI’16)：USENIX 链接
Design Guidelines (Kalia et al., ATC’16)：USENIX 链接 —— 必读
InfiniSwap (Gu et al., NSDI’17)

消化重构期

DrTM+H (Wei et al., OSDI’18)
LegoOS (Shan et al., OSDI’18)：arXiv 1810.01632
RACE (Zuo et al., ATC’20)
NAM-DB (Zamanian et al., VLDB’20)

DM 事务专项

FORD (Zhang et al., FAST’22)：USENIX 链接 —— 必读
Sherman (Wang et al., SIGMOD’22)
Clover (Tsai et al., ATC’20)
XStore (Wei et al., OSDI’20)

MVCC 持久化

Motor (Wu et al., OSDI’24)：USENIX 链接 —— 必读
SMART (Luo et al., FAST’24)
Outpost (Wang et al., ASPLOS’24)
Outback (Choi et al., NSDI’23)
Plor (Lee et al., ATC’23)

锁分离 + 控制面

LOTUS (Liu et al., arXiv’25)
CREST（开源 DM 事务系统）
AURA（本路线主体，2026）

综述与背景

The Datacenter as a Computer (Barroso et al., 3rd ed., 2018)
A Survey on Disaggregated Memory (Wang et al., 2023)

行业讨论

Anuj Kalia’s RDMA series blog —— 很好的工程视角

搜索