第3章：5 个自适应 dimension 详解 —— full / partial / future 的诚实分级

第 1 章告诉你 v27 thesis 是”5 维度运行时物理设计”，第 2 章把底座补齐。这一章是 v27 设计的脊柱——把这 5 个维度逐个拆开讲清楚：每一维是什么、v27 做到了什么状态（full / partial / future）、对应代码在哪、与现有系统（LOTUS、LOTUS-3MN、CREST）的差异。读完这章你能回答评委可能从任何一维进攻的”你这一维做完了吗”的灵魂拷问——而且能用 paper 的诚实分级方式回答，而不是吹牛或回避。

📑 目录

1. 5 维度速览表
2. Dim 1 · 执行位置（execution location）
3. Dim 2 · 仲裁位置（arbitration location）
4. Dim 3 · 仲裁粒度（arbitration granularity）
5. Dim 4 · MN 主权（MN primary authority）
6. Dim 5 · Mode / fallback
7. LOTUS-3MN 对照：MN-primary 这一维真的不能 actuate 吗
8. 章末小结：3 + 1 + 1 的分级哲学

1. 5 维度速览表

v27 paper §3.2 的核心表，本章的”地图”：

维度	描述	v27 状态	对应代码 anchor	本章 §
1. 执行位置	哪个 CN 跑 txn body	✓ full	`TpccClient.cc:281`	§2
2. 仲裁位置	CN local lock vs MN CAS	⚠️ partial（LOCAL 43% ✓）	OwnerLockTable + W9/W11	§3
3. 仲裁粒度	per-key / cohort / partition	✓ full	CohortGenerator + A2 + A3	§4
4. MN 主权	哪个 MN replica 是 master	✗ future	LOTUS-3MN 对照（§7）	§5
5. Mode/fallback	planner 可让 cohort 走 fallback	✓ full	EpochManager + W14.5	§6

⭐ 诚实分级的总分布：full × 3 + partial × 1 + future × 1。这不是缺点——这是 paper 的卖点之一。

每一维下面都按 4 件套展开：(a) 是什么 / (b) v27 做到哪步 / (c) 跟现有系统的差异 / (d) reviewer 可能问什么。

2. Dim 1 · 执行位置（execution location）

2.1 是什么

txn 体由哪个 CN 实际执行——拿数据、做 OCC validation、提交。在 disaggregated 架构里这是个真问题：

CREST 把 client 发起的 txn 就近在某个 CN 上跑（默认随机 / 轮询）
LOTUS 引入 ownership 后，可以”把 txn 路由到 cohort owner CN”——但 LOTUS 用的是静态 owner map
AURA v25 第一次让 txn 路由跟着 cohort 学习结果走——cohort-owner routing
AURA v27 继承 cohort-owner routing，没改算法，但确认它默认开启 + 文档化

2.2 v27 做到哪步：full

TpccClient.cc:281 的 RouteToOwnerCN() 在 v25/v26/v27 都是默认开启。client 发起 txn 前先查 OwnerMap，把 txn 体直接发给 cohort owner CN。

代码骨架：

// TpccClient.cc:281
auto cohort_id = cohort_generator.Identify(read_set, write_set);
auto owner_cn  = owner_map.Get(cohort_id);
client_->ExecuteOnCN(owner_cn, txn_body);   // 路由到 owner

完整 full 的依据：

routing 默认开启（不需要 flag）
OwnerMap 在 router 进程实时维护，client 拉 manifest 更新
A2/A3 lever 改变 cohort 形状 / OwnerMap 后，routing 自动跟随

2.3 跟现有系统的差异

系统	路由策略	是否随 cohort 漂移
CREST	随机 / 轮询	×
LOTUS（静态）	partition owner	×
AURA v25	cohort owner	✓（每 100 ms）
AURA v27	cohort owner（同上）	✓

2.4 reviewer 可能问什么

Q1：“这跟 LOTUS 静态 partition owner 路由有啥区别？” A：LOTUS 把 partition 写死，AURA 让 cohort 在线漂——partition 是一种特殊的 cohort（每个 cohort = 一个 partition），AURA 在它之上加了”cohort 可以在线分裂 / 合并 / 改 owner”。

