跳到主要内容
分离式内存事务系统全景调研

第9章：开放问题与自家工作 —— DM 事务的下一个十年

DM 事务领域的 6 个开放方向（CXL / AI infra 协同 / 异构 NIC / cross-DC / ML for DM / 多副本 owner），以及自家工作 CREST + AURA 在地图中的位置

DM 事务 开放问题 未来方向 CREST AURA 调研 自家工作

12 年的演进让 DM 事务从”能不能做”走到”怎么做更广”。但 12 年并没有完全解完这个领域——还有大量开放方向。本章把 DM 事务的下一个十年最可能产出的 6 个方向系统梳理：CXL 上的 DM 事务、AI infra 协同（KV cache + 事务）、异构 NIC、跨 DC、ML for DM、多副本 owner。最后用一节展示”自家工作”——CREST 与 AURA 在地图中的位置——这是本路线的收尾，也是模块十五的入口。

📑 目录

1. 为什么 DM 事务下一个十年仍然有故事

1.1 第 3 章 8 个核心问题的”已解 vs 未解”

问题已解未解
1. atomic IOPS 物理墙LOTUS / AURA（同 DC）跨 DC、CXL、SmartNIC
2. RDMA RTTdoorbell batch + 异步 validate持久化路径、跨 cohort
3. OCC validateOutpost 流水线跨 cohort、多版本
4. 锁字布局masked CAS（CN-side 不限制）跨硬件代际兼容
5. 索引RACE / Sherman / XStore / SMART图、多模、AI 协同
6. MVCCMotor+ 锁分离合体、GC 长事务
7. 持久化Plor、CloverCXL 持久化、跨副本
8. 故障FaRM-style epoch跨 DC、partition、CN-side recovery

🌟 结论：8 条主线没有一条完全解完——每个都有”已解一部分，剩余开放”。

1.2 6 个最值得做的开放方向

   开放方向（按"5 年内可发顶会"评估）
   ───────────────────────────────────
   ⭐⭐⭐⭐⭐ CXL 上的 DM 事务
   ⭐⭐⭐⭐⭐ AI infra 协同
   ⭐⭐⭐⭐  异构 NIC
   ⭐⭐⭐⭐  跨 DC
   ⭐⭐⭐⭐  ML for DM
   ⭐⭐⭐  多副本 owner

每个方向有论文、有市场、有合适规模的工程量——是博士选题的好候选。

2. 方向 1：CXL 上的 DM 事务

2.1 CXL 是什么

CXL（Compute Express Link）是新一代硬件总线，CXL 2.0+ 支持内存池化：

   CXL 内存池
   ────────────
   CPU A ─┐
           │
   CPU B ─┼──► CXL Switch ──► Memory Pool（远端 DRAM/PMEM）
           │
   CPU C ─┘
   ↑ CPU 直接 load/store 远端内存
   ↑ 延迟 ~200ns（vs RDMA ~5µs）

🌟 关键事实：CXL.mem 把”远端内存”延迟从 µs 级压到 ns 级——这是革命性的。

2.2 CXL 对 DM 事务的影响

   CXL 改变了什么
   ──────────────
   1. 远端访问从 µs → ns
   2. 不需要 RDMA verbs（直接 load/store）
   3. atomic 直接走 CPU 指令（不走 NIC）
   4. 但 atomic 仍受 cache coherency 协议限制

2.3 CXL DM 事务的开放问题

问题描述
atomic 行为CXL.mem 上 cmpxchg 的延迟和 IOPS？
一致性域多 CN 共享 CXL 池时的 cache coherency？
持久化CXL.mem 上的 PMEM 怎么 flush？
失效域CXL switch 故障时怎么办？

2.4 CXL DM 论文的现状

⚠️ 现状：截至 2026 年，还没有专门的 CXL DM 事务论文——只有概念探讨。这是个完全空白的方向。

🌟 建议：博士生选题：第一个完整的 CXL DM 事务系统——预期能发顶会。

3. 方向 2：AI infra 协同（KV-cache + 事务）

3.1 LLM 时代的新负载

