第3章：论文 §2 重读 —— 从锁瓶颈到锁所有权物理设计

第 2 章把”读 AURA 论文前的 30 分钟知识包”打齐了。从本章开始进入论文章节的逐段重读——以论文 §2 (Background & Motivation) 的四个小节为骨架，把 motivation chain 拆成”为什么不能跳步”的版本。读完你能徒手画出 AURA 立题的三段论：锁瓶颈不可水平扩 → 路由 +2.4% 撞墙 → 必须把锁所有权升级成可在线设计的物理参数，并能向同行复述 5 条设计目标分别对应哪个后续章节。

📑 目录

• 1. §2 motivation chain 三段论的全景
• 2. §2.1 锁瓶颈：物理墙的论证版本
• 3. §2.2 为什么单纯路由不够：CREST 实测数据点
• 4. §2.3 从数据物理设计到锁所有权物理设计
• 5. §2.4 设计目标 5 条：各自对应后续哪个章节
• 6. 一张总图：把 §2 三段论折成一页

---

1. §2 motivation chain 三段论的全景

论文 §2 是整个 AURA 立题的”三段论”。把它压成一句话：

🌟 三段论：(A) 锁瓶颈不是软件层能优化的物理上限 → (B) 单纯客户端路由顶天 +2.4% 吞吐 → (C) 必须把锁所有权当作可在线设计的物理参数（不是搬数据、不是搬路由，是搬锁权威）。

每一段在论文里对应一节，本章按一一对应展开：

论文小节	三段论位置	本章对应 §
§2.1 远程内存事务中的锁瓶颈	A	本章 §2
§2.2 为什么单纯路由不够	B	本章 §3
§2.3 从数据物理设计到锁所有权物理设计	C	本章 §4
§2.4 设计目标	立题落地	本章 §5

🧠 读法建议：每段都先看”论文怎么写”→“它在反驳谁”→“如果跳过这一段会被人问倒在哪”。三层都过一遍才算真懂这段 motivation。

---

2. §2.1 锁瓶颈：物理墙的论证版本

2.1 论文怎么写的

论文 §2.1 三句话讲完锁瓶颈：

1. DM 事务系统都用单边 RDMA（FORD/Motor/CREST）
2. 写锁靠 RDMA atomic CAS
3. 所有 CN 的 atomic 请求汇聚到 存放锁字的 MN RNIC，AU 串行化→吞吐顶天

🌟 结论：这是结构性问题，不是配置问题。不论你怎么调 outstanding queue / batch / coalescing，AU 单点的吞吐上限不动。

2.2 它在反驳谁

反驳对象	反驳要点
”调大 NIC outstanding 就行”	AU 是 throughput-bound，加深 queue 只让延迟涨
”用 RDMA-aware OS / DPDK 优化软件栈”	软件栈优化的是 CN→NIC 一段，AU 在 MN 侧
”升级网卡（ConnectX-7）就好”	11 年从 1 Mpps 涨到 10 Mpps，不会突然到 100 Mpps
”用 two-sided RPC 替代 atomic”	RPC 让 MN CPU 介入，违反 disaggregation 原则

🍎 直觉比喻：第 1 章的”银行 ATM”+ 第 2 章的”PCIe 串行 AU”两个比喻叠在一起就是 §2.1。再加一个新的：

把 atomic 想成”印章盖戳”。MN 上只有一个印章和一个盖戳师傅。无论你寄多少快递包裹（atomic 请求）过去，师傅一秒只能盖 N 次戳。增加快递员（CN 数）只让快递在仓库门口堆得更高，盖戳速度不变。

2.3 跳过这一段会被问倒在哪

如果省掉 §2.1 直接讲 AURA 设计，reviewer 必然问：

• “你怎么证明锁瓶颈不是软件问题？”
• “升级 ConnectX-7 + RDMA-aware OS 不就解决了？”
• “为什么不能用 RPC 替代 atomic？”

🧠 关键洞察：§2.1 是 AURA 立题的”地板”——一旦 reviewer 接受”atomic 是物理上限”，后面所有的代价（迁移成本、控制平面复杂度）都好谈；不接受的话，AURA 整篇 paper 没立场。