Q2：“如果 OwnerMap 切换瞬间，client 还在用旧 map 怎么办？” A：见第 6 章 W14.5 dual-authority guard——CN 端拒绝旧 epoch 的请求，client retry。第一维的 safety 依赖第六章 §3 的协议。

🌟 结论：第 1 维是 v25 已经做完、v27 默认承继的能力。没有新东西，但作为 5 维度框架的一员要列出来，且诚实标 full。

3. Dim 2 · 仲裁位置（arbitration location）

3.1 是什么

lock 的物理位置——MN-side CAS 还是 CN-local OwnerLockTable。

MN-side CAS：每次 acquire/release 走 RDMA atomic，落到 MN-RNIC 物理上限（ConnectX-6 Dx 5-10 Mpps）
CN-local OwnerLockTable：cohort owner CN 维护一个本地锁表，acquire/release 跟 OCC validation 同进程，不走 RDMA atomic

→ 把 lock 从 MN 搬到 CN 是 LOTUS 的核心 thesis；AURA v27 让这个搬动可在线决定。

3.2 v27 做到哪步：partial

LOCAL takeover（cohort 完全在 owner CN）：✓ 跑通

43% 的路由走 LOCAL takeover 路径——data 在 owner CN 本地能算完 OCC，不用跨 CN
atomic IOPS 节省可观（从 baseline 12.16 atomic/txn → 6.11 atomic/txn 经 v26 客户端 access graph 重构后）

REMOTE_OWNER takeover（cohort 跨 CN）：✗ W9/W11 backlog

57% 的路由需要”客 CN 给主 CN 发 proxy RPC”——这条路径 99.5% abort cascade
根因：第 7 章 §2 详述（cv.wait_for × worker pool 16 槽死锁）
v27 punt 决定：写成 §6.5 caveat + §8 limitation

3.3 为什么不强行算 full

诚实化原则——partial 就写 partial，不掩盖 99.5% abort cascade 的真实存在。

如果硬写 full，reviewer 复现时会看到爆炸数据，paper 立刻信誉破产。

🍎 直觉比喻：你不能因为”做对了一半”就说”全做对了”。AURA 第 2 维就是这种情况——LOCAL 全对，REMOTE 全炸，加权下来是 partial。

3.4 跟现有系统的差异

系统	仲裁位置	在线变更
CREST	MN-CAS only	×
LOTUS（静态）	CN-local（按 critical field 静态分配）	×
AURA v27 LOCAL 路径	CN-local（按 cohort 动态）	✓
AURA v27 REMOTE 路径	CN-local + cross-CN RPC	partial（99.5% abort）

3.5 reviewer 可能问什么

Q1：“你说 partial，那你的 §6.2 数据是怎么跑的？是不是只跑了 LOCAL？” A：5-cell ablation 和 drift workload 都跑了完整 v27（含 REMOTE 路径），但仲裁位置维度只有 43% 路由走 LOCAL takeover、其余仍走 MN-CAS 后备路径。详见 §6.5 caveat row。

Q2：“REMOTE 99.5% abort 是不是说你的 thesis 错了？” A：不是——这正反证 thesis。“CN-only locks 不能简单 LOTUS 化”是 v27 §1 的 contribution 1 之一。partial CN-only 的失败模式正说明为什么需要 adaptive 而不是静态 CN-only。

🌟 结论：第 2 维是 v27 唯一一个 partial，所有”AURA 哪里没做完”的 reviewer 攻击都会落在这里——必须准备好回应（详见第 7 章）。

4. Dim 3 · 仲裁粒度（arbitration granularity）

4.1 是什么

锁的单位——per-key / per-cohort / per-partition：

per-key：CREST 默认。每个 record 一把锁（CAS bit on MN）
per-cohort：AURA v25/v27。一组 record 共享一把 lock（OwnerLockTable 单 entry）
per-partition：LOTUS / H-Store。整个 partition 一把全局锁

粒度越粗，锁竞争点越少；但粒度过粗会导致无关 txn 也排队。

4.2 v27 做到哪步：full

AURA v27 选了 per-cohort 粒度，并通过 A2/A3 lever 让 cohort 在线调粒度：

