第1章：DM 事务定义与领域边界 —— 它和单机/共享存储/经典分布式有什么本质区别

DM 事务是分布式事务领域过去 12 年里”最像但又最不像”的一类系统——它表面看是”分布式数据库的网络更快版本”，但底层硬件假设的差异几乎让 Spanner / Cockroach 那一整套范式在 DM 上不再适用。本章不直接进入任何论文细节，而是先把”DM 事务到底是什么、不是什么”用 4 个区分维度钉死。读完你应该能拿到一个 5 秒判别工具：看到任何新系统，问 4 个问题就能判断它是不是 DM 事务、是 DM 事务的话属于哪一支。这是后续 8 章所有深挖的基础坐标系。

📑 目录

1. 用一个反例开场：Spanner 不是 DM 事务
2. 四个区分维度
3. DM 事务 vs 单机数据库
4. DM 事务 vs 共享存储数据库（Aurora / Polar）
5. DM 事务 vs 经典分布式事务（Spanner / Cockroach）
6. 为什么”OCC + 单边原语”几乎是 DM 事务的默认范式
7. 5 秒判别工具：4 个问题
8. 领域边界外：哪些系统看起来像 DM 但其实不是
自我检验清单
参考资料

1. 用一个反例开场：Spanner 不是 DM 事务

1.1 Spanner 的硬件模型

Google Spanner 是经典分布式事务的代表。每个 Spanner 节点：

持有一份完整数据 partition（Paxos 副本）
跑应用 CPU（执行 query）
跑事务管理器（TrueTime + 2PC coordinator）
持有 SSD 存储

   Spanner Node A          Spanner Node B
   ────────────────         ────────────────
   ┌──────────────┐         ┌──────────────┐
   │ Application  │         │ Application  │
   │ Query Engine │         │ Query Engine │
   ├──────────────┤         ├──────────────┤
   │ Txn Manager  │ ←───→   │ Txn Manager  │   2PC + Paxos
   │ (Paxos lead) │         │ (replica)    │
   ├──────────────┤         ├──────────────┤
   │ SSD storage  │         │ SSD storage  │
   └──────────────┘         └──────────────┘
                  TCP / RPC

关键观察：Spanner 的两端都是 active 节点——能跑代码、能维护锁状态机、能主动 abort/commit 协议。

1.2 DM 事务的硬件模型

   CN A                                     CN B
   (Compute Node)                           (Compute Node)
   ───────────────                         ───────────────
   ┌──────────────┐                        ┌──────────────┐
   │ Application  │                        │ Application  │
   │ Txn logic    │                        │ Txn logic    │
   │ Local cache  │                        │ Local cache  │
   └────┬─────────┘                        └────┬─────────┘
        │  RDMA single-sided                    │
        │  READ / WRITE / CAS / FAA             │
        ▼                                       ▼
   ┌──────────────────────────────────────────────────┐
   │ MN (Memory Node, passive memory + RNIC)          │
   │ ┌────────────────────────────────────────────┐   │
   │ │ data records | lock words | version table  │   │
   │ │ index region | log buffer (PMEM if any)    │   │
   │ └────────────────────────────────────────────┘   │
   │ NO application CPU. RNIC processes RDMA only.     │
   └──────────────────────────────────────────────────┘

关键观察：MN 完全 passive——没有应用 CPU 运行事务逻辑、没有锁状态机、没有协议参与。

1.3 这个差异不是”性能优化”

很多人第一次看 DM 事务以为是”Spanner 网络更快版本”——错。这是硬件假设的差异：

操作	Spanner	DM
远端取锁	远端线程 receive RPC → 检查状态机 → reply	NIC 直接 CAS 内存 8B 字
远端写数据	远端线程 receive → 验证 → 写盘 → reply	NIC DMA 到主机内存
远端 abort 协议	远端线程主动发 abort 消息	MN 不知道 abort 是什么
远端持久化	远端 fsync	CN 必须主动确保 PMEM flush

🌟 关键事实：DM 的协议必须只用”被动内存能支持的语义”——也就是 RDMA 单边原语 + 字节级原子操作。这是为什么很多 Spanner 思想（TrueTime、2PC、Paxos lead）在 DM 上要么不可用、要么必须重写。