📎 工程踩坑视角：模块十五第 1 章的 atomic IOPS 实测数据 + retry storm 微观图，是 §2.1 的工程展开版。

---

3. §2.2 为什么单纯路由不够：CREST 实测数据点

3.1 论文怎么写的

§2.2 三句话讲完 routing-only 的局限：

1. 自然想法是把访问相似数据的事务路由到同一 CN（partition-aware client routing）
2. 这在传统分布式 DB 里有效（减少跨分区事务）
3. 但 DM 上锁权威仍在 MN，路由只改变请求从哪个 CN 发出，不改变 MN AU 接收的 atomic 总数

🌟 结论：路由是必要不充分。它能降 abort（同一 CN 的事务能内部 serialize 一部分），但不能把吞吐推过 atomic 物理墙。

3.2 CREST 实测数据点（论文 Table 1）

论文给了一组很关键的实测数据，把”路由不够”量化：

实验设置	吞吐	Abort rate	观察
1 CN + 1 MN, TPC-C	208.7 KTPS	~1%	基线
2 CN + 1 MN, TPC-C	250.4 KTPS	~1%	1.20× 扩展（理想是 2×）
3 CN + 1 MN, TPC-C	235.8 KTPS	异常	总吞吐回落
随机路由	250.4 KTPS	5.6%	多 CN 基线
分区路由	256.4 KTPS	2.6%	吞吐仅 +2.4%

🧠 关键洞察：分区路由把 abort rate 从 5.6% 降到 2.6%（−3pp），但吞吐只涨 +2.4%。abort 降下来的 IOPS 预算被 retry 之外的瓶颈吃掉了——MN AU 仍是上限。

这个 +2.4% / −3pp 是 AURA 论文里最有杀伤力的一组数据，因为它**用同一个开源系统（CREST）**就证明了”路由不够”，不用搭别的 baseline。

3.3 为什么 3 CN 反而回落

注意上表第 3 行：3 CN 比 2 CN 吞吐下降。两个原因叠加：

1. AU 已经饱和：2 CN 已经把 AU 喂到接近上限，3 CN 增加的只是排队深度
2. CN 间网卡争用 + 节点稳定性（论文用 “节点异常下有效值” 描述）

🌟 结论：“加 CN 就有吞吐”是 DM 事务在 atomic 瓶颈下的一个伪命题——加 CN 到一定数量后反而退化。这是后续所有 AURA 设计的必要性根据。

3.4 它在反驳谁

反驳对象	反驳要点
”做好 partition-aware client routing 就够了”	CREST 实测 +2.4%，远低于”加一个 CN 翻倍”的预期
”abort rate 降下来就行”	abort 降 3pp，吞吐只涨 2.4%，benefit 没传到 throughput
”用 H-Store/VoltDB 那套 single-thread + partition”	那是把数据放在本地（shared-nothing），DM 数据在 MN，不能照搬

📎 工程踩坑视角：模块十五第 12 章讲过 CREST 自带的 partition-aware routing（W15 TransactionRouter::Resolve）效果有限——这是 §2.2 的工程对照。

---

4. §2.3 从数据物理设计到锁所有权物理设计

4.1 论文怎么写的

§2.3 是 AURA 立题的”代差转向”——它在说：“别学 MorphoSys / Lion 那套，DM 上要换坐标。”

论文核心句：传统分布式数据库的物理设计回答”如何分区、复制哪些数据、主副本放哪”。MorphoSys 把这做成在线（split/merge/add replica/remove replica/remaster）。Lion 把访问关系建图、聚 clump、重排副本。但 DM 上数据集中放在 MN 是资源解耦的基本假设，频繁迁移数据违反这个假设。

🌟 结论：AURA 不搬数据，搬锁所有权——锁元数据比数据小很多（一个 cohort 状态 ~几十字节），迁移成本可控。

4.2 对比矩阵：传统 vs DM 物理设计

维度	传统分布式 DB（MorphoSys / Lion）	DM 事务（AURA）
物理设计变量	数据分区 + 副本位置	锁所有权位置（cohort → owner CN）
在线动作	split / merge / add_replica / remaster	merge cohort / migrate ownership
迁移代价	数据搬运（MB–GB）	锁状态搬运（几十字节）
Disaggregation 假设	不需要	必须保持（数据留在 MN）
适用硬件	任意网络	RDMA / 字节寻址 DM

