第1章：AURA 是什么 —— 把锁所有权变成在线物理设计

读 AURA 论文最大的陷阱是：太早扎进 freeze-drain-handoff-publish 的协议细节，反而忘了这篇 paper 真正想解决的问题、想反驳的对手、和它在系统谱系里的位置。本章是整本教程的”地基章”——用 30 分钟让你能向任何人讲清楚 AURA 的一句话主张、它在 LOTUS / Calvin / H-Store 这条谱系里的坐标、四个不变式 I1–I4 是什么、Router-Centric 部署为什么不是”重新引入单点”。读完你能不打开论文就回答：“AURA 解决什么、不解决什么、它的最低承诺是什么”。

1. 一句话主张：在线物理设计 + Router-Centric 集中编排

AURA 的论文 abstract 把一句话讲得比较学术，把它翻成工程师可记忆的版本：

🌟 AURA 主张：把”哪些锁该归哪个 CN 持有、什么时候搬”从静态部署决策升级成在线物理设计问题——用一个 router 进程集中维护的”访问图 → cohort 学习 → ownership planning → migration → affinity routing”闭环，让锁所有权在不丢一致性的前提下跟随工作负载漂移。

把这句话拆成四个可独立辩护的小主张，每一个都是后续某一章的核心：

小主张	对应章节	它在反驳谁
(a) 锁热点是 DM 事务的物理上限，不是工程问题	第 2 / 3 章	”再优化一下 batch 就好了”派
(b) 把锁提到 CN 是必要但不充分，必须支持运行时漂移	第 3 / 4 章	LOTUS 静态分配派
(c) Cohort 是 key_group 的逻辑子集，不要求物理相邻	第 5 章	”partition 必须连续”派（H-Store 朴素版）
(d) 控制平面要做在 router 进程，不能 per-CN 自治	第 4 / 8 章	per-CN race-publish 派（AURA v0 自己）

🍎 直觉比喻：把 MN（Memory Node）想象成只有一个收银台的银行总行。

FORD / Motor 的做法是”所有客户都到总行收银台排队”——atomic IOPS 一旦爆掉，新增 CN 不再带来吞吐增长。
LOTUS 是预先把 VIP 客户分到各支行（CN）单独服务——但要求你先知道谁是 VIP、且 VIP 名单不变。
AURA 是在线观察客流、谁多就把柜台动态搬到哪个支行，柜台搬动期间也不丢一致性；并且支行之间还能互相协作处理跨支行业务（OwnerRpc 慢路径）。
Router-Centric = 银行总部派一个”客流调度中心”集中下发”柜台分布图”，各支行执行；而不是各支行自己投票决定怎么搬。

🧠 关键洞察：atomic IOPS 是固定预算（ConnectX-6 Dx ~5–10 Mpps，这是物理上限），不能水平扩。唯一出路是把锁请求从 MN 路径搬走。静态搬走解决一半（LOTUS），动态搬走保证搬走的那部分始终对得上当前 workload（AURA）。

2. AURA 在 DM 事务谱系里的位置

把 DM 事务系统按”锁住哪里”这一条轴串起来，AURA 的坐标就一目了然：

                    锁的物理位置（atomic IOPS 压力轴）
   高 ◄──────────────────────────────────────────────► 低
        FaRM ── FORD ── Motor ── CREST ── LOTUS ── AURA
        │       │       │       │         │       │
        │       │       │       │         │       └─ Router-Centric 集中编排
        │       │       │       │         │            + 在线 cohort 学习
        │       │       │       │         │            + 闭环迁移
        │       │       │       │         └─ 应用提供 critical field, 静态
        │       │       │       └─ cell-level OCC + masked-CAS（仍在 MN）
        │       │       └─ MVCC + 一致版本表（仍在 MN）
        │       └─ 单版本 + cache-line 对齐锁（仍在 MN）
        └─ 首篇 RDMA OCC，奠基（锁全在 MN）

🍎 学习顺序：

先读 FORD：DM 事务最小骨架，理解为什么”single-version + cache-line 对齐”已经把单边路径推到极致——但锁还在 MN
再读 Motor：MVCC + 一致版本表，知道了为什么”换数据结构”救不了 atomic IOPS
再读 LOTUS：第一次有人把锁提到 CN，但你会发现它默认你知道哪些字段是热的
最后读 AURA：在线学习 + Router-Centric 集中编排 + 动态迁移

