第4章：Router-Centric 架构与 OLTP 谱系对照

第 3 章把 motivation chain 三段论讲完之后，本章正式进入 AURA 设计本体。论文 §3.1 给的是总体架构 + 4 个核心组件 + cohort 三态生命周期；§3.2 给的是系统模型 + I1–I4 不变量；§3.8 把 AURA 放进 OLTP 工业系统谱系，回答”Router-Centric 不是单点”。本章按这三个小节顺序展开，并补一张”AURA 12 模块完整图”作为后续 §5/§6 章的索引地图。读完你能徒手画 AURA 系统模型、解释 cohort 三态切换不变量、并把 AURA 在 H-Store/VoltDB/Calvin/TiDB 谱系里定位清楚。

📑 目录

1. §3.1 总体架构：4 核心组件 + 12 模块完整图
2. Cohort 三态生命周期：owned / transferring / fallback
3. §3.2 系统模型与术语
4. I1–I4 不变量：每条违反会发生什么
5. §3.8 Router-Centric 部署的 4 条理由
6. AURA 在 OLTP 工业谱系里的位置
7. 与 LOTUS 的差异表

1. §3.1 总体架构：4 核心组件 + 12 模块完整图

1.1 论文的”4 组件”说法

论文 §3.1 把 AURA 抽象成 4 个核心组件 + 数据面执行体：

组件	在哪	干啥
Access Graph Profiler	Router 进程	聚合 CN 上报的访问 → 维护键组共同访问边
Lock Cohort Generator	Router 进程	把强亲和键组聚成 cohort，支持 merge/split/transfer/evict
Ownership Planner	Router 进程	为每个 cohort 选 owner CN + 决定 epoch
Affinity Router	Router 进程	把事务发到最适合的 owner CN
OwnerLockTable	每个 CN	本地锁服务（替换 MN atomic）
StatsReporter	每个 CN	周期上报访问统计
OwnerMapSubscriber	每个 CN	拉 router 发的 manifest，触发本地 TransferController
TransferController	每个 CN	执行 freeze/drain/handoff 迁移

1.2 12 模块完整图（论文实际工程实现）

把论文 §3b 的 12 个工作流模块和 §3.1 的 4 组件对齐成一张图：

┌─────────────────────────── Router 进程（控制面） ───────────────────────────┐
│                                                                              │
│    TraceCollector ──► AccessGraphProfiler ──► LockCohortGenerator           │
│       │                      │                       │                       │
│       │                      ▼                       ▼                       │
│       │              AggregatedAccessGraph   OwnershipPlanner               │
│       │                                              │                       │
│       │                                              ▼                       │
│       │                                       OwnerMapPublisher              │
│       │                                              │                       │
│       │              AffinityRouter ◄────────────────┘                       │
│       │                  │                                                   │
└───────┼──────────────────┼───────────────────────────────────────────────────┘
        │ stats heartbeat  │ ExecuteTxn TCP                  │ memcached manifest
        │ (CN→router)      │ (router→CN)                     │ publish (CN pull)
        ▼                  ▼                                 ▼
┌──────────────────────── CN（数据面，每个 CN 一份） ─────────────────────────┐
│                                                                              │
│   StatsReporter ──► (heartbeat)                                              │
│        ▲                                                                     │
│        │                                                                     │
│   TxnExecutor ◄── OwnerRpc ──► (CN-CN 慢路径)                                │
│        │                                                                     │
│        ▼                                                                     │
│   OwnerLockTable ◄────── TransferController ◄──── OwnerMapSubscriber        │
│        │                       (freeze/drain/handoff)                        │
│        ▼                                                                     │
│   FallbackLock ──► MN masked-CAS (冷数据 + 异常路径)                         │
│                                                                              │
│   AuraStats (NIC counter / abort 率 / 队列深度)                              │
└──────────────────────────────────────────────────────────────────────────────┘

🌟 结论：Router 进程跑控制面，每个 CN 跑数据面 + StatsReporter。整个系统的”决策”集中、“执行”分布——这是 OLTP 标准的 controller / executor 模式。

1.3 12 模块每个的章节定位