🍎 直觉比喻：Spanner 像”两个能商量的银行职员”，DM 像”两个客户都对着同一个 ATM 操作，ATM 不会替任何一方做决定”。

2. 四个区分维度

要把 DM 事务从其他相邻领域里切出来，最简洁的工具是 4 个二选一的维度：

   D1: 远端是否资源解耦？
       ────────────────────
       是 → 计算节点和存储节点物理分开
       否 → 计算和存储在同一节点
   
   D2: 远端是否被动？
       ──────────────────
       是 → 远端 NIC 处理请求，无应用 CPU 参与
       否 → 远端有线程跑代码、状态机
   
   D3: 主路径是否单边原语？
       ──────────────────────
       是 → READ / WRITE / CAS / FAA 直接 DMA
       否 → SEND/RECV 双边消息 + 远端 handler
   
   D4: 默认并发控制是 OCC 还是 2PL？
       ─────────────────────────────────
       OCC → 不取锁、提交时验证 + CAS
       2PL → 事务开始就取锁，远端持有

只要 D1=是 + D2=是 + D3=是 + D4=OCC，就是典型 DM 事务系统。任何一个维度反过来，就脱离 DM 范式：

D1	D2	D3	D4	这是什么
✓	✓	✓	OCC	DM 事务（FaRM/FORD/Motor/AURA）
✓	✓	✓	2PL	罕见（不可行：2PL 需要远端线程持锁）
✓	✓	部分双边	OCC	DrTM+H / FaSST 类 hybrid
✓	否	×	OCC	NAM-DB（NIC-attached）
否	×	×	OCC	单机数据库
✓	否（active）	否（RPC）	OCC/2PL	共享存储（Aurora / Polar）
否	否	×	2PL	经典分布式（Spanner）

🧠 关键洞察：四个维度构成 DM 事务的特征签名——任意一个反过来都意味着进入相邻领域。这给了你看任何新论文 5 秒定位的工具。

3. DM 事务 vs 单机数据库

3.1 单机数据库的设计前提

单机数据库（PostgreSQL / MySQL / RocksDB / DuckDB）：

所有数据在本地内存或本地磁盘
锁、版本、索引都在同一进程地址空间
并发控制可以用任何机制（2PL / MVCC / OCC / 锁层级 / 死锁检测）
性能瓶颈在磁盘 IO + 锁争用

3.2 DM 改变了什么

   单机数据库                         DM 事务系统
   ──────────────                     ────────────────
   ┌──────────────┐                   ┌──────────────┐
   │ Application  │                   │ CN logic     │
   │ Buffer Pool  │                   │ Local cache  │
   │ Lock Manager │ ← 本地内存          └────┬─────────┘
   │ Version Mgr  │                        │ RDMA
   │ Index        │                        ▼
   │ WAL          │                   ┌──────────────┐
   │ ↓             │                   │ MN: data + lock│
   │ Disk         │                   │      + version │
   └──────────────┘                   │      + index   │
                                      └──────────────┘
   性能瓶颈: 磁盘 IO              性能瓶颈: RDMA atomic IOPS

3.3 三个反直觉的 DM 设计选择

选择 1：放弃所有需要”远端代码”的设计

单机方案	在 DM 不可用	因为
锁等待队列（remote lock manager）	是	MN 不能维护队列
死锁检测器	是	需要全局视图 + 主动算法
可重入锁	是	状态机
锁升级（read → write）	是	需要协议

选择 2：8B atomic 是唯一同步原语

   单机：std::mutex / spinlock / atomic<T> for any T
   DM：  RDMA CAS 8B / FAA 8B（其他都不是 atomic）

🌟 后果：所有锁字必须能压进 8B。版本号 + lock holder + flags 全部塞进同一个 8B 字段——这是为什么 masked CAS 有用（可以只更新 8B 中的部分 bit）。

选择 3：放弃 buffer pool 的所有变种

单机数据库花了 30 年优化 buffer pool（LRU、CLOCK、ARC、各种淘汰算法）。DM 上这些不再适用：

数据”在哪个层级”由 RDMA 网络决定，不是由 OS page cache 决定
buffer pool 的 hit miss 不再是核心 metric——RDMA RTT 才是
prefetch 和 batch 必须在 RDMA verbs 层做