🧠 关键洞察：AURA 的”在线物理设计”是把 MorphoSys 的思想搬到 DM 上，但物理设计变量从”数据放哪”换成”锁权威放哪”。这是一个代差——不是 incremental 优化，是设计哲学的转向。

🍎 直觉比喻：

• MorphoSys / Lion = 搬家具：在线决定客厅沙发摆哪、卧室床摆哪
• AURA = 不搬家具，搬”谁有这间屋子的钥匙”

家具（数据）很大、搬起来贵；钥匙（锁权威）很小、搬起来便宜。DM 架构假设家具放在中央仓库（MN），所以 AURA 选搬钥匙。

4.3 它在反驳谁

反驳对象	反驳要点
”用 MorphoSys 那套数据迁移做 DM”	违反 disaggregation 假设，数据搬运成本高
”Lion 的访问图直接搬过来”	思路对，但搬的对象不对——AURA 借访问图思路，但搬的是 ownership 不是数据
”做个 caching 层就行（FaRM Caching）“	cache 一致性 + 写时失效仍要走 atomic

📎 工程踩坑视角：模块十五学习路线”设计空间速查表”里的”数据迁移（MorphoSys / Lion 类）“vs”动态 owner placement（AURA）“对照——这是 §2.3 的展开版。

---

5. §2.4 设计目标 5 条：各自对应后续哪个章节

论文 §2.4 列了 5 条设计目标。这一节把每条目标拆出”为什么这么定 + 对应本教程哪一章”：

5.1 G1：减少 MN Atomic

原文：对热点写集合，锁获取和释放应尽量在 owner CN 本地完成。

🎯 本教程章节：第 4 章（Router-Centric 架构）+ 第 5 章（cohort 学习）+ 第 6 章（AffinityRouter）

🌟 关键指标：atomic_per_txn —— AURA acceptance gate 之一（baseline 13.51，目标 ≤ 5）

5.2 G2：保持数据解耦

原文：数据、索引和版本主体仍存放在 MN；AURA 只改变锁所有权和路由，不要求大规模数据搬迁。

🎯 本教程章节：第 4 章 § Router-Centric 主张

🧠 关键洞察：这一条是 AURA 与 MorphoSys/Lion 划清界限的关键——AURA 不动数据，否则就退化成 MorphoSys 类。第 4 章会展开”为什么数据留在 MN 是 AURA 的硬约束”。

5.3 G3：适应工作负载变化

原文：系统应从事务流中自动学习访问亲和性，不依赖应用手工给 critical field。

🎯 本教程章节：第 5 章（访问图 + cohort 学习）

🌟 关键指标：drift_response_time —— 从 hotspot 漂移到 manifest 更新的延迟（目标 ≤ 5×100ms tick）

🧠 关键洞察：这一条是 AURA 与 LOTUS 划清界限的关键。LOTUS 要应用提供 critical field，AURA 在线学。第 5 章会展开 typed edge + EWMA decay 怎么做到自动学习。

5.4 G4：兼容回退路径

原文：对冷数据、低置信度锁簇或迁移中的锁簇，可以回退到原 CREST RDMA CAS 路径；但任一时刻同一锁簇只能有一种权威锁路径。

🎯 本教程章节：第 7 章（迁移协议 + I1 不变式 + FallbackLock）

🌟 关键不变式：I1（任一时刻 cohort 权威唯一）+ I4（commit 路径不依赖 owner 位置）

🧠 关键洞察：这一条让 AURA 成为渐进部署而不是”all-or-nothing 替换”——冷数据可以一直走 fallback，热数据走 owner CN 快速路径。

5.5 G5：可在 CREST 中渐进实现

原文：第一版先实现无故障、单 MN、多 CN 的 owner-aware fast path，再逐步补充迁移、恢复和多 MN 支持。

🎯 本教程章节：第 8 章（Router-Centric 实现）+ 第 9 章（端到端复现）

🧠 关键洞察：这一条是写给 reviewer 看的——“我们不是从头造系统，是在 CREST 上改 + 渐进 + 可验证”。这也是为什么 AURA 实验都在 CREST 之上做的根本原因。

5.6 5 条目标 → 后续章节速查表