模块	本教程章节	论文小节
TraceCollector	第 5 章	§3b W13
AccessGraphProfiler / AggregatedAccessGraph	第 5 章	§3.3 + §3b W13
LockCohortGenerator	第 5 章	§3.4 + §3b W14
OwnershipPlanner	第 6 章	§3.5–3.6 + §3b W16
OwnerMapPublisher / OwnerMapSubscriber	第 6 / 7 章	§3b + §4
AffinityRouter	第 6 章	§3.7 + §3b W18
TxnExecutor	第 7 章	§3b
OwnerLockTable	第 4 / 7 章	§3.1 + §4
OwnerRpc	第 7 章	§3b（慢路径）
FallbackLock	第 7 章	§3b + §4 + I1/I4
AuraStats	第 5 / 9 章	§3b + §6 评测
TransferController	第 7 章	§4 协议

📎 工程踩坑视角：模块十五学习路线”AURA 关键模块”那张表是这张图的工程展开版（含具体源文件位置）。

2. Cohort 三态生命周期：owned / transferring / fallback

任一 cohort 始终处于以下三态之一：

                ┌─────────────────────────────────────┐
                │              fallback               │
                │   (MN masked-CAS, 冷数据默认状态)   │
                └────────────────┬──────────────────┘
                                 │
                                 │ access graph 发现写热点
                                 │ Ownership Planner 决定 promote
                                 ▼
                ┌─────────────────────────────────────┐
                │               owned                 │
                │  (CN 本地 OwnerLockTable 裁决)      │
                └────┬─────────────────────┬──────────┘
                     │                     │
        access graph │                     │ 负载失衡
        发现 cohort  │                     │ Ownership Planner
        访问衰减     │                     │ 决定 transfer
                     │                     ▼
                     │           ┌───────────────────┐
                     │           │   transferring    │
                     │           │ (旧 owner 冻结新   │
                     │           │  token, drain 旧)  │
                     │           └─────────┬─────────┘
                     │                     │
                     │                     │ drain 完成
                     │                     │ 切到新 owner
                     │                     ▼
                     │           ┌───────────────────┐
                     │           │   owned (新 owner)│
                     │           └───────────────────┘
                     │
                     ▼ Evict
                 fallback

🌟 关键规则：

fallback ↔ owned：通过 Ownership Planner 决定（promote / evict）
owned ↔ owned：必须经过 transferring 中间态（不能直接换 owner，否则违反 I1）
任何 epoch 内同一 cohort 只能由一种权威裁决（owner CN 的 OwnerLockTable 或 fallback 的 MN masked-CAS，二选一）

🧠 关键洞察：transferring 是协议的安全网——它把”旧 owner 还在处理事务、新 owner 还没就位”这段时间窗口包起来，期间所有新请求被 freeze，旧 token drain 完才切。第 7 章会展开 4 阶段时序。

📎 工程踩坑视角：模块十五第 14 章 §6 的”InstallCohort 幂等性陷阱”本质就是 owned ↔ owned 切换时没经过 transferring 中间态的代码缺陷。

3. §3.2 系统模型与术语

论文 §3.2 给的术语是后续 §3.3–3.7 的”工具箱”。把术语按”上下游关系”重排：

   record
      │ 哈希 / range 映射
      ▼
   key group  (统计最小单位 - 如 hash bucket / key range)
      │ 多个 key group 组成
      ▼
   cohort     (所有权基本单位 - merge/split 在这一层)
      │ 当前 owner / epoch / mode
      ▼
   owner map  (cohort → (owner CN, epoch, mode))
      │ epoch 单调
      ▼
   owner token  (owner CN 授予执行者的临时权限)

3.1 术语速查表

术语	含义	工程对应
key group	owner map 的最小统计单位	在 CREST 实现里：`(table_id << 10) \| (record_key & 0x3FF)`，9 张表 × 1024 bucket = 9216 个
lock cohort	若干 key group 的集合，所有权迁移的基本单位	论文 v25：router 用 access-graph cohort planner 学；v1 工程：直接 `cohort_id = (table<<20) \| bucket`
owner CN	当前 epoch 内唯一有权授予该 cohort 锁的 CN	CN id 0/1/2/3 之一
epoch	每次所有权迁移递增的版本号	u64 单调递增计数器
mode	cohort 权威模式	enum {OWNED, TRANSFERRING, FALLBACK}
owner token	owner CN 授予执行者的临时权限	`OwnerLockTable::LockEntry`