🍎 直觉：DM 把”内存 vs 磁盘”的二元层级换成”local vs remote DRAM”——两端都是 ns 级，但中间有 µs 级网络。

4. DM 事务 vs 共享存储数据库（Aurora / Polar）

4.1 共享存储数据库的架构

Amazon Aurora / Alibaba PolarDB / Microsoft Hyperscale 这一系：

   ┌──────────────┐  ┌──────────────┐  ┌──────────────┐
   │ Compute      │  │ Compute      │  │ Compute      │
   │ Node 1       │  │ Node 2       │  │ Node 3       │
   │ (主)          │  │ (只读副本)   │  │ (只读副本)   │
   └──────┬───────┘  └──────┬───────┘  └──────┬───────┘
          │  redo log only          │  read pages
          ▼                                          ▼
   ┌──────────────────────────────────────────────────┐
   │ Shared Storage (distributed log + page server)    │
   │ ★ 这里有应用 CPU                                  │
   │ ★ Storage server 主动 apply log → page             │
   │ ★ Storage 主动做 GC、compaction、replication       │
   └──────────────────────────────────────────────────┘

4.2 共享存储 vs DM 的关键差异

维度	共享存储（Aurora）	DM
远端是否被动	否（storage server 主动 apply log）	是
主路径协议	RPC（compute → storage 发 redo log）	RDMA 单边
锁管理	compute 节点（leader）	CN 或 MN 上的 8B 字
一致性维持	redo log 串行化 + page server replay	OCC validate + CAS
默认并发控制	2PL（PostgreSQL 风格）/ MVCC	OCC + MVCC

🌟 核心区分：共享存储的 storage 是 active 服务（有 CPU），DM 的 MN 是 passive memory（无 CPU）。这是两条完全不同的工程路径。

4.3 共享存储的工程优势

⭕ 互补：DM 不一定比共享存储好——共享存储有自己的优势：

storage server 能做主动 GC、compaction、replication，不需要客户端管
能跑复杂逻辑（page server 可以解析 SQL hint）
兼容性好（用现成的 PostgreSQL/MySQL kernel 改）

DM 的优势在另一头：

真正的 zero-copy（不经过 storage server CPU）
更细粒度的扩展性（CN 数量与 MN 容量独立）
更接近”硬件级”性能上限

🧠 关键洞察：共享存储是”分布式数据库的工程化”，DM 是”分布式数据库的硬件原生重构”——两者面向不同 trade-off，长期共存。

4.4 一个常见误解：把 Aurora 当成 DM

⚠️ 重要：Aurora 论文里有”compute 和 storage 解耦”的说法，让一些读者误以为 Aurora 是 DM。它不是——Aurora 的 storage 是 active server（page server 跑代码），不是 passive memory。

判别方法：问”远端节点上跑不跑应用 CPU”。Aurora 跑（page server 解析 redo log）。FORD/Motor 不跑。

5. DM 事务 vs 经典分布式事务（Spanner / Cockroach）

5.1 经典分布式事务的核心机制

机制	Spanner	Cockroach	FaRM/FORD/Motor
Leader 选举	Paxos	Raft	无（无 leader）
全局时间	TrueTime	HLC	epoch（基于 NIC RTT）
跨节点协议	2PC + Paxos	2PC + Raft	OCC + RDMA CAS
远端 abort	主动消息	主动消息	不存在概念
节点角色	都是 active replica	都是 active replica	CN active, MN passive

5.2 为什么 Spanner 思想在 DM 上不适用

   Spanner 协议假设
   ────────────────
   1. 远端节点有线程持有锁、能 timeout、能主动 release
   2. 跨节点协议 = 多个 active 节点交换消息达成共识
   3. 时间用 TrueTime 等"权威时钟服务"
   
   DM 的限制
   ────────────────
   1. MN 没线程 → 不能"持有锁等待"
   2. 多 active 节点 = 多 CN，但 MN 不参与协议
   3. NIC 的 RTT 是天然 epoch 边界，不需要时钟服务

🌟 后果：Spanner 的整套协议要么完全不可用，要么必须重写。FaRM 论文（2014）里专门说过这一点：“we deliberately rejected 2PC because it requires remote thread participation”。