A2 affinity binding 把多个 cohort 绑同一 owner CN（等效于 partition 粒度，但保留动态性）
A3 cohort split 把过度争用的 cohort 切开（变细）

完整 full 的依据：粒度可在线伸缩，从”per-cohort 接近 per-key（每个 cohort 1 key）“到”per-cohort 接近 per-partition（cluster of 3 cohorts）“。

4.3 跟现有系统的差异

系统	粒度选择	是否动态
CREST	per-key	×
LOTUS	per-cohort（静态）	×
H-Store	per-partition	×
AURA v27	per-cohort（A2 + A3 在线调）	✓

4.4 reviewer 可能问什么

Q1：“per-cohort 粒度是不是太细了，A2 affinity binding 本质上就是把粒度推回 per-partition？” A：A2 binding 后逻辑上是 cluster of cohorts，但仍保留 cohort 边界——如果未来某 cohort 单独热起来，A3 可以把它切出来。保留可分性是跟静态 partition 的本质差异。

Q2：“cohort 划分本身是不是 critical field——LOTUS 的另一种命名？” A：cohort 不是 critical field。critical field 是 LOTUS 由应用提供的静态 marker；cohort 是 AURA 从 access graph 学出来的动态结构。第 5 章 §6 已对比 actuation surface 差异。

🌟 结论：第 3 维是 v27 的核心新东西——粒度伸缩 + 动态调整。是 paper §3 的 contribution 2 的主战场。

5. Dim 4 · MN 主权（MN primary authority）

5.1 是什么

哪个 MN replica 是 master——在多 MN 系统里，对同一份数据可以有多个 MN replica，但 master replica 决定权威值。

单 MN 系统（CREST default / AURA v27 default）：master 唯一，无可选项
多 MN 系统（LOTUS-3MN / Spanner 类）：master 可在多 MN 间漂移

→ MN 主权这一维只在多 MN 系统里才有意义。

5.2 v27 做到哪步：future

诚实分级：✗ future。理由：

v27 实验都是单 MN bench（CloudLab amd103 作为 MN）
单 MN 物理上没有”哪个 MN 是 master”的选择
这一维不能简单地”通过加 MN replica”补齐——MN-primary 与第 2 维”仲裁位置”交叉作用，需要双层协议设计

5.3 为什么不删掉这一维

理由：留 future work 的接口。

如果删掉，paper 的 5 维度框架变成 4 维度——未来 LOTUS-3MN 对比 / 多 MN 扩展工作没有锚点。留作 future 让框架完整，同时诚实标”我们没做这一维”。

🧠 关键洞察：把 MN-primary 留为 future work 而不是删掉，是 paper §3.2 的设计选择——这样 paper 的 5 维度框架仍然完整，而不是”我们只做了 4 维度”。诚实分级允许”做了 80% 就发”，不要求”全做完再发”。

5.4 reviewer 可能问什么

Q1：“你说 MN-primary 是 future，但 LOTUS-3MN 已经做了一些，你为什么不直接用作 baseline？” A：LOTUS-3MN 的 MN-primary 是静态分配，AURA v27 需要的是自适应迁移——两者不在同一抽象层。LOTUS-3MN 作为对照基线部分有效，但不能完整 exercise 这一维。详见 §7。

Q2：“是不是你们不愿意做 12 节点的多 MN 实验？” A：CloudLab 节点资源有限是部分原因，但更关键的是 MN-primary 涉及 RDMA replication 协议设计——超出 v27 论文范围。详见 §8 limitation。

🌟 结论：第 4 维是 future work，paper §6.6 RQ5 缺失的一部分。诚实标记 + 留接口是最佳处理。

6. Dim 5 · Mode / fallback

6.1 是什么

planner 可以有意把一个 cohort 留在 “fallback mode”——即不走 AURA 的 CN-local lock，回退到 MN-CAS。

⭐ 关键点：fallback 不是”出错时的逃避路径”，而是 adaptive policy 的一种合法选择。

什么时候 planner 会选 fallback？

cohort 太冷（访问稀少）——搬到 CN 的 move cost 超过收益
cohort 跨 CN 跨太大（access set 散在 4 CN）——CN-local 锁反而引入大量 cross-CN RPC
workload phase 不稳（A4 reservoir 显示样本变化剧烈）——搬来搬去 thrashing

