第3章：设计空间地图 —— DM 锁热点的 N 种解法

第 1 章建立了”必须把锁请求从 MN 移走”的命题。但解决这个问题的设计空间不止 AURA 一种——routing、static partition、data migration、dynamic owner 各自占一个角落。本章把所有相关工作放进同一张矩阵，给每个系统的 Δ 表（它解决了什么 / 它假设了什么 / 它在哪里失效），并且严格区分”概念上不同”和”实现细节不同”——读完你应该能徒手画 AURA 与 LOTUS 的 Δ 表，并清晰回答”为什么 AURA 是新工作不是优化”。

📑 目录

1. 设计空间矩阵：四个维度
2. 数据迁移派：MorphoSys / Lion 路线
3. Routing-only 派：CREST 路由扩展
4. Static owner 派：LOTUS
5. Dynamic owner 派：AURA
6. AURA Δ 表：与每个工作的精确差异
7. 设计空间的空白处
自我检验清单
参考资料

1. 设计空间矩阵：四个维度

1.1 把所有方案放进同一坐标系

只有把不同方案放进同一坐标系，才能避免”我和它们各做各的”这种含糊。AURA 论文 §2 的 design space 用四个维度：

维度	取值空间	关键问题
D1 锁权威位置	MN-only / CN-static / CN-dynamic / 多副本	锁请求最终打到谁的 RNIC
D2 决策频率	静态部署 / 反应式（100ms+）/ 闭环（5ms）/ 离线分析	跟随漂移的能力
D3 一致性保证	强 / 最终 / 应用解决	迁移期间会不会出错
D4 假设强度	无先验 / 应用提供 schema / critical field	应用可移植性

1.2 五系统在矩阵中的位置

系统	D1 锁权威	D2 决策频率	D3 一致性	D4 假设
FORD	MN-only	静态	强（OCC SR）	无先验
Motor	MN-only	静态	强（SI/SR）	无先验
CREST（cell-level + MVCC）	MN-only	静态	强	无先验
CREST + routing（本研究自加）	MN-only	静态（路由策略）	强	无先验
LOTUS	CN-static	反应式 100ms	强	应用提供 critical field
AURA ⭐	CN-dynamic	闭环 5ms	强	无先验（自学）

1.3 二维投影：D1 × D2

   D2 决策频率
      ▲
      │
      │
 闭环 ┤                          ★ AURA
      │
反应式┤                LOTUS ●
      │
      │
   静态┤  FORD●  Motor●  CREST●
      │
      └─────────────────────────────────► D1 锁权威
         MN-only          CN-static  CN-dynamic

🧠 关键洞察：左下角是 baseline（撞墙）；右上角是 AURA。LOTUS 在中间——它解了”锁权威往右移”，没解”决策频率往上”。这是为什么 AURA 不是 LOTUS 的”优化”，而是设计空间另一个角落。

1.4 维度之间的耦合

四个维度不是独立的：

D1 越往右，D2 必然越复杂：CN-dynamic 需要在线决策，不可能再静态
D2 越往上，D3 越难保证：闭环 5ms 决策必须有强一致迁移协议保护
D4 越弱（无先验），D2 必然越复杂：没有应用提示就只能在线学

🌟 结论：四个维度是相互拉扯的”约束链”。AURA 的贡献本质上是”放松了 D4 的同时保住了 D3”——这是论文 abstract 必须强调的命脉。

2. 数据迁移派：MorphoSys / Lion 路线

2.1 思路：把数据搬到访问它的节点

传统分布式数据库的物理设计核心问题是”数据放哪、谁是主副本、什么时候 split/merge”。MorphoSys（VLDB’21）把这些决策做成在线操作，用学到的代价模型持续调整。Lion（2024）把事务访问关系建成图，把共同访问的分区聚成 clump，再通过副本重排和预测减少分布式事务。

2.2 在 DM 架构下的根本问题

