第2章：必备底座 —— atomic 物理墙、OCC、三源 bottleneck shift

第 1 章告诉你 v27 thesis 是”事务控制路径的运行时物理设计”。但要看懂 v27 paper §2 motivation，你必须先吃透三件事：(a) 为什么 atomic IOPS 是物理墙不是工程问题、(b) OCC 三阶段每个阶段的”锁角色”差异、(c) 瓶颈不是单点漂移，而是在 CN scale-out / workload phase / mode mix 三条轴上各自漂。本章是”预备包”，没什么自家新观点，主要任务是把模块十三《RDMA & 分离式内存》+ 模块二十《DM 事务全景》+ v27 paper §2 的精华浓缩成 30 分钟读完即用的笔记。读完你能不查任何资料就回答：“为什么 CREST 撑不住 8 CN？""为什么 LOTUS 知道 critical field 就够了？""v27 又多对应了哪一种瓶颈？”

📑 目录

• 1. atomic IOPS 物理墙：ConnectX 代际表
• 2. OCC 三阶段与锁的角色
• 3. “锁放哪”三行 motivation 表
• 4. v27 修订的 thesis 段落
• 5. Bottleneck shift 的三源
• 6. 30 分钟预备包速查卡

---

1. atomic IOPS 物理墙：ConnectX 代际表

ConnectX 系列网卡上 RDMA atomic（CAS / FAA）的吞吐不是工程问题，是物理上限——硬件 atomic unit 数 × 频率 = 固定预算，无论 CPU 多强、CN 多少、PCIe 带宽多宽，都打不破。

1.1 代际数字（ibv_atomic_bw 实测）

ConnectX 代际	atomic CAS 上限	atomic FAA 上限	备注
ConnectX-3	~1 Mpps	~1 Mpps	FORD 论文时代基线
ConnectX-4	~3 Mpps	~3 Mpps	Motor 实验环境
ConnectX-5	~4 Mpps	~4 Mpps	CREST 早期
ConnectX-6 Dx	~5-10 Mpps	~5-10 Mpps	CREST v27 实验环境

CloudLab c6525-25g 配的是 ConnectX-6 Dx 100 GbE QSFP56——本教程引用的所有数据都在这台硬件上跑。

1.2 为什么物理上限不能水平扩

朴素直觉是”加 CN 就能加 atomic 吞吐”——但这是错的：

• 每个 CN 通过 RDMA atomic 操作 MN 上的某 record
• atomic 是在 MN-RNIC 硬件上执行的——硬件 atomic unit 数 × 时钟频率 = 物理预算
• 多 CN 把 atomic 压力集中到 MN 一张 RNIC上，预算反而被分摊
• → CN 越多，每 CN 能用的 atomic 配额越少

🍎 直觉比喻：MN-RNIC 像一个原子工厂的反应炉——每秒只能反应固定次数。多 CN 像往同一个反应炉送材料，材料越多反应越拥挤，不是越快。

1.3 物理墙的工程后果

CREST 在 4-CN TPC-C 上：

• 每 txn 平均 atomic ops：12.16 atomic/txn（v27 baseline 实测）
• 4 CN 总吞吐 13.64 KOPS → 总 atomic ops/sec = 13640 × 12.16 = 166 Kops
• ConnectX-6 Dx 上限 ~5 Mpps，离上限还远 → atomic 不是 4-CN 时的瓶颈

但如果扩到 16-CN：

• 假设吞吐线性扩到 13.64 × 4 = 54.56 KOPS（理想）
• 总 atomic ops/sec = 54560 × 12.16 = 664 Kops
• 仍未到 5 Mpps，但分布是否均匀又是另一回事

→ 物理墙是潜在风险，不是当下 4-CN 实验的硬瓶颈。但所有 DM 事务工作的共同长期问题就是它。

🧠 关键洞察：v27 paper 不能在 4-CN 上完整 demonstrate atomic 墙——这是 §6.6 RQ5 CN scale-out 缺失的原因之一。第 8 章会展开评测方法论。

---

2. OCC 三阶段与锁的角色

OCC（Optimistic Concurrency Control）的 3 个阶段：

                   ┌─────────────┐
                   │ Read Phase  │ ← 无锁，从 MN 拉 snapshot
                   └──────┬──────┘
                          │
                          ▼
                   ┌─────────────┐
                   │ Validation  │ ← **lock authority 关键**
                   │   Phase     │
                   └──────┬──────┘
                          │
                          ▼
                   ┌─────────────┐
                   │ Commit /    │ ← lock 仍持有，原子写
                   │   Abort     │
                   └─────────────┘