LLM 推理引入了一类新数据：KV-cache（attention 状态）。

   KV-cache 特点
   ────────────
   - 大量短期数据（每次 prompt ~MB-GB）
   - 高频读（decode 时反复访问）
   - 跨实例共享潜力（prefix cache）

Mooncake / DistServe / SplitWise 等系统已经做了 KV-cache 池——它们用 RDMA 但不做严格事务。

3.2 AI infra 与 DM 事务的协同点

   协同点
   ──────────
   1. 共享 RDMA 硬件（同一个集群跑 KV-cache + DB）
   2. 共享 disaggregation 哲学
   3. 共享元数据存储（用户信息 / session 状态）

3.3 开放问题

问题描述
LLM 推理时的事务保证用户 session 状态需要事务一致
KV-cache 与事务系统共存同一硬件资源如何调度
LLM 生成的数据写入数据库流式事务设计

3.4 AI infra 与 DM 协同的论文

🌟 现状：这个方向几乎完全空白——AI infra 圈和 DB 圈说不同语言。做交叉的有重大机会。

4. 方向 3：异构 NIC 集群

4.1 现状：同代际假设

主流 DM 论文假设集群内同代际 NIC——实测都是 c6525-25g 全 ConnectX-6 Dx。

但生产集群通常异构：

   生产场景
   ──────────
   - 老节点：ConnectX-3
   - 新节点：ConnectX-6 Dx
   - 最新节点：ConnectX-7
   ↑ 同集群混用

4.2 异构带来的挑战

   异构挑战
   ──────────
   1. atomic IOPS 不一致（CX-3 1M vs CX-6 5-10M）
   2. extended verbs 兼容性（masked CAS 在 CX-3 不支持）
   3. NIC counter 行为不同（firmware 差异）
   4. cohort 怎么放（应该偏向 CX-6 节点？）

4.3 已有工作

⚠️ 现状：几乎没有专门处理异构的 DM 论文。AURA 在 portability claim 时讨论了一点但不深。

🌟 机会：异构 NIC 的 cohort 调度、协议降级策略——博士选题。

5. 方向 4：跨 DC DM 事务

5.1 现状：单 DC 假设

主流 DM 论文都假设单 DC 单机柜——RTT ~µs。

跨 DC：

场景RTT
同 DC1-5µs
同区域跨 DC100-500µs
跨区域10-100ms

🌟 致命：跨 DC RTT 比单 DC 大 1000 倍——RDMA 优势完全消失。

5.2 跨 DC 的开放问题

   开放问题
   ──────────
   1. 跨 DC 副本协议（Paxos/Raft 跨 DC 慢）
   2. 跨 DC OwnerRpc（AURA 跨 DC 怎么办）
   3. 跨 DC 时间一致性（TrueTime 或 HLC）
   4. 网络分区下的 fallback

5.3 已有工作

⚠️ 现状：跨 DC DM 事务几乎是空白——传统跨 DC 数据库（Spanner / Cockroach）有成熟方案，但是基于 active server 的，不能直接搬到 DM。

🌟 建议：这是 DM 事务”走出实验室”必须解决的方向——但难度高。

6. 方向 5：ML for DM（智能调度）

6.1 ML 在 DM 中的角色

AURA 已经引入”在线学习”做 cohort 划分。下一步：

   ML for DM
   ──────────
   - 用 LSTM/Transformer 预测 workload 漂移
   - 用 RL 优化 cohort placement
   - 用图神经网络做访问模式分类

6.2 已有工作

工作用途
XStore (OSDI’20)learned index
AURA (本路线)在线 cohort learning（轻 ML）

6.3 开放问题

   开放问题
   ──────────
   1. ML 决策的延迟（5ms 内能跑多复杂的模型？）
   2. ML 的可解释性（出错时能 debug 吗）
   3. ML 模型何时重训
   4. ML + 控制理论的结合（RL × AIMD）

6.4 风险与机会

⚠️ 风险：ML 在系统里容易过度复杂化——审稿人会质疑”为什么不用简单 heuristic”。

🌟 机会：真正展示 ML 优于 heuristic 的工作很少——做出来有重要意义。