问题	解释
违反 disaggregation 原则	数据集中放在 MN 是 DM 架构的基本假设，频繁迁移破坏资源解耦
元数据复杂度	每条 record 有自己的”当前位置”，索引必须同步更新
一致性代价	迁移期间 reader 必须等待或重定向
内存复制开销	每次迁移要 RDMA WRITE 一遍数据

🍎 直觉比喻：搬数据 = 搬整个仓库；搬锁 = 搬调度台。仓库里货物每天都换，但调度台只是一个小桌子——AURA 选择只搬调度。

2.3 一组对比数字

假设 record 平均 256B，锁字 8B：

操作	数据量	频率
迁移 1 个 record（数据派）	256B + 元数据	取决于访问漂移
迁移 1 个 cohort（AURA）	~64B 锁状态 + 元数据	5ms 决策

32 倍的数据量差距——这是为什么 AURA 选择只搬锁。

2.4 数据迁移派对 AURA 的启发

⭕ 互补：MorphoSys / Lion 的核心方法论 AURA 还是借鉴的：

在线学习成本模型（MorphoSys）：AURA 的 OwnershipPlanner 用了类似的代价函数
访问图聚类（Lion）：AURA 的 LockCohortGenerator 直接用了访问图建 cohort
持续重排：AURA 的闭环也借鉴了 MorphoSys 的”持续优化”思路

区别只在”搬什么”——这就是 AURA 和这条路线的精确差异。

3. Routing-only 派：在 CREST 之上加路由

3.0 先澄清 CREST 本身（避免误解）

⚠️ 本路线之前章节里多次把 CREST 简单概括为”路由扩展”——这是不准确的。基于仓库 README + 源码核对，CREST 的真实定位是：

针对高冲突 / 倾斜 OLTP 负载的 DM 事务系统（README 原话）
协议：OCC + masked-CAS commit（必须 OFED 4.9-7.1.0.0）
MVCC 而非单版本（带 RecordVersion + write_ts + 一致快照检测）
cell-level + record-level 两档 CC（细粒度并发）减 false conflict
column-level rw 追踪：仅传修改列
仓库自实现 from scratch + 内置 FORD / Motor 对比 baseline
4 类 workload：TPC-C / SmallBank / TATP / YCSB

但锁仍在 MN 上——atomic IOPS 物理墙仍是 CREST 的天花板。这就是为什么本节讨论”在 CREST 之上加 routing”——routing 是一个独立的实验扩展（本研究自加的 motivation），不是 CREST 的主体。

3.1 思路：把”访问相似数据”的事务路由到同一个 CN

直观逻辑：如果 CN_1 和 CN_2 总在抢同一个 record，那把它们都送到 CN_1，就只剩 CN_1 内部并发，外部冲突就没了。

3.2 实测数字（接第 1 章 §4）

路由策略	吞吐 (KTPS)	Abort rate
随机	250.4	5.6%
分区路由（按 wid）	256.4	2.6%

Abort 减半，吞吐只 +2.4%——为什么差距这么大？

3.3 数学解释

设 atomic 上限 $\lambda^* = 5.8\text{ Mpps}$ ，CN 们的总 CAS 速率是 $\lambda$ ， $\lambda$ 不被路由改变（路由只改”哪个 CN 发”，不改”发多少”）。吞吐是：

$\text{Tput} = \min(\lambda, \lambda^*) \cdot (1 - p_{\text{abort}})$

abort 从 5.6% 减到 2.6%：

$\frac{\text{Tput}_{\text{new}}}{\text{Tput}_{\text{old}}} = \frac{1 - 0.026}{1 - 0.056} \approx 1.032$

实测 +2.4%，和理论 +3.2% 数量级一致（小差距来自 retry 路径上的隐藏开销）。

🌟 结论：routing-only 在 atomic 触顶下只能动边际。它和 LOTUS / AURA 不互斥（可叠加），但单独使用永远跨不过物理墙。

3.4 routing 仍然有用，但要叠加在哪里

⭕ 互补：路由策略可以叠加：