2.1 Read Phase：无锁

txn 从 MN 拉 snapshot——读 record 的当前版本 + write_ts + (CREST) 行尾 lock bit。

不需要锁——读到的版本可能是 stale 的，但 validation 阶段会检查。这是 OCC 跟 2PL 的本质差异——读阶段乐观。

2.2 Validation Phase：lock authority 关键

OCC 的核心：检查 read set 是否仍然 fresh。

• 对每个 key k in read_set，检查 k 的当前 write_ts == read 时拿到的 ts
• 如果有不一致：abort
• 如果全部一致 + 拿到所有 write_set 的 lock：proceed to commit

这一阶段必须有 lock authority —— 防止其他 txn 在 validation 同时改 read set。

2.3 Commit Phase：lock 仍持有

• 把所有 write_set 的新值原子写到 MN
• 更新每个 key 的 write_ts = commit_ts
• 释放所有 lock

Lock 在 commit 完成后才释放——保证其他 txn 看到的是 atomic 的”全部写完”或”全部没写”。

2.4 锁角色总结

阶段	是否需要 lock	锁的物理位置（CREST）	锁的物理位置（AURA）
Read	×	N/A	N/A
Validation	✓	MN 上的 row lock bit	CN-local OwnerLockTable（A2/A3 调粒度）
Commit	✓	MN 上的 row lock bit	同上

🧠 关键洞察：OCC 的锁只在 validation/commit 两阶段需要——这是为什么”在线搬锁”在 OCC 系统里可行而在 2PL 系统里几乎不可能的根本原因。2PL 锁在整个 txn 生命周期持有，搬锁会冻结整个 txn pool；OCC 锁只在最后几毫秒持有，搬锁影响窗口很小。

2.5 AURA 怎么用 OCC

AURA 不改 OCC 协议本身——它改的是 lock 的物理位置（在 MN 还是 CN）和 lock 的粒度（per-key 还是 per-cohort）。

具体细节：

• AURA 的 lock 在 CN-local OwnerLockTable（除非走 fallback 路径）
• AURA 的 lock 粒度是 per-cohort（由 A2/A3 调）
• OCC validation 仍然标准——只是查的是 OwnerLockTable 而不是 MN row lock bit

→ AURA 的 contribution 不是”换 OCC”，是”换锁的物理设计”。OCC 是 prerequisite。

---

3. “锁放哪”三行 motivation 表

v27 paper §2.2 的核心表——把 5 维度框架里的 Dim 2（仲裁位置）和 Dim 3（仲裁粒度）的设计空间用三行串起来：

放在哪	典型适用 workload	失败模式	典型代表
MN-side CAS only	冷读多 / 写争用稀 / 单 MN 容量足	MN RDMA-atomic IOPS 撞天花板	CREST / FORD / Motor
CN-local OwnerLockTable	partition 稳定 / critical field 明确 / 跨 CN 协调少	RPC fan-in on owner CN + wake-queue race	LOTUS / H-Store
Adaptive (AURA v27)	dynamic / phase-changing / 不可预测	需要 safe handoff protocol (I1/I2/I3)	AURA v27

3.1 每行的物理含义

MN-side CAS only：所有 acquire/release 走 MN-RNIC 的 atomic 操作。

• 优势：协议简单（每次 CAS 直接是事实），无需 CN 间协调
• 劣势：MN-RNIC 的 atomic IOPS 是物理墙；MN-CPU 没事干（一切都在硬件 CAS）

CN-local OwnerLockTable：每个 partition / cohort 由唯一 CN 持有锁。

• 优势：lock acquire 跟 OCC validation 同 CN 内存，亚微秒级
• 劣势：跨 CN txn 需要 RPC 到 owner CN；owner CN 死锁风险（第 7 章 W11 故事）

Adaptive：planner 在线决定哪些 cohort 走 CN-local、哪些走 MN-CAS fallback。

• 优势：跟随 workload 漂移，避开静态分配的局部最优
• 劣势：需要 safe handoff protocol（第 6 章详述）

3.2 三行表的故事价值

这张表是 paper §2.2 motivation 的精华——读者读完应能立即理解：

1. 为什么 CREST 之后 LOTUS 是合理的进化（MN-CAS → CN-local）
2. 为什么 LOTUS 之后 AURA 是合理的进化（静态 CN-local → 自适应）
3. AURA 不是”颠覆 CREST/LOTUS”，是”在它们之间动态选择”