7. 方向 6：多副本 owner / 协作式锁

7.1 当前 owner 模型的限制

AURA 现在是 单 owner——一个 cohort 只在一个 CN 上有权威。

   单 owner 的限制
   ──────────────
   - owner 自己有 CPU 上限
   - cohort 只能 split 不能"复制"
   - 多个事务争同一 cohort 还是要 RPC 到 owner

7.2 多副本 owner 的设想

   多副本 owner
   ──────────────
   - 一个 cohort 在多个 CN 上有 active 权威
   - 用某种协议保证一致性（quorum / lease）

7.3 难点

   难点
   ──────
   1. I1（authority uniqueness）放松后如何不破坏一致性
   2. 多副本之间的 lock state 同步
   3. 故障下哪个副本是 leader

7.4 已有相关工作

⚠️ 现状：多副本 DM owner 还没有系统设计论文——可能是 AURA 之后的下一篇。

8. 自家工作：CREST

8.1 CREST 的定位（核对实际仓库 README + 源码）

CREST（开源仓库 CREST-Opensource-0007）：针对高冲突 / 倾斜 OLTP 负载的 DM 事务系统。README 原话：“targets highly-contented workload and provides high throughput under skewed workloads”。

⚠️ 诚实声明：CREST 在我手头的仓库 README 没有标注具体发表会议 / 年份。本路线之前章节里出现的 “ASPLOS’26 Anonymous” 是不准确的——当作”开源 DM 事务系统”看待，引用时只引仓库本身。

8.2 CREST 的核心贡献（基于源码核对）

   CREST 贡献
   ──────────────
   1. 高冲突 / 倾斜负载的 DM 事务系统
      - 默认协议：OCC + masked-CAS commit
      - 必须 OFED 4.9-7.1.0.0（masked atomic 仅在此版本暴露）
      - cell-level CC（细粒度并发控制）减少 false conflict
   
   2. MVCC（不是单版本）
      - RecordVersion + write_ts 时间戳
      - inconsistent-snapshot 检测
      - column-level rw_columns / access_columns 追踪
        → 仅传输被修改的列，减少 RDMA 字节流量
   
   3. 完整的 4 类 workload 支持
      - TPC-C / SmallBank / TATP / YCSB
      - 每个 workload 在 benchmark/ 目录独立实现
   
   4. 自带 FORD / MOTOR 对比 baseline
      - Comparisons/myford
      - Comparisons/mymotor
      - 不是 fork 自 FORD，而是 from scratch 自实现 + 收录他系统复现
   
   5. CN-side 加速
      - AddressCache（CN 缓存远端地址）
      - ENABLE_LOCAL_EXECUTION（本地执行优化）
      - ENABLE_REDO_LOG（持久化日志）
      - 状态机里有显式 "LOCALIZATION" 阶段 → 把热点 record 拉到 CN 本地处理

🌟 关键定位：CREST 的核心 selling point不是”实验框架”——它有自己明确的研究 contribution（高冲突倾斜负载下的高吞吐）。仓库内置 FORD/Motor baseline 是”为了对比”，不是它的主体贡献。

8.3 CREST 在 design space 矩阵的位置（修正版）

维度CREST
D1 OCC vs 2PLOCC（masked-CAS commit）
D2 单版本 vs MVCCMVCC ⭐（带 write_ts + RecordVersion）
D3 锁权威集中（MN-side）
D4 leader轻 leader
D5 validate同步（OCC 风格）
D6 verbs单边（masked-CAS 是 extended atomic）
细粒度cell-level + record-level 两档可选
目标 workload高冲突 / 倾斜（skewed）

⚠️ 本路线之前章节里把 CREST 标成”单版本”是错的——CREST 实际是 MVCC。这个错误已在 §8.2 修正。