每一篇都比上一篇多解决一个具体问题。AURA 不是革命，是把 LOTUS 留下的两个补丁补完：critical field 漂移、所有权迁移的一致性。

🌟 一句话定位：AURA = LOTUS + 在线学习 + 集中编排 + 一致性迁移协议。

📎 工程踩坑视角：模块十五第 3 章把这张谱系展开成了”5 种 DM 锁热点应对策略” Δ 表，对照看会更清楚每一档放弃了什么。

3. 它要反驳的两个直觉

学习 AURA 之前，先把两个常见的”想当然”在脑子里破掉，否则后面读到 §3 和 §4 会反复被卡。

直觉 1：再优化一下 batch / coalescing 就能压住 atomic 热点

错。 atomic IOPS 是 RNIC 的固定预算：

网卡代际	atomic IOPS 上限（实测，64B CAS）
ConnectX-3	~1 Mpps
ConnectX-5	~3–4 Mpps
ConnectX-6 Dx	~5–10 Mpps

这不是软件层能优化的：

batch 8 个 CAS → MN RNIC 仍按 8 个独立 atomic 处理（不像 RDMA READ 可以 inline scatter-gather）
coalescing 写锁请求 → 只能减少 client 端发起次数，不减 MN 端原子处理次数
加 outstanding queue → 队列堆深，吞吐还是上限

🌟 结论：这是物理上限，不是工程问题。这是 AURA 第 1 句 motivation 站得住的根本原因。第 2 章会把 RNIC 内部为什么这么慢讲清楚（PCIe round trip + atomic 单元串行化）。

直觉 2：把锁提到 CN 就解决问题了（LOTUS 已经做完了）

也错。 LOTUS 解决的是”锁权威位置”这一个轴，留下两个 AURA 必须补的洞：

LOTUS 留的洞	AURA 怎么补
应用必须提供 critical field（“哪些字段是热的”）	在线建访问图、自动学 cohort（第 5 章）
没有运行时迁移协议（critical field 漂移就退化）	freeze-drain-handoff-publish 4 阶段（第 7 章）

🧠 关键洞察：LOTUS 的假设”critical field 稳定且已知”在真实 OLTP 里经常不成立——TPCC 的 hotspot 会随 warehouse 数量、客户分布、节假日变化漂移；YCSB 的 hotspot 直接是模拟参数 θ 控制的。一旦漂移，LOTUS 退化成 FORD/Motor。

🍎 直觉比喻：LOTUS 像是开学之前就把宿舍楼分配好——新生一来直接住进去就行。但学校真实运作中，宿舍调换是常态（学生退学、转专业、扩招）。AURA 是引入一个”宿舍管理处”，在线观察人员流动，按需调整 + 调整期间宿舍权属不混乱。

4. 不变式 I1–I4：AURA 的”最低承诺”

AURA 的整个协议都围绕 4 条不变式展开——这是它能向 reviewer 做出的最低承诺，论文 §3.2 + §4 给出形式化定义，工程上记住下面这张表就够：

不变式	内容	违反会发生什么
I1	任一时刻同一 cohort 的权威只在一处（owner CN 或 fallback 到 MN）	双写、数据损坏
I2	epoch 单调递增，旧 epoch 的 manifest 不能覆盖新 epoch	路由错乱、stale ownership
I3	迁移期间所有未完事务必须 drain 或 abort，新事务等到新 owner 就位	事务路由到旧 owner 提交，新 owner 不知情
I4	数据 commit 路径（RDMA WRITE + masked-CAS）不依赖锁所有权位置	故障路径打不通，回滚 fallback 失败

🌟 结论：这 4 条是 AURA 设计的”地板”。所有 §3 的算法、§4 的协议都是为了维持这 4 条。第 7 章会把每条的违反 corner case + 协议怎么挡逐一讲透。

🧠 关键洞察：

I1 是数据正确性的根，对应 §4 的 freeze-drain-handoff
I2 是路由收敛的根，对应 §3.6 的 Manifest publish + monotone epoch
I3 是迁移期间无锁丢失的根，对应 §4 的 drain
I4 是故障安全的根，让 AURA 在 owner CN 挂掉时可以回退到 MN atomic CAS，而不是整个集群停摆