🍎 直觉比喻：CREST = 全国统一银行总行收银台；LOTUS = 静态分配的支行系统；AURA = 在线调度的支行系统。三者解决同一问题（怎么排队），只是控制粒度不同。

🧠 关键洞察：DM 事务的设计空间不是”MN vs CN”二选一，而是”在两个极端之间选一条曲线”——AURA 在这条曲线上动态滑动，CREST 在最左端，LOTUS 在曲线中间某点（静态）。

---

4. v27 修订的 thesis 段落

v27 §2.3 把 v26 的 thesis 做了一次修订：

v26 旧版：

Data stays on MN, only locks move.

v27 新版：

Master data stays on MN. Read-only cached replicas may live on CNs proportional to per-CN access frequency.

4.1 为什么改

两个动机：

1. 不要堵死 B5 (CN cache) 的未来工作接口——v25 的 thesis 说”data stays on MN”，这跟”CN 上有 cached replica”逻辑上矛盾。改成”master 在 MN”就把 cache 留为合法的 future work。
2. 跟控制平面 vs 数据平面的清晰分界对齐——AURA 改的是控制平面（lock / cohort / owner），不改数据平面（master record）。修订后的 thesis 明确这条边界。

4.2 修订的语义影响

v26 thesis 的语义：data 是不动的、整体的、唯一的。 v27 thesis 的语义：data 分两层——master（不动）+ cached replica（v27 不做但未来可以）。

→ v27 thesis 是 v26 thesis 的严格扩展——v26 的所有 claim 在 v27 thesis 下仍成立。但 v27 thesis 多留了 future work 的”空间”。

4.3 跟 paper §1 thesis 的关系

第 1 章 §2 的 thesis 是 v27 §1 的全文版——讲”事务控制路径的运行时物理设计”。 这一节的 thesis 是 v27 §2.3 的细化——讲”数据怎么分层”。

两者是互补的两个抽象层级——前者讲 control 层（AURA 改）、后者讲 data 层（AURA 不改 master，留 replica 为 future）。

---

5. Bottleneck shift 的三源

v27 §2.4 论证”瓶颈不是单点漂移，而是在三个独立维度上各自漂”。这条论证支撑 §1 thesis（“runtime physical design 必要”）。

5.1 三源逐条

第 1 源：CN scale-out

• 描述：CN 数从 1 到 8 到 16，atomic IOPS 总需求线性增加，但 MN-RNIC 是固定预算
• 临界点：atomic 总需求 / MN-RNIC 上限 > 80% 时，atomic 变成瓶颈
• 证据：4-CN 时离上限远；8-CN sweep 待补（§6.6 RQ5 缺失数据）

第 2 源：Workload phase change

• 描述：hot key 集合轮转（如 district_id bias 切换）
• 临界点：phase 切换周期 < 几倍 planner tick (100 ms) 时，OwnerMap 来不及适应
• 证据：drift_5sec / drift_2sec 实验（§6.3 RQ2）—— migrations 0→21/tick、splits 11→64

第 3 源：Mode mix shift

• 描述：读写比从 60/40 漂到 90/10（OLAP-ish）或 30/70 (write-heavy)
• 临界点：写比例 > 50% 时，lock cost 主导；写比例 < 30% 时，atomic cost 主导
• 证据：目前 v27 没有充分实验——是 §8 limitation 之一

5.2 三源的独立性

为什么是三源而不是三种现象？

• CN scale-out 涉及资源量级变化（atomic ops 总量）
• Workload phase 涉及resource 在 CN 间分布变化（同样总量，CN0 vs CN1 谁拿多）
• Mode mix 涉及resource type 比例变化（atomic vs lock vs RPC 谁主导）

三个维度正交——任意一个变了其他两个不变，AURA 仍要适应。

5.3 v27 的覆盖范围

三源	v27 评测覆盖	缺口
1. CN scale-out	× 缺 (1/4/8/12 CN sweep)	§6.6 RQ5
2. Workload phase	✓ drift_5sec / drift_2sec	已覆盖（§6.3）
3. Mode mix	× 未实验	§8 limitation

→ v27 paper 在三源中 cover 了 1 源（phase），另 2 源是 future work / limitation。诚实化原则再次。

5.4 跟 v25 故事的对照

v25 paper 只 cover 第 1 源——“CN scale-out 导致 atomic 墙”。 v25 paper 没讲 第 2 源——drift workload 是 v27 才引入的。 v25 paper 没讲 第 3 源——mode mix 是 v27 paper §8 的 future work。

→ v27 在 v25 之上扩了 1 源（第 2 源 phase），并列出第 3 源作为 future。