8.4 CREST 仓库结构（实测）

   CREST-Opensource-0007/
   ├── src/
   │   ├── common/      Config + Type
   │   ├── db/          Table / Schema / DbRecord / PoolHashIndex / AddressCache
   │   ├── mempool/     Pool / BufferManager / Coroutine / Scheduler
   │   ├── rdma/        QueuePair / MemoryRegion / Doorbell / RdmaBatch
   │   └── transaction/ Txn / RecordHandle / TimestampGen / LogManager / ...
   ├── benchmark/
   │   ├── TPCC/  SmallBank/  TATP/  YCSB/   ← 4 类 workload
   │   └── BenchRunner.cc
   ├── Comparisons/
   │   ├── myford/      ← FORD 对比实现
   │   └── mymotor/     ← Motor 对比实现
   ├── config/          各 workload 的 JSON 配置
   └── scripts/         Python 实验自动化（scalability / breakdown / sensitivity）

8.5 CREST 与 AURA 的关系（修正版）

   AURA 与 CREST
   ──────────────
   ❌ 错误说法："AURA 直接 fork 自 CREST"
   ✓ 正确说法：AURA 在 CREST 框架上扩展
                - 复用 CREST 的 RDMA / mempool / db 层
                - 在 transaction/ 层新增 Owner-aware fast path
                - LoopB.h（NIC counter 监测）作为补丁加入
                - cohort / OwnerLockTable / TransferController 是 AURA 新增

🌟 AURA 在 CREST 之上的具体增量见模块十五——本节只是把”自家工作链”标清楚。

8.6 CREST 之前的 gap（修正版）

   CREST 之前
   ──────────
   - FORD（单版本）在高冲突 / 倾斜负载下 abort 暴涨
   - Motor（MVCC）解决了 SI 问题但仍受 atomic IOPS 限制
   - 缺少"针对高冲突倾斜负载的工程化系统"
   
   CREST 之后
   ──────────
   - cell-level CC + MVCC 让倾斜负载下的吞吐显著回升
   - 但锁仍在 MN，atomic IOPS 物理墙仍存在
   - LOTUS / AURA 接的就是这个"锁还在 MN"的 gap

9. 自家工作：AURA

9.1 AURA 的核心贡献

详见模块十五完整教程。简短总结：

   AURA 三件套贡献
   ──────────────────
   1. 动态锁所有权
      - 接 LOTUS gap：critical field 未知或漂移时怎么办
      - 在线学 cohort，5ms 闭环
   
   2. 形式化迁移协议（freeze-drain-handoff-publish）
      - 4 阶段 + 4 不变式 I1-I4
      - 故障安全（fallback to MN）
   
   3. 闭环控制（吸收 AdaptX Loop A/B）
      - owner-side back-pressure
      - NIC counter 摄取
      - AIMD 反压

9.2 AURA 在地图中的位置

维度AURA
D1OCC
D2单版本（MVCC 是开放方向）
D3分散动态 ⭐
D4轻 leader
D5同步（异步是开放方向）
D6单边

🌟 AURA 的 niche：D3 维度的下一步——从 LOTUS 静态走到动态。

9.3 AURA 与 6 个开放方向的关系

方向AURA 已经做了AURA 留下的
1. CXL没做（RDMA-only）CXL 上 cohort placement
2. AI infra没做与 KV cache 共享集群
3. 异构 NIC部分做（CX-3/CX-6 portability claim）异构下的 cohort 选择
4. 跨 DC没做（明确限定单 DC）跨 DC 协议
5. ML for DM部分做（在线学 cohort）更复杂的 ML（LSTM 预测）
6. 多副本 owner没做I1 放松后的多副本

🌟 机会：AURA × Motor 合体（动态锁 + MVCC）是非常自然的下一步——博士生考虑。

9.4 AURA 的局限（写 paper 必须诚实）

   AURA 的局限
   ──────────────
   1. 跨 cohort 比例 > 50% 时退化
   2. 单 DC 假设
   3. profile 开销 ~1.4% CPU
   4. 在 critical field 已知 + 永不漂移时略输 LOTUS

详见模块十五第 1 章 §7 与第 8 章 §4。

10. 选题建议：从地图到 PhD topic

10.1 用本路线选博士题

   选题流程
   ──────────────
   1. 读完本路线（模块二十）→ 拿到全景
   2. 选一个开放方向（§2-§7 任一）
   3. 找 AURA × X 或 Motor × X 的合体（§9.3）
   4. 在 design space 矩阵（第 4 章 §8）找空白格
   5. 用 micro benchmark 证明问题存在（§5）
   6. 设计协议（参考 AURA 的不变式范式）
   7. 实现 + 实验（参考第 8 章方法论 + 模块十五第 9 章实战）