6.2 v27 做到哪步：full

实现：

EpochManager 每 100 ms 评估每个 cohort 的 mode（CN-local / MN-CAS-fallback）
mode 切换走 epoch handoff（freeze-drain-handoff-publish），同 ownership 迁移协议
W14.5 invariant guard 防止 mode 切换期间出现 dual authority

完整 full 的依据：mode 是 cohort 的第一类属性，planner 决策时 fallback 是默认候选之一（不是 fallback-only）。

6.3 fallback 不是逃避

很多 reviewer 第一次看到 “fallback mode” 会误解：“你这是出错就回退 MN-CAS？那 AURA 不就退化成 CREST 了吗？”

回应：

fallback 不是因为出错触发——是 planner 主动选择的策略
fallback 不是 binary——cohort 表里可以有 70% 走 CN-local + 30% 走 MN-CAS-fallback 的稳定混合
§6.2 5-cell ablation 显示 baseline (fixed/off/off) 跟 full_v27 commit_rate 都 99.92%+——意味着 fallback 没破任何 SI 保证

🍎 直觉比喻：fallback 像保险的”低保额套餐”——不是”出事才用”，是”对某些客户来说低保额本身就是最优选择”。

6.4 跟现有系统的差异

系统	是否支持 mode 选择	mode 是否在线变
CREST	只有 MN-CAS（无 mode 概念）	N/A
LOTUS	只有 CN-local	×
AURA v27	CN-local / MN-CAS-fallback 二选一	✓（每 100 ms）

6.5 reviewer 可能问什么

Q1：“fallback 是不是变相承认 CN-local 不行？” A：不是。fallback 在 §6.2 数据里只占少数 cohort（具体比例待 telemetry 补全），主路径仍是 CN-local。fallback 是对 “cohort 不适合 CN-local” 那部分的最优选择，不是整体退化。

Q2：“如果 cohort 大多数都在 fallback，AURA 退化成 CREST，那 paper 还有什么 contribution？” A：极端 workload 下确实会退化（这是 paper §8 limitation 之一）。但对TPC-C 4-CN 这种 partitionable workload，fallback 比例足够低（待补数据），主路径仍展示 adaptive 价值。

🌟 结论：第 5 维是 v27 完成度最高的”诚实化”实现——fallback 不是 bug 而是 feature。

7. LOTUS-3MN 对照：MN-primary 这一维真的不能 actuate 吗

回到 Dim 4 没讲完的细节。LOTUS 论文里有 3-MN 配置——这给了 v27 §6.4 一个 reference baseline 候选。

7.1 LOTUS-3MN 是什么

LOTUS 的 3-MN 实验配置：

3 个 MN 节点，data 在 3 MN 间分片（partition × replication）
每个 partition 有一个 master MN
master MN 静态分配（实验前 calibrate 好）
critical field 仍由应用提供

7.2 这是不是”MN-primary 这一维已经被做过了”

不是——理由 3 条：

静态 vs 动态：LOTUS-3MN 是静态 master 分配，AURA v27 想做的是自适应迁移——两者不在同一抽象层
actuation surface：LOTUS-3MN 的 actuation 是”启动时选 master”，AURA 的 actuation 是”运行时迁移 master”
协议复杂度：LOTUS-3MN 不需要 in-flight migration 协议（master 不变），AURA 需要

7.3 §6.4 缺失基线的三选一

第 1 章 §5 提过 §6.4 RQ4 缺失基线候选：

A 选项：W11 finish → 真做 CN-only baseline（被 punt）
B 选项：LOTUS port → 2 天工作量（评估中）
C 选项：honest caveat row → v27 当前选择

LOTUS-3MN 不能完整替代——它是部分对照（仅 cover Dim 4 静态版），不 cover Dim 2（仲裁位置）。

7.4 future work 接口

如果未来要做 MN-primary 这一维：

阶段 1：实现 RDMA replication 协议（3 MN 间同步 write）
阶段 2：实现 master 在线迁移协议（同 cohort migration 的 freeze-drain-handoff）
阶段 3：把 master 选择加入 Benefit 函数（新增 cost coefficient replication_cost）