叠在 LOTUS 之上：把”应该归 owner CN_X 的事务”路由到 CN_X，本来就是 LOTUS / AURA 的 AffinityRouter 做的事
叠在 AURA 之上：在 cohort owner 不命中时，仍然可以用 routing 策略减少跨 cohort 调用

routing 不是替代品，是增量。

4. Static owner 派：LOTUS

4.1 LOTUS 的核心贡献

LOTUS（arXiv 2025）是第一篇系统性证明”锁可以离开 MN”的工作。它的关键设计：

应用声明 critical field：每张表有一个或多个”主排序字段”
按 critical field hash → owner CN：每个值落到一个固定 CN
commit 时本地取锁：owner CN 本地维护锁表，不用 RDMA CAS
100ms 反应式调整：观察热点变化后调整 partition

4.2 LOTUS 的数学胜利

在 critical field 已知 + 稳定的工作负载下：

指标	MN-only	LOTUS
远端 atomic CAS / commit	~3	0
单事务 commit 延迟	~10–20µs	~5–10µs
Atomic IOPS 上限影响	严重	消失

🌟 核心收益：把 atomic 从 commit 路径上完全移除——这是从根上解决问题。

4.3 LOTUS 必须假设什么

假设	实际成立度
critical field 由应用声明	单表场景容易；跨表 join 难
工作负载分布在 critical field 上稳定	静态 OLTP 容易；漂移负载难
critical field 是单一维度	TPC-C wid 单维 OK；复杂 schema 不行

🍎 直觉比喻：LOTUS 像是”VIP 客户预先分到各支行”——支行能服务 VIP 是因为客户没换支行。一旦客户开始随机切支行，VIP 服务就退化到打电话回总部确认。

4.4 LOTUS 的反应式 100ms 调整局限

LOTUS 的 100ms 是”出问题再修”的反应式：

热点出现 → 100ms 后才检测到 → 100ms 后开始重新 partition → 期间已经撞墙
漂移频率 > 1Hz 时反应不过来

这是 AURA 把窗口压到 5ms 的动机——闭环 + 主动预测 vs 反应式 + 滞后修复。

5. Dynamic owner 派：AURA

5.1 AURA 的方法论代差

维度	LOTUS	AURA
决策来源	应用声明 critical field	在线学习 access graph
cohort 粒度	由 critical field 决定（static partition）	任意 key_group 子集（cohort）
决策频率	反应式 100ms	闭环 5ms
迁移协议	弱（粗暴 reassign）	freeze-drain-handoff-publish
应用先验	必须	不需要
漂移工作负载	退化	跟随漂移

5.2 三件 AURA 必须比 LOTUS 多做的事

学 cohort 边界（无需应用提供）—— 第 5 章
形式化迁移协议（保证 I1–I4）—— 第 6 章
闭环控制 + AdaptX Loop A/B（5ms 跟漂移）—— 第 7 章

这三件每一件都不是”LOTUS 的优化”——是 LOTUS 没解决的全新问题。

5.3 AURA 在 stable 工作负载下不胜出，是诚实的

工作负载	LOTUS	AURA	Δ
stable + critical field 已知	100%	~97–100%	~0–3% 损失（profile 开销）
drifting	退化 30–60%	100%	2–5×
unknown critical field	不适用	70–90%	N/A → 70–90%

🌟 AURA 的承诺：不是更快，是更广。在 LOTUS 假设成立时不输（甚至略输 profile 开销），在它假设不成立时大幅领先——这是诚实但有力的范围扩张。

6. AURA Δ 表：与每个工作的精确差异

6.1 Δ 表的标准格式

Δ 维度	与谁比	AURA 怎么不同
锁路径	FORD / Motor	atomic 从 MN 移到 CN
atomic 总量	CREST routing	真减少而不仅是 abort 下降
应用先验	LOTUS	不需要 critical field
决策频率	LOTUS	5ms 闭环 vs 100ms 反应
迁移协议	LOTUS	形式化 4 阶段 + 不变式
cohort 灵活性	LOTUS	任意 key_group 子集 vs 必须 contiguous
数据搬不搬	MorphoSys / Lion	不搬数据，只搬锁权威