🍎 直觉比喻：把 I1–I4 想象成宿舍调换时的四条物业规章：

I1 = 任何时刻，一间宿舍只能有一个负责人（不能同时挂两个名字）
I2 = 宿舍分配表只能往新版本走，旧版本作废
I3 = 调换期间，新住客拿到钥匙之前，旧住客已经把行李清空
I4 = 万一新住客没出现，物业能直接接管这间宿舍（fallback to MN）

📎 工程踩坑视角：模块十五第 14 章 §6 讲过 OwnerLockTable::InstallCohort 的幂等性陷阱——本质就是 I1 在工程层面的实现细节没做对。第 7 章会把这个 corner case 讲清楚。

5. Router-Centric 主张：不是单点，是编排集中

读到 §3.8 大部分人会有一个反应：“Router-Centric 是不是把分布式系统拆回单点？是不是 router 挂了整个集群停？”

答案是：不是单点，是 OLTP 谱系的标准答案。

   控制平面（manifest 决策）  │  数据平面（事务执行）
   ──────────────────────────┼──────────────────────────
                             │
   Router 进程 ──────────────►│ 4 CN 自治
   (100ms tick 出新 manifest) │ (OwnerLockTable + TxnExecutor)
                             │
   Router 挂掉 ──── 影响 ────►│ 旧 manifest 继续生效 ✅
                              │ 事务继续提交         ✅
                              │ 不能学新 cohort       ❌
                              │ 不能迁移            ❌

🌟 结论：Router 在故障路径上只决定 manifest，不在事务执行的关键路径上。CN 端 OwnerMapSubscriber 拉取 manifest 后完全自治执行；即使 router 挂掉，旧 manifest 继续生效，集群以”无新迁移”的姿态正常工作。这和 TiDB 的 PD（Placement Driver）、Calvin 的 sequencer、VoltDB 的 partition planner 是同一档架构。

系统	集中控制平面	决定的事	失效时事务能否继续
H-Store	partition manager	哪个 partition 在哪个 site	✅ 继续，按旧 partition map
Calvin	sequencer	事务执行顺序	❌ 不能提交新事务（关键路径上）
VoltDB	partition planner	client routing	✅ 继续，按旧 plan
TiDB	PD（Placement Driver）	region 路由 + 调度	✅ 继续，按旧 region map
AURA	router 进程	manifest（cohort → owner CN）	✅ 继续，按旧 manifest

🍎 直觉比喻：把 router 想成”宿舍管理处”，CN 想成”楼栋负责人”。

宿舍管理处定期更新”宿舍分配表”贴在公告栏（manifest publish to memcached）
楼栋负责人按公告栏分表自治运作（OwnerLockTable + TxnExecutor）
宿舍管理处下班了 → 楼栋按上一版分配表继续工作，新生入住要排队等管理处上班（不能学新 cohort，但旧业务正常）

🧠 关键洞察：Router-Centric 把控制平面的决策集中，但执行下放——这是 OLTP 工业系统的标准答案，不是”重新引入单点”。第 4 章会把 AURA-router-centric 在 H-Store / VoltDB / Calvin / TiDB 谱系里的位置画清楚。

📎 工程踩坑视角：模块十五第 14 章讲过为什么 per-CN 自治控制平面（v0 → v23）在 4 CN race-publish 下走不通——这正是 Router-Centric 重构的工程动因。

6. 论文 §1 贡献清单的可复述版本

把论文 §1 末尾的”contributions”翻成你能 30 秒讲完的版本：

#	论文原文（简化）	可复述版
C1	提出”动态锁所有权”作为 DM 事务的新设计点	把锁放哪从静态部署升级成在线学习问题
C2	设计 cohort + ownership 双层抽象	cohort = key_group 任意子集；ownership = 每个 cohort 的当前 owner CN
C3	设计访问图 + cohort merge + ownership planning 在线学习算法	typed edge access graph → union-find merge → Benefit 模型挑 owner
C4	设计 freeze-drain-handoff-publish 一致性迁移协议	4 阶段时序 + epoch 单调，保证 I1–I4
C5	在 CREST 上实现并端到端验证	Router-Centric 部署 + 9216 cohort 全表展开 + CloudLab 复现

🌟 30 秒电梯讲法：