🌟 结论：key group < cohort < owner map 是三层抽象。后续算法（§3.3 访问图、§3.4 cohort merge、§3.5 ownership planner）都建立在这三层上。

🍎 直觉比喻：

key group = 一格储物柜（最小可寻址单位）
cohort = 一片储物柜区域（若干格的集合，统一管理）
owner map = “哪片区域归谁管”的大字报
owner token = 区域负责人发给具体用户的临时钥匙

4. I1–I4 不变量：每条违反会发生什么

第 1 章 §4 已经给了 I1–I4 的速记表，本章在论文 §3.2 + §4 形式化定义的基础上补”每条违反 corner case”。

4.1 I1：权威唯一性

任一 cohort 在同一 epoch 内只能由一个权威裁决锁：要么是 owner CN 的本地锁表，要么是 fallback 模式下的 MN CAS。

违反 corner case：

   T1 (CN1): 看到 cohort c 处于 fallback → 走 MN masked-CAS → 加锁成功
   T2 (CN2): 同时看到 cohort c 已 promote 到 owned (在 CN2) → 走本地锁表 → 加锁成功
       │
       └─ 两个事务都认为自己持有锁 → 双写

🌟 防御：epoch + mode 一起检查。promote 时先 publish 新 OwnerMap (mode=transferring) + 等所有 CN 拉到，再切到 owned。这就是 4 阶段协议（第 7 章）的根。

4.2 I2：epoch 单调性

所有 owner token 都带有 cohort epoch；如果提交阶段发现 token epoch 低于 owner map 中的当前 epoch，则事务必须 abort 或重新获取权限。

违反 corner case：

   T1 拿到 epoch=5 的 owner token
   迁移发生 → cohort 进入 epoch=6
   T1 仍用 epoch=5 token 提交 → owner 接受 → 与 epoch=6 的事务冲突

🌟 防御：commit phase 必须验证 token.epoch == owner_map[cohort].epoch；不等就 abort。这是 OCC validation 多了一道”epoch 校验”。

4.3 I3：迁移排空

cohort 从 owner O 迁往 owner N 前，O 必须停止授予新 token，并等待旧 token 释放、超时或被主动 abort。

违反 corner case：

   迁移 cohort c: O → N，O 没等旧 token drain
   T_old 拿着 O 给的 token，仍在执行
   T_new 已经在 N 上拿到新 token
   两者 commit 都顺利通过 → I1 在事务边界上失效

🌟 防御：drain 阶段必须等所有 outstanding token 释放或超时。模块十五第 14 章讲过的 freeze-drain-handoff 4 阶段就是 I3 的工程实现。

4.4 I4：数据提交不变

AURA 不改变底层数据写回、日志和版本验证协议；它只替换锁获取路径，因此提交可见性仍由底层 DM 事务系统决定。

违反 corner case（假设性，AURA 设计上禁止）：

   AURA 把 commit phase 改成 "在 owner CN 上写值"
   故障：owner CN 挂掉 → commit 数据丢失
   fallback 模式下事务无法 commit（因为提交协议变了）

🌟 防御：AURA 只动锁路径，commit phase 100% 复用 CREST 原版——masked-CAS + RDMA WRITE + replicate 全部不动。owner CN 上的 OwnerLockTable 只决定”是否能 commit”，commit 数据写到 MN 仍然走 RDMA。

🧠 关键洞察：I4 是 AURA 能渐进部署的根。冷数据走 fallback、热数据走 owner CN，两条路径用同一个 commit 协议，所以可以混跑。

📎 工程踩坑视角：模块十五第 7 章讲过 AdaptX 折叠进 AURA 时 commit 路径必须保持不变——这是 I4 的工程对照。

5. §3.8 Router-Centric 部署的 4 条理由

第 1 章 §5 已经讲过”Router-Centric 不是单点”，本节按论文 §3.8 的 4 条理由一一展开：