5.3 跨节点事务在 DM 上怎么做

经典分布式事务用 2PC：

   Coordinator → ALL participants:
     1. PREPARE: "你能提交吗？"
     2. ALL reply: "能/不能"
     3. COMMIT/ABORT: "提交吧/回滚吧"

DM 上没有 active 远端，跨 cohort 事务怎么办？两种方案：

方案	怎么做
OCC validate + CAS（FaRM/FORD）	取所有锁（CAS）→ 验证版本（READ）→ 写入（WRITE）。失败原子回滚
Owner 代理（LOTUS/AURA）	客户端发到主 cohort owner，由它 forward 给协作 owner

两种都不需要 MN 参与——这是 DM 设计哲学的根本。

5.4 一个高度 important 的工程后果

DM 事务系统几乎都不做”严格 serializable + 跨数据中心”：

Spanner 主打全球分布 + 严格 serializable
DM 主打单 DC 单机柜规模 + 强一致

🌟 不同的目标空间：DM 不是”廉价 Spanner”，是”针对单机柜内 OLTP 极限性能的另一种范式”。理解了这个目标空间区别，才不会拿 Spanner 去 review DM 论文。

6. 为什么”OCC + 单边原语”几乎是 DM 事务的默认范式

6.1 为什么不是 2PL

2PL（两阶段锁）需要：

事务开始时取锁
锁被占时等待
事务结束时释放锁
死锁检测

在 DM 上：

2PL 步骤	DM 是否能做
取锁	✓（用 RDMA CAS）
等待（被锁住时）	✗（MN 不能挂起 CN，CN 必须 spin 或回退）
释放锁	✓（RDMA WRITE）
死锁检测	✗（需要全局视图）

🌟 致命问题：2PL 的”等待”语义需要”持锁方释放时通知等待方”。在 DM 上 MN 不能做通知——CN 只能 spin 重试，等同于退化成 OCC 的 abort+retry。所以 2PL 在 DM 上没有任何优势，全部论文都用 OCC。

6.2 为什么不是 Pessimistic + Spin

理论上 CN 可以 spin 等锁释放：

   while (rdma_cas(lock_addr, expected=0, swap=tx_id) != 0) {
       cpu_relax();
   }

问题：spin 占满 NIC atomic IOPS。一个 spin 循环每 µs 发一次 CAS，10 个 spin 客户端 = 10 Mpps，直接打爆 atomic 上限。

⭕ 互补：少量 spin 可以接受（lock 即将释放时）。但作为默认协议路径不可行。OCC 是更好的选择：失败就 abort，不浪费 NIC 资源。

6.3 OCC 在 DM 上的天然优势

OCC 性质	为什么适合 DM
无锁等待	不需要 MN 维护等待队列
失败 abort	不浪费 atomic IOPS（spin 才浪费）
commit 用 CAS 取锁	RDMA CAS 是 native 支持
验证用 read 重读版本	RDMA READ 是 native 支持
不需要远端 active 参与	完美匹配 passive MN

🌟 结论：OCC + 单边 RDMA 原语是 DM 事务的”自然语言”——这不是某篇论文的发明，是硬件约束下的必然。

6.4 例外：FaSST 用 two-sided

FaSST（OSDI’16）是个反例——它论证 two-sided（SEND/RECV）有时比 one-sided 快。但：

它不否认”远端必须能跑应用 CPU”——所以本质上 FaSST 是”轻 active server” 不是纯 DM
它的高吞吐来自”远端 batch 处理”——这跟 DM 哲学相反

🍎 结论：FaSST 是历史上探索过的另一条路，但主流 DM 事务（FORD/Motor/LOTUS/AURA）都选 OCC + one-sided。

7. 5 秒判别工具：4 个问题

拿到任何新论文/系统，问 4 个问题，30 秒内定位它在地图哪个角落：

7.1 Q1：远端节点跑应用 CPU 吗？

答案	含义
跑（有 application thread）	不是 DM。是共享存储 / 经典分布式 / 单机
不跑（只 NIC 处理 RDMA）	是 DM 候选

7.2 Q2：主路径用 RDMA 单边原语吗？

答案	含义
是（READ/WRITE/CAS/FAA 为主）	DM
否（RPC / SEND / TCP）	不是典型 DM