AURA 把 DM 事务里”锁放哪”从一次性部署决策升级成在线物理设计问题。它在 CN 之上加一层 router 进程，集中维护访问图、在线学 cohort、规划 ownership、协调迁移；CN 端 OwnerMapSubscriber 拉 manifest 后自治执行。所有这些都在 I1–I4 四条不变式下完成，故障时退回 MN atomic CAS 不丢一致性。CREST 上 9216 cohort 全表展开端到端跑通，在 TPCC / SmallBank / TATP 上撞墙后的 atomic 路径被有效卸载。

把上面这段背熟，你已经能应付 90% 的 paper 问答。

7. 一页定位图与第 2 章预告

把本章四个关键点叠成一页图：

            ┌──────────────────────────────────────────────────┐
            │ AURA 一句话主张                                  │
            │ 把锁所有权变成在线物理设计 + Router-Centric 编排 │
            └────────────┬─────────────────────────────────────┘
                         │
       ┌─────────────────┼─────────────────┐
       │                 │                 │
   要反驳的直觉     最低承诺(I1-I4)    架构主张
   ────────────     ──────────────    ─────────
   1. batch 救不了  I1 权威唯一        Router 集中
      atomic 上限   I2 epoch 单调      编排
   2. LOTUS 没      I3 迁移期 drain    CN 自治执行
      完成（漂移   I4 commit 路径
      没解决）        不依赖 owner

       │                 │                 │
       └─── 第2/3章 ─────┴─── 第7章 ──────┴── 第4章 ──┐
                                                       ▼
                                              第5/6/8/9章
                                              （算法/路由/实现/复现）

✅ 自我检验清单

一句话主张：能不看论文，30 秒讲出 AURA 的电梯讲法
DM 谱系：能画出 FaRM → FORD → Motor → CREST → LOTUS → AURA 的演进 + 每一步多解决了什么
反直觉 1：能解释为什么 batch 优化不能压住 atomic 热点（PCIe round trip + atomic 单元串行）
反直觉 2：能说出 LOTUS 留给 AURA 的两个洞（critical field 漂移、迁移协议缺失）
I1–I4：能徒手写出 4 条不变式 + 每条违反的后果
Router-Centric：能解释”为什么不是单点”——router 在故障路径上只决定 manifest，不在事务执行关键路径
C1–C5：能复述论文 §1 的 5 条贡献，每条都能映射到后续章节

第 2 章预告

第 2 章是预备知识章——把”读 AURA 论文前的 30 分钟知识包”打齐：

ConnectX-3/5/6 atomic 单元为什么受 PCIe 串行化拖累
RDMA OCC 三阶段（read / validate / commit）的标准实现
Disaggregated Memory 与 RDMA-attached storage 的边界
CREST / FORD / Motor 共享的基础抽象（Pool / Hash Index / Cell-level CC）

读完第 2 章你能不打开任何论文直接进入第 3 章 motivation 重读。

📚 参考资料

论文原文

AURA：本路线主轴论文，paper_lock_ownership_cn/main.pdf（本仓库内）
AURA Phase R-big 重构 §3 草稿：PHASE_R_PAPER_S3_DRAFT.md

关键论文（本章引用）

LOTUS (Liu et al., arXiv’25) —— 静态锁分离 + 100ms 反应再均衡
FORD (Zhang et al., FAST’22) —— 单版本 DM 事务：USENIX 链接
Motor (Wu et al., OSDI’24) —— MVCC + 一致版本表：USENIX 链接
FaRM (Dragojević et al., NSDI’14) —— 首篇 RDMA OCC：USENIX 链接

OLTP 谱系（§5 Router-Centric 用）

H-Store (Kallman et al., VLDB’08) —— partition manager 起点
Calvin (Thomson et al., SIGMOD’12) —— deterministic execution + sequencer
VoltDB Architecture White Paper —— H-Store 商业版
TiDB Placement Driver Design Doc —— 工业级 region routing

模块内交叉引用

模块十五第 3 章：设计空间地图：DM 锁热点的 N 种解法 —— 本章 §2 的 5 种策略 Δ 表展开版
模块十五第 14 章：Router-centric 重构与 9216 cohort 全表展开 —— 本章 §5 的工程实施版
模块二十：分离式内存事务系统全景调研 —— FORD / Motor / LOTUS / CREST 横向对比

搜索