5.1 理由 1：全局视图

Cohort 规划需要所有 CN 的访问分布——单个 CN 看不到别的 CN 在干什么。Router 是 client-facing 单点，天然聚合点。

🌟 反例（per-CN 模型）：

   CN1 看到自己 cohort c 访问量大 → 决定 promote 到自己
   CN2 看到自己也访问 c 不少    → 决定 promote 到自己
   两者同时 publish OwnerMap → race window

📎 工程踩坑视角：模块十五第 13 章讲过 W7.4-B 的 per-CN 控制环就是栽在这种 race-publish 上。

5.2 理由 2：决策与路由同址

Router 内部 cohort planner 直接喂数据给 router 内部 RoutingTable，决策→路由零网络往返。

   per-CN 模型：CN 决策 → publish 给 client → client 更新路由表 (多一跳)
   Router-Centric：router 内部决策直接更新路由 (零跳)

🌟 结论：Router-Centric 把”learn → plan → route”压在一个进程内，反馈窗口可以短到 100ms tick。

5.3 理由 3：TransferController 仍在 CN

迁移的执行（freeze / drain / handoff）必须在 CN 本地完成——只有 CN 知道自己 OwnerLockTable 的当前 outstanding token 状态。

🌟 分工：

阶段	在哪	干啥
规划（决定迁谁、迁去哪）	Router	OwnershipPlanner + Benefit 模型
publish（公告新 OwnerMap）	Router → memcached	Manifest v2
执行（freeze/drain/handoff）	每个 CN 本地	TransferController + OwnerMapSubscriber

🍎 直觉比喻：宿舍调换的”管理处”决定要调，“楼栋负责人”执行调；两边都需要、缺一不可。

5.4 理由 4：Ground truth 仍由 CN 提供

CN 上的 StatsReporter 捕获真实访问（含 abort retry / index lookup / 本地队列深度）——这些 router 直接从 logical request 看不到。

🌟 数据流：

   CN StatsReporter → heartbeat 上报 (含 typed edge ww/wr/rr + 本地队列深度)
                                           │
                                           ▼
                              Router AggregatedAccessGraph
                                           │
                                           ▼
                              Cohort plan 输入

🧠 关键洞察：Router 不是 omniscient，它通过 CN 上报来感知世界——这是分布式系统的标准做法（TiDB PD 通过 region heartbeat 收集 leader / load 信息，本质同构）。

6. AURA 在 OLTP 工业谱系里的位置

Router-Centric 的合法性靠”工业系统都这么做”撑——这就是 §3.8 拉 H-Store / VoltDB / Calvin / TiDB 出来对照的原因。

6.1 5 系统谱系对照表

系统	中心控制平面	决定的事	失效时事务能否继续	执行模型
H-Store	partition manager	哪个 partition 在哪个 site	✅ 按旧 partition map	shared-nothing, single-threaded
Calvin	sequencer	事务执行顺序（全局序）	❌ 在关键路径上	deterministic, in-memory
VoltDB	partition planner	client routing	✅ 按旧 plan	H-Store 商业化
TiDB	PD（Placement Driver）	region 路由 + 调度	✅ 按旧 region map	distributed SQL + raft
AURA	router 进程	manifest（cohort → owner CN）	✅ 按旧 manifest	DM + OCC + 动态锁所有权

🌟 AURA 在谱系里的位置：

控制面集中 ✅（H-Store / VoltDB / Calvin / TiDB 全是）
数据面分布 ✅（同上）
失效不阻塞执行 ✅（H-Store / VoltDB / TiDB 是；Calvin 不是）
动态调整粒度 = cohort（锁权威），这是 AURA 独有的轴

🧠 关键洞察：AURA 不是发明 Router-Centric，是把这个工业标准模式应用到一个新轴（锁权威）上。轴是新的，但架构是熟的。这让 reviewer 容易接受。

6.2 谱系借鉴方向

