AIInfra学习路线
分离式事务的动态锁所有权 学习路线
围绕 AURA 论文系统化拆解 DM 事务的 atomic IOPS 物理瓶颈、动态锁所有权设计、在线学习与迁移协议、闭环控制与端到端复现的完整学习路线
Disaggregated Memory RDMA OCC Lock Ownership AURA AdaptX LOTUS CREST 分离式事务
模块十三的第 4 章已经把 FORD / Motor / LOTUS / AdaptX 的 design space 横向串了一遍。但当一个研究生真的要在这个方向上做工作时，光知道”有这些系统”远远不够——他需要知道为什么要走动态锁所有权这条路、cohort 怎么定义、迁移协议怎么不丢一致性、实验怎么设计才说服得了审稿人。本路线把 AURA 这一篇论文当作主轴，把所需的 RDMA / OCC / 控制系统 / 实验方法论基础全部沉淀进来，串联 9 章内容，从立题、设计、协议、控制、实验到端到端复现，全程对齐”看完能自己实现并辩护”的标准。
作者将根据该路线编写系列文章，把 AURA 这条研究链路从问题到落地讲到工程级深度。
📑 目录
🌟 全景概览：为什么动态锁所有权是 DM 事务的下一步
DM（Disaggregated Memory）事务系统过去十年的演化主轴是**“把状态搬到远端、把动作压到 RDMA 单边原语”。FaRM、FORD、Motor 把读写、版本、commit 路径都做到 one-sided，唯独锁的获取**仍然依赖 MN（Memory Node）RNIC 的 atomic（CAS / FAA）原语。这条路径在 ConnectX-3 上被压在 ~1 Mpps，在 ConnectX-6 Dx 上 5–10 Mpps——这是物理上限，不可水平扩。一旦工作负载的写锁热点 IOPS 超过这个数字，新增 CN 不再带来吞吐增长，反而引发 retry storm 让系统反向退步。
LOTUS 第一次把锁从 MN 提到 CN，但它假设应用提供稳定的 critical field，且不支持运行时漂移。AURA 在 LOTUS 之后回答两个 LOTUS 留下的问题：
- 如果 critical field 未知或随时间漂移，怎么办？
- 锁所有权一旦放到 CN，怎么在不丢一致性的前提下迁移？
AURA 的回答是把”哪些锁该归哪个 CN”做成一个在线学习 + 闭环控制的物理设计问题：
MN（数据 + Fallback Lock）
──────────────────────────
↑ RDMA READ/WRITE/CAS（数据通路不变）
│
┌────────────┼────────────┐
│ │ │
┌─▼─┐ ┌─▼─┐ ┌─▼─┐
│CN₁│ │CN₂│ │CN₃│
│ │ ◄────► │ │ ◄────► │ │ OwnerRpc（迁移 + 跨锁簇协调）
│ ┌─┴──────┐ │ ┌─┴──────┐ │ ┌─┴──┐
│ │OwnerLock│ │ │OwnerLock│ │ │… │
│ │ Table │ │ │ Table │ │ │ │
│ └────────┘ │ └────────┘ │ └────┘
│ │ │
│ Trace → AccessGraph → CohortPlanner → MigrationCtrl
└─────────── Affinity-aware Routing ──────────────────┘
🧠 核心洞察：atomic IOPS 是固定预算，不能水平扩；唯一出路是把锁请求从 MN 路径搬走。静态搬走解决一半，动态搬走保证搬走的那部分始终对得上当前 workload。
🍎 直觉比喻：把 MN 想象成只有一个收银台的银行。LOTUS 的做法是预先把 VIP 客户分到各个支行（CN）单独服务；AURA 的做法是在线观察客流，谁多就把柜台动态搬到哪个支行——而且支行之间还能互相协作处理跨支行业务。
四个待解的核心权衡，贯穿后续 9 章：
| 权衡 | 选择空间 | 影响 |
|---|---|---|
| 锁权威位置 | MN 集中 / CN 单一所有 / CN 多副本 | atomic IOPS 压力 vs 协议复杂度 |
| Cohort 粒度 | 单 record / key_group / 大簇 | 命中率 vs 迁移成本 |
| 决策频率 | 离线 / 100ms / 5ms 闭环 | 漂移适应性 vs 抖动风险 |
| 一致性策略 | 等待迁移完成 / fallback to MN / 双权威 | 可用性 vs 实现复杂度 |
🌟 一句话主旨：AURA 把”锁放哪、谁说了算”从静态部署决策升级成在线物理设计问题——这是 DM 事务在 LOTUS 之后的下一步。
📖 章节导览
整个模块分为 14 章，从立题到复现，到工程实测拐点，再到 router-centric 重构：
| 章 | 主题 | 核心问题 | 关键产出 |
|---|---|---|---|
| 1 | DM 事务的 atomic IOPS 物理墙 | 撞墙在哪、撞墙之后会发生什么 | atomic IOPS 实测数据 + retry storm 微观图 |
| 2 | RDMA / OCC / 分离式架构必要前置 | 看 AURA 论文之前要打牢的概念 | ConnectX 代际差异表 + OCC 三阶段图 |
| 3 | 设计空间地图：DM 锁热点的 N 种解法 | LOTUS / FORD / Motor / CREST 怎么分类 | 设计空间矩阵 + Δ 表 |
| 4 | AURA 骨架：cohort、ownership、状态机、不变式 | 12 个模块、I1–I4、3 状态机怎么协同 | 模块架构图 + 不变式速记 |
| 5 | 在线学习与 cohort 划分 | AccessGraph 怎么建、cohort 边界怎么决定 | merge/split 决策伪代码 |
| 6 | 迁移协议：freeze-drain-handoff-publish | 4 阶段时序、epoch 单调、fallback corner case | 时序图 + 不变式证明草图 |
| 7 | 闭环控制：AdaptX 折叠进 AURA | Loop A 反压、Loop B NIC counter、5ms 为什么是 5ms | 控制环 ASCII 图 + 抖动分析 |
| 8 | 实验方法论：把故事讲圆的工程套路 | baseline 设计、bootstrap CI、negative regimes | 实验脚手架清单 |
| 9 | 端到端实战：CloudLab/APT 复现 AURA | reservation → bootstrap → run → CI 计算 | 一键脚本 + 故障速查 |
| 10 ⭐ | 从 §3.3 到 W13：访问图的工程实操与采样队列踩坑 | typed edges C_ww/C_wr/C_rr 为什么必须区分、EWMA decay 半衰期推导、thread_local batch 为何丢尾、α=0.3 的物理含义 | 访问图代码 walkthrough + 钩点对比表 + 硬件 α 估算表 |
| 11 ⭐ | W14 Cohort merge 的稳定性陷阱：union-find、Jaccard 与倒排索引 | cohort_id 漂移、朴素 Jaccard 把控制线程冲飞（1500×250）、W14.h 倒排索引砍到 ~50；“1229 cohort + 100% inheritance + LOCAL hit 0.3%” 反直觉 | streak 迟滞 + 倒排索引代码 + 反直觉分析 |
| 12 ⭐ | W15 / W16 / W18：跨 CN 一致性的两条独立路径 | 事务级路由 vs 跨 CN owner 共识两条线、为什么 W15 走 TCP 不走 RDMA（slot 256B 装不下 NewOrder ~450B）、bootstrap bias 修复 | TransactionRouter::Resolve + ProxyTxnQueue cv 握手 + access summary heartbeat |
| 13 ⭐ | 从 +3.76% 到 +1.06%：OwnerMap 广播的工程教训 | +3.76% headline 怎么挣的、W8.7 -1.42pp 折损分账、W8.11 砍 RPC 33× 只补 0.11pp、真瓶颈是 per-Apply 本地 Publish | 完整 ablation 表 + 真瓶颈识别方法论 + 可推广教训 |
| 14 ⭐ | Router-centric 重构与 9216 cohort 全表展开 | per-CN 控制环留下的 2 个结构性问题、AURA-router-centric 在 H-Store/VoltDB/Calvin/TiDB 谱系里的位置、9216 cohort 全表展开的算账、OwnerLockTable::InstallCohort 幂等性陷阱（LOCAL 命中 17% 但 atomic 没降的真因） | 8-phase R0-R7 重构地图 + 5 系统谱系对比表 + EvictCohort+InstallCohort 修复 + 下一步 lever（W9 REMOTE_OWNER takeover / client-side dispatch） |
🍎 学习顺序建议：第 1-2 章必读，建立”为什么要做”和”做之前需要懂什么”的基础；第 3 章看完你应该能默写 LOTUS 与 AURA 的 Δ；第 4-7 章是 AURA 设计的核心，按顺序啃；第 8-9 章在你已经准备发起实验时再读。第 10-13 章是工程实测进阶层——已经跑通第 9 章的端到端实战之后，对照 ablation 拐点 + 反直觉收益再读，里面的工程教训才咬得住。第 14 章是架构重构层——当 per-CN 控制平面被 ablation 链推到性能/一致性边界时，把控制平面拎到 router 进程是 OLTP 谱系（H-Store/VoltDB/Calvin/TiDB）的标准答案，本章把 AURA Phase R-big 8-phase 重构和暴露出的 InstallCohort 幂等性陷阱一并讲透。如果只是想理解 AURA 设计可以跳过 10-14；如果要真正改 AURA 代码或在其上做研究，10-14 章必读，14 章对应论文 §3 d1cde1e 的最新重写。
⏳ 里程碑论文时间线
2014 ──── FaRM (Dragojević et al., NSDI'14) 首篇系统性 RDMA OCC，奠基 DM 事务范式
2018 ──── LegoOS (Shan et al., OSDI'18) Disaggregated OS 概念奠基
2018 ──── DrTM+H (Wei et al., OSDI'18) hybrid verbs 调度
2022 ──── FORD (Zhang et al., FAST'22) 单版本 DM 事务，cache-line 对齐锁
2024 ──── Motor (Wu et al., OSDI'24) MVCC + 一致版本表
2025 ──── LOTUS (Liu et al., arXiv'25) 首次把锁提到 CN，应用提供 critical field
2025 ──── CREST（开源 DM 事务系统） 开源实验框架，多层抽象
2026 ──── AURA (this guide, 2026) ★ 在线学习 + 闭环控制 + 动态锁所有权迁移
🍎 阅读顺序建议：
- 打底：LegoOS（理解 disaggregation 哲学）→ FaRM（RDMA OCC 鼻祖）
- DM 事务谱系：FORD（单版本）→ Motor（MVCC）→ LOTUS（锁分离）→ AURA（动态锁所有权，本路线主轴）
- 横向工具：CREST 源码（实验载体）+ ConnectX-3/5/6 atomic 行为差异
🛠️ 设计空间速查表
锁热点应对策略
| 策略 | 代表系统 | 假设 | 局限 |
|---|---|---|---|
| MN-only（基线） | FORD / Motor | 网络快、atomic IOPS 够用 | 工作负载一热就触顶 |
| 细粒度 OCC + MVCC | CREST | cell-level CC + masked-CAS 减少 false conflict | 锁仍在 MN，atomic IOPS 仍是上限 |
| 数据迁移 | MorphoSys / Lion 类 | 数据可被搬移 | DM 架构下违反 disaggregation 原则 |
| Routing-only | CREST 之上的路由扩展 | 把热点请求集中到同一 CN | 不减 atomic 总量 |
| Static owner partition | LOTUS | critical field 已知且稳定 | 漂移工作负载退化 |
| Dynamic owner placement（per-CN 控制环） | AURA W7.4-B → W8.11 | 无需先验、在线学习 | 4 CN race-publish + per-Apply Publish 是隐性瓶颈（第 13 章） |
| Dynamic owner placement（router-centric） ⭐ | AURA Phase R-big（本路线第 14 章） | 控制平面单一发布者、CN 仅作执行体 | 9216 cohort 全表展开 + InstallCohort 适用范围漂（第 14 章） |
AURA 关键模块
| 模块 | 职责 | 章节 |
|---|---|---|
| TraceCollector | 收集事务访问轨迹 | 第 5 章 |
| AccessGraphProfiler | 在线建权重图 | 第 5 章 |
| LockCohortGenerator | 决定 cohort 边界（merge/split） | 第 5 章 |
| OwnershipPlanner | 决定每个 cohort 的 owner CN | 第 5 章 |
| TransferController | 执行迁移 4 阶段协议 | 第 6 章 |
| OwnerMapPublisher | 发布 epoch + OwnerMap 快照 | 第 6 章 |
| AffinityRouter | 客户端按 OwnerMap 路由事务 | 第 4 章 |
| TxnExecutor | 在 owner CN 上执行事务 | 第 4 章 |
| OwnerLockTable | CN 本地锁表 | 第 4 章 |
| OwnerRpc | CN 间锁请求 / 跨 cohort 协调 + CN→router 反向 access summary 上报 | 第 4 / 14 章 |
| FallbackLock | 回退到 MN atomic CAS | 第 6 章 |
| AuraStats | 监控指标（NIC 计数、abort 率） | 第 7 章 |
| RouterControlLoop ⭐ | router 进程 100 ms tick 聚合 + 发布 manifest | 第 14 章 |
| AggregatedAccessGraph ⭐ | router 端聚合 CN 上报的 access summary | 第 14 章 |
| OwnerMapSubscriber ⭐ | CN 端拉 memcached manifest + 安装 9216 per-bucket cohort | 第 14 章 |
三种状态与不变式
| 状态 | 含义 | 进入条件 | 退出条件 |
|---|---|---|---|
| OWNED | 某 CN 唯一持有该 cohort | 迁移成功 | 触发 split / merge / migrate |
| TRANSFERRING | 正在迁移中，请求被 drain | 迁移开始 | 迁移完成 / 超时 |
| FALLBACK | 退回 MN atomic 路径 | owner 失败 / 冷数据 | 工作负载再次变热 |
| 不变式 | 内容 |
|---|---|
| I1 | 任一时刻同一 cohort 的权威只在一处 |
| I2 | epoch 单调递增 |
| I3 | 迁移期间所有未完事务必须 drain 或 abort |
| I4 | 数据 commit 路径不依赖锁所有权位置 |
🧭 新人破局指南
学习路径（推荐 4-6 周）
第 1 周：立题与基础
- 读完第 1 章 + 第 2 章
- 在 APT 集群跑
ib_atomic_bw实测 ConnectX-3 atomic 上限 - 在 CloudLab c6525 跑同样测试，对比 ConnectX-6 数字
- 目标：能用一句话说清”为什么 DM 事务必须改”
第 2 周：相关工作 + AURA 骨架
- 读 FORD / Motor / LOTUS 三篇 paper（精读 commit 路径与锁路径）
- 读完第 3 章和第 4 章
- 默画 AURA 12 模块协同图
- 目标：能徒手画出 AURA 与 LOTUS 的 Δ 表
第 3-4 周：AURA 核心设计
- 读完第 5 / 6 / 7 章
- 在草稿上把 freeze-drain-handoff-publish 的 4 阶段时序写出来
- 推演两个 corner case：(a) 迁移中 owner CN 挂；(b) 跨 cohort 事务遇上 split
- 目标：能向人复现 AURA 论文 §3 的所有图
第 5 周：实验方法论
- 读第 8 章
- 把模块十三第 4 章的 baseline 拿出来对照 AURA paper 实验设计
- 自己写一个 bootstrap CI 脚本（参考 PROGRESS.md 的工程笔记）
- 目标：能独立设计一组对 AURA 不利的实验（critic 视角）
第 6 周：动手复现
- 第 9 章实战
- 在 CloudLab d6515 / Utah c6525 上跑通一组数据点
- 把数据填进 paper 的 §6 模板
- 目标：拿到一个可写进 paper 的 figure
第 7-8 周：工程实测拐点（进阶，可选）
- 读完第 10 / 11 / 12 / 13 章
- 对照自己第 6 周跑出来的数据，画一张 W7.4 → W8.5 → W8.7 → W8.10 → W8.11 折损链
- 用第 13 章的”真瓶颈分账法”逐行解释为什么每加一层一致性吞吐就掉一点
- 思考 W8.12（per-tick local Publish）这条未来 lever 的实现细节
- 目标：能在 PC 上给审稿人 / 同行徒手解释”+3.76% headline 为什么落到 +1.06%“，并指出 next lever 在哪
第 9 周：架构重构层（进阶，可选）
- 读完第 14 章
- 在自己的笔记里默画一张 Phase R-big 数据流（CN → router → memcached → CN OwnerMapSubscriber → OwnerLockTable → TxnIO route），标注 8 个 LOG_INFO 探针位置
- 把第 14 章 §2 的 H-Store / VoltDB / Calvin / TiDB / AURA-router-centric 谱系表自己补完，加一列”如果让你重做 AURA，你会借哪一家最多”
- 推演一遍 §6 的 InstallCohort 幂等性陷阱：能用三句话说清”代码没错、适用范围变了、可观测性 SLO 在 atomic counter 而不在 LOG_INFO”
- 目标：能说清 router-centric 是不是 AURA 的”必经一步”，并预测 W9 REMOTE_OWNER takeover + client-side cohort-aware dispatch 谁先做谁后做
三个高频踩坑
- 把”锁提到 CN”等同于 LOTUS：LOTUS 是静态 + 应用先验，AURA 是动态 + 在线学习。两者方法论上是代差，不是性能增量。看到 paper 里有人混淆，第一时间纠正。
- 以为 cohort 必须连续：cohort 是 key_group 的任意子集，不要求 key 在物理空间相邻。这是 AURA 在 TPC-C 里能 cross-table 聚簇的前提（NewOrder 跨 7 张表但都共享 wid）。第 4 章会展开。
- 把闭环窗口当成”越短越好”：5ms 是抖动 / 反应速度 / NIC counter 噪声 / 迁移成本平衡的结果，不是越短越好。第 7 章会用频谱分析说清楚。
核心思维：动态锁所有权 = 在线物理设计
| 优化 | 牺牲 | 换取 |
|---|---|---|
| 静态 owner（LOTUS） | 应用先验、漂移退化 | 实现简单、单次部署 |
| 动态 cohort 划分（AURA） | 实现复杂度 | 工作负载漂移自适应 |
| 闭环 5ms 窗口 | 决策抖动风险 | 跟随热点漂移 |
| epoch + drain 迁移 | 短暂 stall | 不丢一致性 |
| Fallback to MN | 局部低效 | 故障安全 + 渐进部署 |
🌟 理解了这张表，就掌握了本模块核心思维：没有”零代价的动态”，只有 trade-off 选择。AURA 的贡献不是”更快”，而是”在更弱假设下仍然可行”。
📚 参考资料
综述与背景
- The Datacenter as a Computer (Barroso et al., 3rd ed., 2018) —— Warehouse-scale computing 奠基书
- A Survey on Disaggregated Memory (Wang et al., 2023) —— 分离式内存早期综述
关键论文（DM 事务谱系）
- FaRM (Dragojević et al., NSDI’14) —— 首篇系统性 RDMA OCC：USENIX 链接
- FORD (Zhang et al., FAST’22) —— 单版本 DM 事务：USENIX 链接
- Motor (Wu et al., OSDI’24) —— MVCC + 一致版本表：USENIX 链接
- LOTUS (Liu et al., arXiv’25) —— 静态锁分离 + 100ms 反应再均衡（首次把锁提到 CN）
- CREST（开源 DM 事务系统） —— 针对高冲突倾斜负载的 DM 事务系统：cell-level OCC + MVCC + masked-CAS commit，自实现 from scratch，仓库内置 FORD / MOTOR 对比 baseline。本路线第 8/9 章实战载体
- AURA (本路线主轴, 2026) —— 动态锁所有权 + 闭环控制 + 在线 cohort 学习
关键论文（参照与对比）
- MorphoSys (Lemur et al., VLDB’21) —— 数据物理设计在线学习的代表
- Lion (Yan et al., 2024) —— 访问图驱动 partition 重排
- DrTM+H (Wei et al., OSDI’18) —— Hybrid verbs 调度
- Pond (Li et al., ASPLOS’23) —— Microsoft 云端 CXL 1.1 实测
工业系统与代码
- CREST：本路线第 8/9 章实战载体（开源 RDMA 事务框架）
- Mellanox OFED 4.9：ConnectX-3 兼容最后一版（APT 集群必装）
- rdma-core：Ubuntu 22.04 inbox 驱动（ConnectX-5+ 可用）
实战环境
- CloudLab：cloudlab.us —— c6525-25g（ConnectX-6 Dx）/ d6515 是主战场
- APT cluster (Utah)：c6220 + ConnectX-3 56Gb IB —— LOTUS 同硬件复现 + 跨硬件对照
- perftest：
ib_atomic_bw/ib_read_bw是测 atomic IOPS 物理上限的标准工具