这是新论文级别的工作，不是 v27 范围。诚实标记 future + 留接口。

8. 章末小结：3 + 1 + 1 的分级哲学

8.1 完成度分布

       Dim 1 (执行位置)        ████████████████ 100% full
       Dim 2 (仲裁位置)        ████████░░░░░░░░  43% partial (LOCAL only)
       Dim 3 (仲裁粒度)        ████████████████ 100% full
       Dim 4 (MN 主权)         ░░░░░░░░░░░░░░░░   0% future
       Dim 5 (Mode/fallback)   ████████████████ 100% full

3 full + 1 partial + 1 future = v27 的诚实化分级。

8.2 诚实化的 4 条收益

评委不会觉得”作者隐瞒了什么”——5 维度框架完整列出，partial 和 future 自己承认
后续工作有清晰的接口——B5 cache / W11 finish / LOTUS 对比每个对应到具体维度
团队 punt 决定有据可循——partial 状态可以在 §8 解释为什么 punt
跟 v25 “做完才发” 的研究策略形成对照——v27 选择诚实化先发，是研究策略的演进

8.3 这套分级是 paper 的核心卖点之一

很多 system paper 选择”全 full”来”显得完整”——但 reviewer 会用复现 / 阅读 code 来挑战这种 full claim。

v27 选择诚实分级——partial 写 partial、future 写 future——让 reviewer 没法用”你声称 full 但 code 是 partial”来攻击。

🌟 结论：5 维度诚实分级是 v27 paper §3.2 的 headline 表。整本 paper 任何”AURA 做了什么”的问题最终都应该把读者引导到这张表，再展开具体维度。

⭐ MEMOIRABLE QUOTE：“5 维度诚实分级是 v27 paper 跟 v25 paper 最大的写作差异——v25 选择做完才发，v27 选择诚实分级先发。两者都对，但 v27 把研究策略本身做成了 paper 卖点之一。”

✅ 自我检验清单

5 维度名称：能默写 5 个 dimension 的名字 + 一句话描述
状态分级：能给出每维的 v27 状态（full / partial / future）+ 整体分布 3+1+1
代码 anchor：能给出每维至少一个代码文件路径
Dim 2 partial：能解释为什么”仲裁位置”是 partial 而不是 full，引用 99.5% abort cascade 作证据
Dim 4 future：能解释为什么”MN primary”留为 future，跟 LOTUS-3MN 的对照怎么说（3 条理由）
Dim 5 fallback：能解释 Mode/fallback 是合法的 adaptive policy 而不是逃避
诚实化策略：能解释 v27 诚实分级 vs v25 “做完才发” 是两种不同的研究策略，各自的优势是什么
LOTUS-3MN 不能完整替代：能给出 3 条理由（静态 vs 动态 / actuation surface / 协议复杂度）

📚 参考资料

概念入门

v27 paper outline §3.2 —— 5 维度表的 source of truth
模块二十三《AURA 论文精讲》第4章-Router-Centric架构与OLTP谱系对照 —— v25 的架构视角

关键论文

LOTUS —— Dim 4 MN-primary 维度的静态对照（3-MN 配置）
Calvin (SIGMOD’12) —— deterministic 执行位置选择的反例
H-Store / VoltDB —— per-partition 粒度仲裁的工业级对照
Spanner (OSDI’12) —— 多 MN 系统的 master replication 范式

行业讨论

模块十五《分离式事务的动态锁所有权》第3章-设计空间地图DM锁热点的N种解法 —— 设计空间地图
模块二十《分离式内存事务系统全景调研》第4章-协议设计派系全图 —— 协议派系对照

框架文档（代码 anchor）

benchmark/Client/TpccClient.cc:281 —— Dim 1 执行位置 routing
src/transaction/aura/OwnerLockTable.cc —— Dim 2 LOCAL takeover
src/transaction/aura/CohortGenerator.cc —— Dim 3 仲裁粒度
src/transaction/aura/EpochManager.cc —— Dim 5 mode switch

📎 v25 对照视角：模块二十三-AURA 论文精讲第4章-Router-Centric架构与OLTP谱系对照 —— v25 时期只 actuate 了 lock placement 一维；v27 扩到 5 维度，并加入诚实化分级

搜索