7.3 Q3：默认并发控制是 OCC 吗？

答案	含义
是	主流 DM 路径
否（2PL）	罕见或非纯 DM

7.4 Q4：锁权威在哪里？

答案	含义
MN	第一代 DM（FORD/Motor/CREST）
CN-static	LOTUS 派
CN-dynamic	AURA 派
多副本	未来开放方向

7.5 一个练习：判断 NAM-DB

NAM-DB（VLDB’20）声称是 DM 数据库。用 4 问：

Q1：远端跑 CPU 吗？部分跑（NAM-DB 有 active server thread 处理批量请求）
Q2：主路径单边原语？部分（用 RDMA WRITE 但也用 RPC）
Q3：OCC？是
Q4：锁权威？远端

🌟 判别：NAM-DB 是半 DM——介于纯 DM（FORD）和共享存储（Aurora）之间。这种系统在 paper 里通常叫”NIC-attached database”，不是严格 DM。

8. 领域边界外：哪些系统看起来像 DM 但其实不是

8.1 InfiniSwap（NSDI’17）

InfiniSwap 把远端 RDMA 内存当 swap 用。不是 DM 事务——它解决的是 OS 层的内存扩展，不涉及事务语义。但它是 DM 概念的早期工程实现，被频繁引用。

8.2 LegoOS（OSDI’18）

LegoOS 把 OS 拆分成多个 monitor（process / memory / storage 解耦）。不是 DM 事务——它是 OS 概念，不直接处理事务。但它确立了 disaggregation 的设计哲学。

8.3 RAMCloud / FaRM-KV

这些是 KV 系统，不是事务系统。如果只支持 GET/PUT/DELETE 没有跨 key 一致性，就不属于 DM 事务范畴。

8.4 Mooncake / DistServe（KV-cache 池）

Mooncake / DistServe 是 LLM 推理的 KV-cache 共享系统。不是 DM 事务——它的 KV-cache 是 LLM 的 attention 状态，不是数据库事务。但它用了 DM 的硬件（RDMA + remote memory），所以经常被一起讨论。

8.5 CXL Memory Pool（Pond / TPP）

CXL pool 是新一代 disaggregation 硬件。目前没有 CXL-native DM 事务系统——CXL 上跑 DM 事务是开放方向（§9 详述）。

8.6 经验法则：领域边界

   是 DM 事务必须满足：
   ────────────────────
   1. 远端 passive memory（不跑 application CPU）
   2. 主路径单边原语（RDMA / CXL.mem）
   3. 处理事务级一致性（不只是 KV）
   4. 跨节点协议不依赖远端 active 参与
   
   缺任何一条 → 不是严格 DM

🌟 建议：写 paper / 报告时不要说”我们做了 DM 事务”如果你的系统不满足以上 4 条——审稿人会挑刺。老实说”我们做了 NIC-attached database”或”shared-storage txn”更安全。

The Datacenter as a Computer (Barroso et al., 3rd ed., 2018) —— Warehouse-scale computing 奠基
A Survey on Disaggregated Memory (Wang et al., 2023) —— 早期综述
模块十三第 1 章什么是分离式内存：本仓库 docs/guides/模块十三-新型互联与远程内存系统/第1章-什么是分离式内存.md

关键论文

FaRM (Dragojević et al., NSDI’14)：USENIX 链接 —— 首篇系统性 DM 事务，确立 OCC + 单边原语范式
LegoOS (Shan et al., OSDI’18)：arXiv 1810.01632 —— Disaggregated OS 概念奠基，DM 哲学源头
FaSST (Kalia et al., OSDI’16)：USENIX 链接 —— 反直觉论证 two-sided 的存在意义
Spanner (Corbett et al., OSDI’12) —— 经典分布式事务对照
Aurora (Verbitski et al., SIGMOD’17) —— 共享存储数据库对照
NAM-DB (Zamanian et al., VLDB’20) —— 半 DM 数据库的代表

行业讨论

Disaggregated Memory in Production（HPCA / OSDI tutorial）
Why DM is the next stack of cloud infra（行业博客）

框架文档

CREST 仓库 —— 后续章节实战载体
Spanner / Cockroach 文档 —— 作为对照参考

搜索