10.2 几个具体可发表的小题

   小题（1 篇 paper 的工作量）
   ──────────────────────────
   ⭐ AURA × Motor 合体：动态锁 + MVCC
   ⭐ Sherman × AURA：cohort-aware B+tree
   ⭐ AURA on CXL：CXL.mem 上的 cohort
   ⭐ ML 预测漂移：LSTM 替代 AURA 滞回
   ⭐ AURA 跨 DC：分层 cohort

10.3 大题（多篇 paper / 整个博士）

   大题
   ──────
   - 异构 NIC 集群上的 DM 事务
   - AI infra + DM 协同框架
   - 完整的 CXL-native 事务系统
   - 跨 DC DM 事务（with TrueTime equivalent）

🌟 建议：先小后大——博士第一年选小题快速发表，建立信心 + experience；后两年选大题做完整系统。

10.4 投稿目标

顶会偏好
OSDI / SOSP系统全栈 / 架构创新
NSDI网络 + 系统协同
ATC工程化 + portability
FAST存储相关（PMEM / NVMe）
ASPLOS跨硬件 / 软硬协同
VLDB / SIGMOD数据库视角

🌟 AURA 投 ATC——因为它是 portability + control loop，匹配 ATC 的偏好。

✅ 自我检验清单

  • 8 个核心问题”已解 vs 未解”：能默写至少 4 条
  • 6 个开放方向：能列出 + 各自一句话核心
  • CXL 改变了什么：能用一句话区分 RDMA 和 CXL.mem
  • AI infra 协同点：能列出至少 2 个 LLM 与 DM 的交叉点
  • 异构 NIC 挑战：能列出至少 3 个异构挑战
  • 跨 DC DM：能解释为什么 RTT 1000× 让 RDMA 优势消失
  • ML for DM 风险：能描述”过度复杂化”的审稿人质疑
  • 多副本 owner：能解释 I1 放松的设计挑战
  • CREST 的 niche：能描述 CREST 作为实验框架的价值
  • AURA 的 6 维定位：能默写 AURA 在 design space 的位置
  • AURA 的局限：能列出至少 3 个 AURA 不胜出的场景
  • AURA × Motor 合体：能描述这个开放方向
  • 小题 vs 大题：能给自己规划博士第一年到第三年的选题
  • 投稿目标：能根据工作类型选合适会议

📚 参考资料

关键论文（按方向）

方向 1 CXL：

  • Pond (Li et al., ASPLOS’23) —— 云端 CXL 1.1
  • TPP (Maruf et al., ASPLOS’23) —— Meta 透明 page placement

方向 2 AI infra：

  • Mooncake (Qin et al., FAST’25) —— KV-cache 池
  • DistServe (Zhong et al., OSDI’24) —— PD 分离

方向 3 异构：

  • DPDK / DOCA 文档 —— SmartNIC 编程

方向 4 跨 DC：

  • Spanner (Corbett et al., OSDI’12) —— TrueTime
  • Cockroach —— HLC

方向 5 ML for DM：

  • XStore (Wei et al., OSDI’20) —— learned index
  • MorphoSys (et al., VLDB’21) —— online learning physical design

自家工作：

  • CREST（开源 DM 事务系统）
  • AURA（本路线主体）—— 详见模块十五

综述

  • The Datacenter as a Computer (Barroso et al., 3rd ed., 2018)
  • A Survey on Disaggregated Memory (Wang et al., 2023)

行业讨论

  • CXL Consortium 白皮书
  • Intel Optane 停产 + CXL 接班的讨论
  • DPU 路线图（NVIDIA Bluefield-3 / AMD Pensando）

入门资料

  • 本仓库 PROGRESS.md —— AURA 项目实战日志
  • 模块十五完整教程 —— AURA 的纵深拆解
  • 模块十三第 4 章 —— DM 事务系统精读（横向起点）