AURA 模块	借鉴 OLTP 系统	借了什么
OwnershipPlanner	TiDB PD scheduler	”评估 region balance + load balance” 这套 cost model 思路
OwnerMapPublisher	TiDB PD heartbeat	manifest publish via memcached（类似 PD via raft log）
AffinityRouter	VoltDB partition-aware client	路由决策直接绑事务到 owner 站点
TransferController	TiDB region split + transfer	freeze-drain-handoff 4 阶段（PD 走的是 raft 切主）
StatsReporter	TiDB region heartbeat	CN 主动上报让 controller 看到真实 ground truth

📎 工程踩坑视角：模块十五第 14 章 §2 “AURA-router-centric 在 OLTP 谱系里的位置” 是这张表的工程动机展开。

7. 与 LOTUS 的差异表

读完 §3.8 + §3.9 应该能徒手画出 AURA 与 LOTUS 的 Δ 表。这是 reviewer 必问的：

维度	LOTUS	AURA
锁权威位置	CN（与 AURA 同）	CN（与 LOTUS 同）
cohort 定义	应用提供 critical field	在线访问图学习
运行时迁移	100ms 反应再均衡（pass-by-range）	freeze-drain-handoff 4 阶段
控制平面	per-CN 自治（pass-by-range 协商）	Router-Centric 集中决策
失效路径	不明确	fallback to MN masked-CAS（I4）
routing layer	§4.3 显式标 “orthogonal, out of scope”	填这个空白
适合场景	应用知道 critical field 且稳定	访问模式漂移 / 缺分片键 / 多表事务热点

🌟 一句话差异：LOTUS = 静态锁分离 + 应用先验，AURA = 动态学习 + 集中编排 + 可迁移。这两个不是 incremental 关系，是代差。

🧠 关键洞察：LOTUS §4.3 把 routing layer 标为 orthogonal——AURA 主要贡献就是填这个空白。如果 LOTUS 自己后续也做 dynamic routing，AURA 与之的差异就剩”动态 cohort 学习 + I1-I4 形式化”。但在 2026 年这个时间点，LOTUS 没做，AURA 占了。

✅ 自我检验清单

12 模块图：能徒手画 router 进程 + 4 CN 数据面的 12 个模块及数据流（heartbeat / ExecuteTxn / manifest）
三态生命周期：能画 fallback ↔ owned ↔ transferring 状态机 + 列出每条边的触发条件
术语链：能解释 record → key group → cohort → owner map 的关系
I1–I4：能徒手写每条不变量 + 给出违反 corner case
§3.8 四理由：能讲清楚 Router-Centric 选 router 而非 per-CN 的 4 条理由
OLTP 谱系：能画 5 系统对照表 + 解释 AURA 不是发明 Router-Centric，是应用到新轴
LOTUS Δ：能背 AURA vs LOTUS 的 7 维差异表

第 5 章预告

第 5 章按论文 §3.3–3.4 + §3b W13/W14 顺序展开访问图与 cohort 学习：

typed edge（W_ww / W_wr / W_rr）为什么必须区分
EWMA decay 半衰期推导
union-find cohort merge + Jaccard 迟滞
thread_local batch + 倒排索引工程细节

读完第 5 章你能徒手讲完整个”事务访问 → 边权更新 → cohort 形成”的 online 学习链。

📚 参考资料

论文原文

AURA paper §3 design overview：paper_lock_ownership_cn/sections/3_design_overview.tex
AURA paper §3b 组件工作流：paper_lock_ownership_cn/sections/3b_component_workflows.tex

OLTP 谱系论文

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 —— TiDB GitHub Wiki PD scheduler + region heartbeat
MorphoSys (Lemur et al., VLDB’21) —— 控制面规划 + 数据站执行分工的奠基

参照对比

LOTUS (Liu et al., arXiv’25) —— §4.3 把 routing layer 标 orthogonal
CREST：本路线实战载体

模块内交叉引用

本模块第 1 章：AURA 是什么 —— Router-Centric 在 §5 的电梯讲法版
本模块第 3 章：论文 §2 重读 —— 本章是 §3.x 的开篇，§2 motivation 是它的前置
模块十五第 4 章：AURA 骨架 —— 本章 §3 / §4 的工程展开
模块十五第 14 章：Router-centric 重构 —— 本章 §5 / §6 的工程落地版

搜索