6.2 与每个相关工作的”是否互斥”

工作	与 AURA 关系	可叠加吗？
FORD / Motor	baseline	用作对比
CREST routing	正交补丁	可叠加（AURA 在 fallback 路径下仍可路由）
LOTUS static partition	同一空间不同点	不可叠加（同一时间只有一种锁权威）
MorphoSys data migration	不同问题（搬数据 vs 搬锁）	理论上可共存
AdaptX (loop A/B)	被吸收进 AURA（第 7 章）	已是 AURA 一部分

6.3 一句话总结每对差异

AURA vs FORD/Motor：不再被 atomic 上限卡住
AURA vs CREST routing：真减少 atomic 总量，不只是 abort
AURA vs LOTUS：方法论代差——动态 + 在线学，无需应用先验
AURA vs MorphoSys：搬调度而不是搬数据

7. 设计空间的空白处

7.1 AURA 之后的开放方向

写完上面五系统的对比，再看一眼矩阵——还有哪些角落没人填？

空白角落	描述	难点
多副本 owner	一个 cohort 同时由 2+ CN 持有锁	I1 唯一性如何放松而不破坏一致性
跨 DC AURA	多机房 OwnerRpc	网络 RTT >> MN atomic，AURA 反而更慢
CXL pool 上的 owner	锁权威放在 CXL 共享内存而不是 CN	CXL 一致性域 + 失效域
AURA + ML 预测	用 LSTM 预测漂移，提前迁移	预测错误的代价分析
异构 NIC AURA	一个集群混 ConnectX-3/5/6	atomic 能力不一致下的 cohort 放置
持久化 owner state	owner CN crash 后 state 不丢	PMEM / RDMA 持久化协议

7.2 几个值得思考的开放问题

AURA 在 multi-tenant 场景里怎么做隔离？两个租户共享 CN，但 cohort 不能交叉访问。
AURA 的 cohort 数量上限是多少？OwnerMap 太大会影响 AffinityRouter 效率。
AURA 在 GPU/CXL/PMEM 异构内存层级上能否扩展？锁权威可以放在 GPU HBM 上吗？
AURA 与上层 SQL 引擎如何配合？query planner 能否利用 cohort 信息做 hint？

🧠 关键洞察：设计空间的”空白”往往不是没人想到，而是没人做出来——因为某个维度的代价过高。比如多副本 owner 不是没人想，是 I1 的形式化保证需要新协议。

7.3 对读者的建议

读到这里，你应该已经能：

把任何一篇 DM 事务新论文准确放进矩阵
用 Δ 表回答”它和 LOTUS / AURA 的关系”
找到设计空间的空白角落作为新工作灵感

下一章正式进入 AURA 的内部架构。

模块十三第 4 章分离式内存事务系统精读：本仓库 docs/guides/模块十三-新型互联与远程内存系统/第4章-分离式内存事务系统精读.md

关键论文

FORD (Zhang et al., FAST’22)：USENIX 链接 —— 单版本 baseline
Motor (Wu et al., OSDI’24)：USENIX 链接 —— MVCC baseline
CREST（开源 DM 事务系统） —— 针对高冲突倾斜负载，cell-level OCC + MVCC + masked-CAS commit；本路线 §3 的 routing 扩展是在 CREST baseline 之上加的实验
LOTUS (Liu et al., arXiv’25) —— static owner partition 唯一相关工作
MorphoSys (et al., VLDB’21) —— 数据物理设计在线学习
Lion (et al., 2024) —— 访问图驱动 partition 重排
AURA (本路线主轴, 2026) —— dynamic owner placement

行业讨论

AURA 论文 §2 Related Work：本仓库 paper_lock_ownership_cn/sections/2_background_motivation.tex
AURA 论文 §3 Design Overview：paper_lock_ownership_cn/sections/3_design_overview.tex

框架文档

CREST 仓库：本路线第 8/9 章实战载体
FaRM 论文（NSDI’14）：早期 RDMA OCC 范式，是所有相关工作的祖先

搜索