🌟 结论：三源 framing 是 v27 比 v25 更广的核心——把 “atomic 墙是唯一瓶颈”扩展到”瓶颈在三个独立维度漂”。

---

6. 30 分钟预备包速查卡

把本章 5 节的关键 takeaway 压缩成一张可贴在桌面上的卡片：

┌──────────────────────────────────────────────────────────────┐
│  AURA v27 必备底座 速查卡                                    │
├──────────────────────────────────────────────────────────────┤
│                                                              │
│  1. atomic 墙：ConnectX-6 Dx ~5-10 Mpps，物理上限不可水平扩  │
│     → 4-CN 当前不撞墙，8-CN+ 有风险（§6.6 缺数据）           │
│                                                              │
│  2. OCC 三阶段：                                             │
│     Read (no lock) → Validation (lock!) → Commit (lock!)     │
│     → 锁只在最后两阶段需要，所以"在线搬锁"在 OCC 系统可行    │
│                                                              │
│  3. 锁放哪三行表：                                           │
│     MN-CAS only (CREST) → atomic IOPS 撞墙                   │
│     CN-local (LOTUS)     → RPC fan-in / wake-queue race      │
│     Adaptive (AURA v27)  → 需要 safe handoff protocol        │
│                                                              │
│  4. v27 thesis：master 在 MN，cached replica 是 future work  │
│     (v26 旧版"data stays on MN" 太死板，v27 留 B5 接口)      │
│                                                              │
│  5. Bottleneck shift 三源：                                  │
│     1) CN scale-out （v27 ×）                                │
│     2) Workload phase （v27 ✓ drift workload）               │
│     3) Mode mix （v27 ×, §8 future）                         │
│                                                              │
└──────────────────────────────────────────────────────────────┘

6.1 一句话总结

atomic IOPS 是预算，OCC 的锁只在 validation/commit 阶段需要，把锁从 MN 搬出去就能突破预算——但搬到哪里、何时搬、怎么不丢一致性，才是 AURA 真要回答的问题。

---

✅ 自我检验清单

• atomic 墙：能给出 ConnectX-6 Dx 的 IOPS 区间数字（5-10 Mpps）+ 解释为什么不能水平扩
• OCC 锁角色：能画 OCC 三阶段图并指出哪个阶段需要 lock authority
• OCC vs 2PL：能解释为什么”在线搬锁”在 OCC 可行而在 2PL 几乎不可能
• 三行表：能默写 MN-only / CN-only / Adaptive 三行的 typical workload + 失败模式 + 代表系统
• thesis 演进：能解释 v27 把 “data stays on MN” 改成 “master stays on MN” 的两个动机
• 三源 shift：能举出 CN scale-out / phase / mode 三种 bottleneck shift 各一个例子 + v27 覆盖情况
• 三源独立性：能解释为什么三源正交（资源量级 / 资源分布 / 资源类型比例）
• CREST 撑不住 8 CN：能不查资料解释根本原因（atomic IOPS 物理墙）

---

📚 参考资料

概念入门

• 模块十三《新型互联与远程内存系统》第2章-RDMA通信原理与verbs —— RDMA verbs 基础
• 模块二十《分离式内存事务系统全景调研》第5章-RDMA利用模式 —— DM 事务里的 RDMA 用法谱系

关键论文

• FORD (FAST’22) —— Disaggregated 事务最小骨架；atomic IOPS 物理墙第一次被直接量化
• LOTUS —— 第一次提出 CN-side lock placement；本章三行表的中间行代表
• CREST —— v27 的 baseline 实现；本章三行表的第一行代表
• OCC (Kung & Robinson, TODS’81) —— OCC 协议的原始论文

行业讨论

• 模块二十三《AURA 论文精讲》第2章-必备底座-atomic物理墙与OCC与分离式架构 —— v25 时期的同主题章节
• ConnectX-6 Dx hardware documentation —— atomic IOPS 物理上限的官方依据

框架文档（代码 anchor）

• src/transaction/aura/OwnerLockTable.cc —— CN-local lock table 实现
• benchmark/TPCC/TpccBenchmarkExecutor.cc —— OCC 三阶段在 TPC-C 上的实现
• benchmark/Client/Drift.cc —— 第 2 源 phase shift 的实现

---

📎 v25 对照视角：模块二十三-AURA 论文精讲 第2章-必备底座-atomic物理墙与OCC与分离式架构 —— v25 只讲 atomic 墙 + OCC + CREST/LOTUS 三行表；v27 加入 bottleneck shift 三源 framing + master 不动 / cached replica future 的修订