目标	对应章节	关键指标 / 不变式
G1 减少 MN Atomic	4 + 5 + 6 章	atomic_per_txn ≤ 5
G2 保持数据解耦	4 章	”数据留在 MN” 硬约束
G3 适应漂移	5 章	drift_response_time ≤ 500ms
G4 兼容回退	7 章	I1 + I4
G5 渐进实现	8 + 9 章	CREST 上端到端复现

🌟 结论：这张表就是整本教程后 6 章的”目标 → 章节”映射表。每章开头都会回链到这张表，告诉读者”本章是在 G 几上的展开”。

---

6. 一张总图：把 §2 三段论折成一页

   ┌────────────────────────────────────────────────────────────────┐
   │ §2.1 锁瓶颈                                                    │
   │   atomic IOPS 物理墙（ConnectX-3:1Mpps, ConnectX-6:5-10Mpps）   │
   │   不是软件优化能解决的                                          │
   │                                                                │
   │              ▼                                                  │
   │ §2.2 单纯路由不够                                              │
   │   CREST 实测：partition routing 仅 +2.4% / abort -3pp           │
   │   3 CN 反而回落（AU 饱和 + 节点稳定性）                         │
   │                                                                │
   │              ▼                                                  │
   │ §2.3 转向：锁所有权物理设计                                    │
   │   不学 MorphoSys/Lion 搬数据（违反 disaggregation）            │
   │   改搬锁权威（cohort → owner CN）                              │
   │   代价小 + 适合 DM 架构                                          │
   │                                                                │
   │              ▼                                                  │
   │ §2.4 设计目标 G1-G5                                            │
   │   G1 减少 MN Atomic         (→ 4,5,6 章)                       │
   │   G2 保持数据解耦           (→ 4 章)                           │
   │   G3 适应漂移               (→ 5 章)                           │
   │   G4 兼容回退               (→ 7 章)                           │
   │   G5 渐进实现 (CREST)       (→ 8,9 章)                         │
   └────────────────────────────────────────────────────────────────┘

✅ 自我检验清单

• 三段论：能不看论文，30 秒讲完 §2.1 → §2.2 → §2.3 的 motivation chain
• §2.1 反驳：能回答”升级 ConnectX-7 不就解决了”——AU 单点延迟，不会突然到 100 Mpps
• §2.2 数据点：能背出 CREST routing-only +2.4% / abort -3pp 这一组关键数据
• 3 CN 回落：能解释为什么 3 CN 比 2 CN 吞吐还低（AU 饱和 + 节点稳定性）
• §2.3 代差：能用”搬家具 vs 搬钥匙”比喻讲清 MorphoSys 与 AURA 的差异
• G1–G5：能徒手列 5 条设计目标 + 各自对应教程哪一章

第 4 章预告

第 4 章正式进入论文 §3.1–3.2 + §3.8：Router-Centric 系统模型 + 与 OLTP 谱系（H-Store / VoltDB / Calvin / TiDB）的对照。读完你能徒手画 AURA 12 模块图、解释 router-centric 为什么不是单点、并把 AURA 在 OLTP 工业谱系里定位清楚。

---

📚 参考资料

论文原文与引用

• AURA paper §2：paper_lock_ownership_cn/sections/2_background_motivation.tex
• MorphoSys (Lemur et al., VLDB’21) —— 数据物理设计在线学习的代表
• Lion (Yan et al., 2024) —— 访问图驱动 partition 重排
• RDMA Design Guides —— Mellanox + 学术界 RDMA 同步原语性能研究（论文 §2.1 引用）

CREST 实测数据来源

• AURA 实验脚本：CREST-aura-impl/bench/ —— §2.2 表格的实测脚本
• CloudLab c6525-25g profile —— routing-only 实验硬件

模块内交叉引用

• 本模块第 1 章：AURA 是什么 —— 三段论是本章 §2 的电梯讲法版
• 本模块第 2 章：必备底座 —— §2.1 的物理细节展开
• 模块十五第 3 章：设计空间地图：DM 锁热点的 N 种解法 —— §2.3 的”5 种策略”工程展开
• 模块十五第 12 章：W15/W16/W18 跨 CN 一致性的两条独立路径 —— §2.2 partition-aware routing 的工程对照