技术 on Hellokitty's Blog

Rust 异步编程原理：Future、状态机、Waker 与 Executor

Tue, 25 Aug 2026 15:35:00 +0800

面向初学者，从 Future::poll 出发推导 Rust async/await 状态机，并解释 Waker、Executor、Reactor、Pin、并发与阻塞。

PCIe BAR 深入解析：从设备地址窗口到 DMA 与 GPUDirect Storage

Fri, 21 Aug 2026 16:25:00 +0800

在操作系统驱动、高性能网卡、NVMe SSD 和 GPU 系统中，经常会同时看到 BAR、MMIO、DMA、IOMMU、peer-to-peer DMA、GPUDirect RDMA 和 GPUDirect Storage 等概念。这些名词都与“设备怎样通过 PCIe 交换控制信息和数据”有关，但它们处在不同层次。

最简洁的理解是：

BAR：让 CPU 能够定位并访问 PCIe 设备中的寄存器或显存窗口
DMA：让 PCIe 设备能够主动读取或写入系统内存
P2P DMA：让一个 PCIe 设备直接访问另一个 PCIe 设备暴露的地址空间
GDS：利用 DMA、GPU 内存映射和驱动协作，让存储数据尽量直接进入 GPU 显存

本文从 PCIe 地址空间和事务模型出发，解释 BAR 是如何分配和映射的，驱动为什么通过 BAR 下发命令，DMA 地址为什么不能简单等同于物理地址，以及 GPUDirect Storage 如何把这些机制组合成一条高性能数据路径。

一、先建立 PCIe 系统视图

一个典型服务器的 PCIe 拓扑如下：

                         CPU
                          │
                Memory Controller
                          │
                       Host RAM
                          │
                    Root Complex
                   ┌──────┴──────┐
                   │             │
              PCIe Switch    PCIe Endpoint
              ┌────┴────┐         GPU
              │         │
           NVMe SSD     NIC

CPU 和内存构成主机侧。Root Complex 把 CPU/内存系统连接到 PCIe fabric。NVMe、网卡和 GPU 通常是 Endpoint。PCIe Switch 用于扩展端口和转发事务。

Rust Tokio 深入解析：运行时原理、并发模型与最佳实践

Fri, 21 Aug 2026 11:35:00 +0800

Rust 语言只定义了 Future、async/await 和 Waker 等异步基础设施，并没有在标准库中提供完整的异步运行时。Tokio 补齐了这一层：它提供任务调度器、网络 I/O 驱动、定时器、异步同步原语、异步文件接口以及阻塞任务隔离机制。

如果把 Rust 异步程序比作一座城市：

Future            = 等待执行的工作
Executor/Scheduler = 安排工作在哪个线程运行
I/O Driver         = 监听 socket 是否就绪
Timer Driver       = 管理定时器何时到期
Waker              = 通知某个任务可以继续
Tokio              = 将上述组件组合成运行时

本文不再重复 Future::poll 和状态机的基础推导，而是聚焦 Tokio 本身：runtime 如何启动，任务如何调度，网络 I/O 为什么不会阻塞线程，以及生产代码中应该怎样处理并发、超时、共享状态、CPU 密集任务和优雅退出。

一、Tokio 提供了什么

一个典型 Tokio 应用依赖：

[dependencies]
tokio = { version = "1", features = ["full"] }

full 适合学习和应用开发，但库作者通常应该只启用实际需要的 feature，缩短编译时间并减少依赖面。

Tokio 的主要组成包括：

组件	作用
Runtime	组合调度器、I/O driver 和 timer driver
Task	由 runtime 调度的异步任务
`tokio::net`	TCP、UDP、Unix Socket 等异步网络接口
`tokio::time`	sleep、interval、timeout
`tokio::sync`	channel、Mutex、RwLock、Semaphore、Notify
`tokio::fs`	文件系统异步接口
`spawn_blocking`	将阻塞或 CPU 密集工作移出异步 worker
`select!`	同时等待多个异步分支

需要先建立一个重要认识：

Mooncake Transfer Engine 源码阅读（四）：TENT 下一代架构如何重构传输引擎

Fri, 21 Aug 2026 11:18:00 +0800

Mooncake 仓库同时存在经典 Transfer Engine 和 TENT（Transfer Engine Next）。TENT 不是简单增加一种 Transport，而是重构了 Segment 生命周期、运行时调度、拓扑选择、QoS、故障转移和插件体系。

阅读版本：

Mooncake commit: 777cc7782417b6e554cf7c2d53210d0d8f89f5cc

一、为什么需要下一代引擎

经典 TE 已经支持 RDMA、TCP、NVLink 和多种硬件，但随着后端增加，TransferEngineImpl + MultiTransport + 各 Transport 容易出现几个问题：

Segment 生命周期分散在元数据和后端注册逻辑中；
传输选择主要依赖静态协议与局部规则；
多 rail、拥塞、故障和 QoS 难以统一调度；
不同后端各自维护进度线程和资源模型；
新硬件接入需要理解大量经典内部约定；
请求取消、deadline 和 failover 缺少统一运行时。

TENT 将这些能力上移到 Runtime 层。

二、目录结构

TENT 核心位于：

tent/src/runtime/
├── transfer_engine_impl.cpp
├── segment.cpp
├── segment_manager.cpp
├── segment_registry.cpp
├── segment_tracker.cpp
├── transport_loader.cpp
├── transport_selector.cpp
├── progress_worker.cpp
├── admission_queue.cpp
├── qos_contract.cpp
├── receiver_credit.cpp
├── topology.cpp
├── control_plane.cpp
└── proxy_manager.cpp

外围包括：

Mooncake Transfer Engine 源码阅读（三）：RDMA、TCP 与请求完成状态机

Fri, 21 Aug 2026 11:17:00 +0800

Transfer Engine 的公共 API 很统一，但 RDMA 和 TCP 的实现差异很大。RDMA 需要 MR、QP、WR 和 CQ；TCP 需要连接、lane、消息 framing 和接收端主动拷贝。本文沿源码比较两条路径，并分析 Batch 状态如何完成。

阅读版本：

Mooncake commit: 777cc7782417b6e554cf7c2d53210d0d8f89f5cc

一、Transport 抽象

Transport 基类统一定义：

install / uninstall
registerLocalMemory / unregisterLocalMemory
submitTransfer
getTransferStatus
allocateBatchID / freeBatchID

它还定义 TransferRequest、TransferStatus 和内部 BufferEntry。

公共抽象要求每个后端回答三个问题：

本地内存如何准备为可传输状态；
请求怎样排队和执行；
如何查询每个 task 的最终状态和字节数。

具体连接模型不属于公共 API。

二、RDMA 初始化

RDMA 后端主要位于：

rdma_transport.cpp
rdma_context.cpp
rdma_endpoint.cpp
endpoint_store.cpp
worker_pool.cpp

安装阶段通常完成：

枚举 RDMA devices / ports / GID
  -> 创建每张 HCA 的 context
  -> 建立 PD、CQ 等资源
  -> 启动 worker / poller
  -> 发布 NIC endpoint metadata
  -> 准备 endpoint store

Mooncake 支持多 HCA、多端口和 GPU 内存，因此一个逻辑请求可能被切到多个 rail 上并行发送。

Mooncake Transfer Engine 源码阅读（二）：Segment、内存注册与元数据服务

Fri, 21 Aug 2026 11:16:00 +0800

Mooncake Transfer Engine 的核心抽象不是“远端指针”，而是 Segment + BufferDesc + Metadata。应用注册本地内存后，TE 将地址范围、设备位置和传输协议发布为 Segment 描述，其他节点才能定位并建立连接。

阅读版本：

Mooncake commit: 777cc7782417b6e554cf7c2d53210d0d8f89f5cc

一、为什么不能直接发送指针

一个进程中的地址：

0x7f12...

在另一个进程中通常没有意义。即使两台机器都使用相同数值，它们也不指向同一块物理内存。

高性能传输还需要额外信息：

这是 CPU DRAM 还是 GPU VRAM；
对应哪张 GPU；
是否注册成 RDMA MR；
rkey 和网卡 endpoint 是什么；
是否能用 NVLink、GPU IPC 或 CXL；
节点当前是否存活；
地址区间是否已经注销。

因此 TE 把地址空间包装成 Segment，并通过元数据服务交换描述。

二、`SegmentDesc`

TransferMetadata::SegmentDesc 是远端发现的中心结构，主要承载：

Segment ID
Segment 名称
协议或协议集合
本机 RPC / endpoint 信息
BufferDesc 列表
设备与拓扑信息
后端扩展元数据

可以把一个 Segment 理解成某个 TE 实例公开的可传输地址空间：

Segment: decode-node-7
├── Buffer A: CPU metadata pool, protocol=rdma
├── Buffer B: GPU KV pool, protocol=rdma
└── Buffer C: GPU KV pool, protocol=hip

同一块 GPU buffer 可以被多个后端注册，从而同时支持：

Mooncake Transfer Engine 源码阅读（一）：统一传输 API 与整体架构

Fri, 21 Aug 2026 11:15:00 +0800

Mooncake Transfer Engine（简称 TE）是 Mooncake 数据平面的基础组件。它不负责决定 KV Cache 应该放在哪里，而是提供统一接口，把一段本地内存搬到远端 Segment，或者从远端 Segment 读取到本地内存。

本文基于 Mooncake 官方仓库：

commit: 777cc7782417b6e554cf7c2d53210d0d8f89f5cc
commit date: 2026-08-21

当前仓库同时保留经典 Transfer Engine 和下一代 TENT。前三篇先阅读经典实现，第四篇再分析 TENT 如何重构控制面、调度和传输后端。

一、源码布局

核心目录为 mooncake-transfer-engine/：

路径	作用
`include/transfer_engine.h`	对外 C++ API
`include/transfer_engine_impl.h`	经典实现内部接口
`include/transport/transport.h`	Transport 抽象、请求和状态
`include/transfer_metadata.h`	Segment、Buffer 与元数据接口
`src/transfer_engine.cpp`	公共 API 转发层，同时兼容经典 TE 与 TENT
`src/transfer_engine_impl.cpp`	初始化、内存注册、Segment 与批次管理
`src/multi_transport.cpp`	安装和选择具体 Transport
`src/transport/`	RDMA、TCP、NVLink、NVMe-oF、EFA 等后端
`tent/`	Transfer Engine Next 实现

TE 的经典架构可以概括为：

应用 / Mooncake Store
        │
        ▼
TransferEngine
        │
        ▼
TransferEngineImpl
   ┌────┼──────────────┐
   ▼    ▼              ▼
Metadata  MultiTransport  Batch 生命周期
          │
   ┌──────┼───────────────┐
   ▼      ▼       ▼       ▼
  RDMA   TCP    NVLink   NVMe-oF ...

二、公共 API 是一层门面

TransferEngine 类本身很薄，大多数函数转发给 TransferEngineImpl：

nvidia-fs 源码阅读（三）：文件 I/O、批处理、完成路径与诊断

Fri, 21 Aug 2026 10:47:00 +0800

前两篇分别介绍了 nvidia-fs 的模块结构，以及 GPU virtual address 到 peer DMA address 的映射。本文沿一次 cuFileRead 对应的内核路径，分析文件 I/O 如何提交、完成和清理，并介绍 batch、稀疏文件、RDMA 与 /proc 诊断接口。

阅读版本：

commit: 328d1d8cce1175c013720985c30e123e9a35242c
GDS_VERSION: 2.29.4

一、I/O 入口

nvfs_ioctl() 接收：

NVFS_IOCTL_READ
NVFS_IOCTL_WRITE
NVFS_IOCTL_BATCH_IO

单次读写共用两阶段结构：

nvfs_io_init(op, ioargs)
  -> 验证并构造 nvfs_io

nvfs_io_start_op(nvfsio)
  -> 向目标文件提交真正 I/O

分成两步的意义在于：参数验证、对象引用和资源分配都应在进入异步 I/O 前完成。一旦请求提交，完成回调可能很快发生，初始化不完整会造成竞态。

二、`nvfs_io_init` 做了什么

nvfs_io_init() 是用户参数到内核 I/O 对象的转换层，主要工作包括：

根据文件描述符取得目标 struct file；
检查读写权限；
查找已经注册的 GPU buffer/mgroup；
验证 GPU buffer offset、文件 offset 和长度；
建立影子 page 对应的 iov 或迭代器；
初始化 kiocb、完成函数和统计字段；
为同步、异步和特殊文件系统路径设置标志。

源码还会检查文件系统类型、direct I/O 条件和文件权限。写操作比读操作更复杂，因为它可能涉及文件扩展、页缓存一致性及磁盘空间预分配。

nvidia-fs 源码阅读（二）：GPU 内存注册、影子页与 DMA 映射

Fri, 21 Aug 2026 10:46:00 +0800

上一篇从 nvfs_init()、字符设备和 ioctl 看到了 nvidia-fs 的外部形态。本文进入 GDS direct path 的核心：怎样把用户分配的 GPU virtual address 变成存储设备能够 DMA 的地址，同时又让 Linux 文件 I/O 栈能够携带它。

阅读版本仍为 NVIDIA gds-nvidia-fs：

commit: 328d1d8cce1175c013720985c30e123e9a35242c
GDS_VERSION: 2.29.4

一、问题本质

普通块 I/O 最终围绕 bio_vec、struct page、scatterlist 和 DMA mapping 展开。但 cudaMalloc 得到的是 GPU 虚拟地址，对 Linux 页缓存和块层来说，它并不是普通 CPU 内存页。

驱动需要解决三次“翻译”：

GPU virtual address
  -> NVIDIA P2P page table 中的 GPU physical pages
  -> Linux I/O 栈可携带的影子 struct page
  -> 某个存储 PCIe 设备可使用的 DMA address

三个地址空间不能混为一谈：

nvidia-fs 源码阅读（一）：模块初始化、设备接口与整体架构

Fri, 21 Aug 2026 10:45:00 +0800

nvidia-fs 是 NVIDIA GPUDirect Storage（GDS）的 Linux 内核模块。它不是一种文件系统，而是连接 libcufile、NVIDIA GPU 驱动、Linux 文件 I/O 和支持 GPUDirect 的存储驱动的一层内核协调组件。

这组文章阅读 NVIDIA 官方 gds-nvidia-fs 仓库，采用的版本为：

commit: 328d1d8cce1175c013720985c30e123e9a35242c
GDS_VERSION: 2.29.4
commit date: 2026-06-01

系列分为三篇：

模块初始化、设备接口与整体架构；
GPU 内存注册、页表与 DMA 映射；
文件 I/O、批量请求、完成路径与可观测性。

本文先回答一个问题：加载 nvidia_fs.ko 后，内核里究竟多了什么？

一、源码目录

核心代码都位于 src/：

文件	职责
`nvfs-core.c/.h`	字符设备、ioctl、GPU 内存注册和文件 I/O 主流程
`nvfs-mod.c`	与 NVMe、RDMA 等外部模块动态注册 DMA 回调
`nvfs-mmap.c/.h`	GPU 页对应的影子 `struct page` 和 mmap 管理
`nvfs-dma.c/.h`	block request 到 GPU DMA 地址的映射
`nvfs-batch.c/.h`	批量 I/O 提交与完成
`nvfs-rdma.c/.h`	RDMA 注册信息管理
`nvfs-pci.c/.h`	GPU 与存储设备的 PCIe 拓扑、距离和亲和性
`nvfs-proc.c`、`nvfs-stat.c`	`/proc` 配置、统计和诊断接口
`nvfs-kernel-interface.c`	不同 Linux 内核版本的兼容封装

主线集中在 nvfs-core.c，但真正的数据直达能力是多个文件共同完成的。

GDS、GIDS 与 uGDS 有什么区别：从数据直达、GPU 发起到用户态 NVMe

Thu, 20 Aug 2026 14:05:00 +0800

GDS、GIDS 和 uGDS 的名字非常接近，也都在讨论 GPU 与存储之间的数据通路，因此很容易被理解成同一项技术的三个版本。

实际上，它们解决的是三个不同层面的问题：

GDS 关注数据路径：怎样让存储数据不经 CPU 内存中转，直接进入 GPU 显存；
GIDS 关注控制路径：怎样让 GPU Kernel 自己决定并发起存储请求，减少 GPU 与 CPU 往返；
uGDS 关注软件栈：怎样让 CPU 在用户态直接管理 NVMe 队列，绕过内核 NVMe 驱动与文件系统。

可以先用一句话概括：

GDS 是“数据直达 GPU”，GIDS 是“GPU 主动要数据”，uGDS 是“用户态 CPU 直接驱动 NVMe 把数据送到 GPU”。

本文从请求由谁发起、数据经过哪里、NVMe 命令由谁构造、是否保留文件系统语义等维度，分析三者的区别与联系。更深入的原理可以继续阅读本系列的三篇文章：

一、先区分数据路径与控制路径

理解这三项技术的关键，是不要把“数据经过哪里”和“谁发起 I/O”混为一谈。

数据路径

数据路径描述有效载荷如何移动。例如：

传统路径：SSD → CPU 内存 → GPU 显存
直接路径：SSD ──────────→ GPU 显存

GDS、GIDS 和 uGDS 都希望建立 SSD 与 GPU 显存之间的 DMA 路径，减少 CPU bounce buffer。但“数据不经过 CPU 内存”并不代表“CPU 没有参与”。

uGDS 原理解析：在用户态打通 NVMe SSD 与 GPU 显存

Thu, 20 Aug 2026 13:55:00 +0800

大模型推理正在把存储重新推到系统性能的核心位置。模型权重、KV Cache、Embedding 和训练检查点都可能在 SSD、主存与 GPU 显存之间频繁搬运。传统路径通常要经过文件系统、内核块层、页缓存或用户态中转缓冲区，不但增加 CPU 开销，也让小块 I/O 延迟变得难以控制。

uGDS 是 ScaleX-IO 开源的一套用户态 GPU Direct Storage 开发库。它的核心思路很直接：

让 CPU 在用户态构造 NVMe 命令并管理提交队列与完成队列，由 SSD 通过 PCIe P2P DMA 直接读写 GPU 显存，从数据路径中绕开内核 NVMe 驱动和文件系统。

本文结合 uGDS 当前源码，解释它为什么快、一次 I/O 如何执行、内核模块与用户态库如何分工，以及使用这类“绕过内核”的存储栈时必须承担哪些工程责任。

一、uGDS 想解决什么问题

先看一条常见的数据读取路径：

NVMe SSD
   │
   ▼
内核 NVMe 驱动 → 块层 → 文件系统
   │
   ▼
主机内存缓冲区
   │
   ▼
GPU 显存

即使系统支持 Direct I/O，应用仍然通常要进入内核，由内核驱动准备 NVMe 命令、完成 DMA 映射并处理中断或轮询。若数据还要经过主机内存，再复制到 GPU，路径会更长。

NVIDIA GPU-Initiated Data Storage（GIDS）详解：让 GPU Kernel 主动访问存储

Wed, 19 Aug 2026 14:05:00 +0800

GPUDirect Storage（GDS）已经能够让存储数据绕过 CPU 内存，直接进入 GPU 显存。但经典 GDS 仍有一个重要特征：I/O 请求由 CPU 侧应用代码提交。

当 GPU kernel 在执行过程中才知道下一份数据位于哪里时，控制权必须在 GPU 与 CPU 之间往返。对于图计算、向量检索、稀疏模型和超大规模数据分析，这种细粒度同步可能比数据传输本身更昂贵。

NVIDIA GPU-Initiated Data Storage，简称 GIDS，试图进一步消除这层控制瓶颈：让 GPU kernel 直接发起存储 I/O，使 GPU 不仅是数据的接收者，也是 I/O 请求的生产者。

本文介绍 GIDS 的动机、架构、工作流程、适用场景，以及它和 GDS 的本质区别。

一、为什么有了 GDS 还需要 GIDS

GDS 优化了数据路径：

CPU 发起请求
     │
     ▼
存储 ─────────────► GPU 显存
       数据不经过 CPU 内存

这已经消除了大量主机内存中转，但控制路径仍然经过 CPU。经典流程可能是：

GPU 执行 kernel；
GPU 产生下一批要访问的数据索引；
kernel 结束或与 CPU 同步；
CPU 读取结果并构造文件 I/O；
CPU 调用 cuFile；
数据进入 GPU；
CPU 再次启动 kernel。

如果每次请求都是大块、批量且可提前预测，这种方式通常没有问题。但如果 GPU 在计算过程中产生数以万计甚至更多的动态访问，频繁的 GPU—CPU 往返会带来：

NVIDIA GPUDirect Storage（GDS）详解：让存储数据绕过 CPU 直达 GPU

Wed, 19 Aug 2026 14:00:00 +0800

在 AI 训练、科学计算和数据分析系统中，GPU 的算力越来越强，但数据从存储设备进入 GPU 的路径却可能成为瓶颈。传统 I/O 通常要先把数据读入 CPU 内存，再复制到 GPU 显存，不仅增加内存带宽消耗，还让 CPU 承担大量数据搬运工作。

NVIDIA GPUDirect Storage，简称 GDS，解决的正是这个问题：它在存储设备与 GPU 显存之间建立更直接的数据路径，使应用能够通过 cuFile API 将文件数据读入 GPU 缓冲区，减少 CPU bounce buffer 和不必要的数据复制。

本文介绍 GDS 的工作原理、软件栈、典型使用方式、适用场景以及它与 GPU-Initiated Data Storage（GIDS）的关系。

一、传统 GPU I/O 为什么效率不高

传统文件读取到 GPU 的路径大致如下：

NVMe / 文件系统
       │
       ▼
CPU 内存缓冲区
       │ cudaMemcpy
       ▼
GPU 显存

应用通常先调用 read、pread 或异步 I/O 接口，把文件内容读入主机内存，然后再调用 CUDA memcpy 将数据复制到 GPU。

这条路径存在几个问题：

同一份数据先经过 CPU 内存，再进入 GPU 显存；
存储流量和 GPU 传输流量竞争 CPU 内存带宽；
CPU 需要提交、管理和完成数据搬运；
大规模 GPU 系统中，CPU 和内存通道容易成为共享瓶颈；
应用需要维护主机端 staging buffer，并处理双重缓冲。

当 GPU 计算越来越快、单机挂载更多 NVMe 或更高速的并行文件系统后，这些额外开销会更加明显。

数据库 MVCC 原理与实现：版本链、事务快照和可见性判断

Fri, 14 Aug 2026 23:50:00 +0800

MVCC（Multi-Version Concurrency Control，多版本并发控制）是现代数据库实现高并发事务的重要机制。它的核心思想并不复杂：数据被修改时，不立即丢弃旧值，而是保留多个版本；事务读取数据时，根据自己的快照选择可见版本。

因此，读事务可以继续访问旧版本，写事务则创建新版本。普通读取通常不需要等待并发写入完成，写入也不必等待读事务释放共享锁。

本文从 MVCC 要解决的问题出发，依次说明版本存储、事务快照、可见性判断、写冲突控制和旧版本回收，并比较 InnoDB 与 PostgreSQL 的典型实现。

一、为什么需要 MVCC

假设数据库中存在一条记录：

账户 A 的余额 = 100

事务 T1 正在读取这条记录，与此同时，事务 T2 希望把余额修改为 80。

如果所有读取都依赖共享锁，那么 T2 可能必须等待 T1 结束；如果 T2 已经持有排他锁，T1 又可能必须等待 T2。锁能够保证正确性，但大量读写互相等待会降低系统并发能力，并增加死锁概率。

MVCC 使用另一种思路处理普通读取：

新版本：balance = 80，由 T2 创建
                 ↓
旧版本：balance = 100

如果 T1 的事务快照不允许它看到 T2 的修改，T1 就读取旧版本 100；在 T2 提交后启动的新事务，则可以读取新版本 80。

于是，同一时刻可以出现：

旧事务看到 100
新事务看到 80

这不是数据不一致，而是两个事务观察到了数据库在不同逻辑时刻的一致状态。

二、MVCC 的五个组成部分

一个完整的 MVCC 实现通常包含五个部分：

MVCC = 多版本存储
     + 事务快照
     + 可见性判断
     + 写冲突控制
     + 旧版本回收

只保存历史版本还不够。数据库还必须知道版本由谁创建、事务能够看到哪些版本、两个写事务冲突时如何处理，以及历史版本何时可以安全删除。

3FS 如何使用 FoundationDB：元数据模型、事务与并发控制

Fri, 14 Aug 2026 19:10:00 +0800

3FS 是面向 AI 训练和推理负载设计的分布式文件系统。它没有把 FoundationDB 当成普通的持久化 KV 使用，而是围绕 FoundationDB 的有序键空间、乐观事务、冲突检测和 Versionstamp，构建了一套强一致的文件系统元数据服务。

本文从源码出发，梳理 3FS 如何接入 FoundationDB，如何编码 inode 和目录项，以及 create、rename、remove、list 等文件系统操作怎样映射为 FoundationDB 事务。

本文分析的源码位于 3FS 仓库中的以下目录：

src/fdb/             FoundationDB C API 封装
src/common/kv/       通用 KV 和事务接口
src/meta/store/      inode、目录项和元数据操作
src/meta/components/ ID 分配、服务分布和 GC 等组件
src/meta/service/    Meta Service RPC 入口

一、3FS 中 FoundationDB 的定位

3FS 将数据面和元数据面分开：

文件的 chunk 数据由 Storage Service 保存。
文件系统元数据由 Meta Service 管理，并持久化到 FoundationDB。

FoundationDB 中保存的主要内容包括：

inode；
directory entry，也就是目录项；
文件打开会话；
RPC 幂等记录；
Meta Server 分布信息；
用户、配置和其他全局状态。

整体调用链可以简化为：

FoundationDB 事务如何实现？从源码看 GRV、Resolver、TLog 与 Storage Server

Fri, 14 Aug 2026 17:00:00 +0800

FoundationDB 支持跨任意 key range 的 ACID 事务，并向应用提供严格可串行化语义。但它既没有让每个 Storage Server 参与经典的两阶段提交，也不是传统单机数据库中“共享缓冲池 + Undo/Redo”的事务实现。

它的核心方案可以概括为：

全局版本号 + MVCC 快照读 + 客户端暂存修改 + Resolver 乐观冲突检测 + 多副本 TLog 持久化。

本文结合 FoundationDB 官方源码，沿着一笔事务的完整路径，解释它如何从读取、提交、冲突检测，一直走到日志持久化和 Storage Server 应用。

本文分析的源码版本为：

commit: eab21ffe07c20575d5bac9ab0745375b8f7f8357
date:   2026-08-12

源码中的具体行号会随版本变化，阅读时应以函数和类型名为主要定位依据。

一、整体架构

FoundationDB 的事务涉及以下核心角色：

角色	主要职责
Client	保存事务 mutations、读冲突范围和写冲突范围
GRV Proxy	分配 Read Version
Commit Proxy	批量接收事务、分配 Commit Version、组织提交流水线
Resolver	检测乐观事务冲突
TLog	复制并持久化已提交 mutations
Storage Server	提供版本化读取，异步应用 TLog mutations
Sequencer	为事务系统提供版本推进基础

完整流程可以简化为：

Client
  │
  ├── 获取 Read Version
  │
  ├── 从 Storage Server 读取该版本
  │
  ├── 在客户端积累 mutations 和 conflict ranges
  │
  └── 提交
        │
        ▼
   Commit Proxy
        │
        ├── 组成 Commit Batch
        ├── 分配 Commit Version
        └── 按 key range 发给 Resolver
        │
        ▼
     Resolver
        │
        ├── 检查 read conflict ranges
        ├── 登记 write conflict ranges
        └── 返回 committed / conflict / too old
        │
        ▼
   Commit Proxy
        │
        ├── 丢弃冲突事务
        ├── 为 mutation 添加 Storage Server tag
        └── 将成功事务写入 TLog
        │
        ▼
       TLog
        │
        ├── 按冗余策略复制和持久化
        └── 返回 durable
        │
        ▼
   Commit Proxy
        │
        └── 向 Client 返回 Commit Version
        │
        ▼
 Storage Server
        ├── 异步读取自己的 tagged mutations
        ├── 应用到内存中的版本化数据
        └── 后台持久化到 Storage Engine

最关键的解耦是：

FoundationDB 中有 Undo 和 Redo 吗？从 TLog、MVCC 到故障恢复

Fri, 14 Aug 2026 10:00:00 +0800

传统数据库通过 Undo Log 和 Redo Log 保证事务的原子性与持久性：Undo 撤销未提交的修改，Redo 恢复已经提交但尚未写入数据文件的修改。那么，在采用分布式事务架构的 FoundationDB 中，是否也存在这两类日志？

简短回答是：

FoundationDB 有承担类似 Redo 职责的 TLog，但通常没有传统意义上的 Undo Log。

这并不意味着 FoundationDB 不支持事务回滚或 MVCC，而是因为它对未提交数据、提交日志和历史版本的组织方式与传统数据库不同。

一、先回顾传统数据库为什么需要 Undo 和 Redo

传统数据库通常允许事务直接修改缓冲池中的共享数据页。数据页何时写入磁盘，与事务何时提交并不完全同步。

因此会出现两种状态。

1. 事务未提交，数据页却已经落盘

例如事务把账户余额从 100 改成 80，但随后事务失败：

BEGIN;

UPDATE account
SET balance = 80
WHERE id = 'A';

ROLLBACK;

如果包含 80 的脏页已经写入磁盘，数据库就必须知道原值是 100，才能撤销这次修改。这是 Undo Log 的主要职责。

2. 事务已经提交，数据页却尚未落盘

另一个事务已经执行 COMMIT，但修改可能仍然只存在于内存中的脏页里。如果服务器此时断电，已提交的数据就会丢失。

因此数据库先持久化 Redo Log，再返回提交成功。重启后，即使数据页没有及时落盘，也可以通过 Redo 重新应用修改。

可以把二者概括为：

Undo：事务不应该生效，但修改可能已经进入数据文件。
Redo：事务应该生效，但修改可能还没有进入数据文件。

二、FoundationDB 的事务提交流程

FoundationDB 并不是把客户端事务中的每次 set 或 clear 立即写入 Storage Server。事务提交前，这些操作首先保存在客户端的事务对象中。

哈希碰撞概率与生日界：从公式到 SHA-256 / XXH128 实测

Tue, 11 Aug 2026 15:10:00 +0800

选哈希算法时常有两个问题绑在一起：碰撞概率有多小、算得有多快。这篇把碰撞概率背后的数学（生日界）讲清楚，再用它算一算 256-bit 的 SHA-256/BLAKE3 与 128-bit 的 XXH128 各自的碰撞概率，最后附上一组本机实测速度数据。

本文所有实测数据均来自随机生成的字节串，不含任何业务或私有数据。

一、背景：碰撞概率的两种含义

对固定长度输出的哈希，“碰撞概率"必须分两种场景谈，否则会得出互相矛盾的结论：

随机碰撞：没有攻击者，数据是正常/随机的。这时只要输出在取值空间里均匀分布，碰撞概率就纯粹由输出位数决定，与具体算法无关。
抗恶意碰撞：有攻击者知道算法、故意构造两个哈希相同的输入。这里才真正区分加密哈希（SHA-256、BLAKE3、BLAKE2）和非加密哈希（xxHash、CityHash、Murmur）。

第一种是数学问题，用生日界就能算。第二种是密码学性质，非加密哈希直接不提供保证。

二、生日问题：直觉的陷阱

一个房间里要多少人，才有超过 50% 的概率存在两人同一天生日？答案是 23 人——远比直觉小。原因在于碰撞看的不是"某人和我同天”，而是"任意两人之间"的配对数：n 个人有 n(n-1)/2 ≈ n²/2 对，概率随 n² 增长。

哈希碰撞是同一个问题：把"人"换成"哈希输入"，把"365 天"换成"哈希空间大小 N"。对 128-bit 哈希，N = 2^128。

三、生日界公式的推导

设哈希空间大小为 N，独立均匀地放入 n 个值。直接算"至少一次碰撞"要用容斥，很麻烦，所以反过来算"全部不同"的概率：

第 1 个：随便放         → N/N
第 2 个：不能撞前 1 个  → (N-1)/N
...
第 n 个：不能撞前 n-1 个 → (N-n+1)/N

全部不同的概率是连乘：

P(无碰撞) = ∏_{k=0}^{n-1} (1 - k/N)

于是至少一次碰撞：

P(碰撞) = 1 - ∏_{k=0}^{n-1} (1 - k/N)

这是精确解，但连乘不好用。用近似 1 - x ≈ e^(-x)（x 很小时成立）把每一项换掉：

技术 on Hellokitty's Blog

Rust 异步编程原理：Future、状态机、Waker 与 Executor

PCIe BAR 深入解析：从设备地址窗口到 DMA 与 GPUDirect Storage

一、先建立 PCIe 系统视图

Rust Tokio 深入解析：运行时原理、并发模型与最佳实践

一、Tokio 提供了什么

Mooncake Transfer Engine 源码阅读（四）：TENT 下一代架构如何重构传输引擎

一、为什么需要下一代引擎

二、目录结构

Mooncake Transfer Engine 源码阅读（三）：RDMA、TCP 与请求完成状态机

一、Transport 抽象

二、RDMA 初始化

Mooncake Transfer Engine 源码阅读（二）：Segment、内存注册与元数据服务

一、为什么不能直接发送指针

二、SegmentDesc

Mooncake Transfer Engine 源码阅读（一）：统一传输 API 与整体架构

一、源码布局

二、公共 API 是一层门面

nvidia-fs 源码阅读（三）：文件 I/O、批处理、完成路径与诊断

一、I/O 入口

二、nvfs_io_init 做了什么

nvidia-fs 源码阅读（二）：GPU 内存注册、影子页与 DMA 映射

一、问题本质

nvidia-fs 源码阅读（一）：模块初始化、设备接口与整体架构

一、源码目录

GDS、GIDS 与 uGDS 有什么区别：从数据直达、GPU 发起到用户态 NVMe

一、先区分数据路径与控制路径

数据路径

uGDS 原理解析：在用户态打通 NVMe SSD 与 GPU 显存

一、uGDS 想解决什么问题

NVIDIA GPU-Initiated Data Storage（GIDS）详解：让 GPU Kernel 主动访问存储

一、为什么有了 GDS 还需要 GIDS

NVIDIA GPUDirect Storage（GDS）详解：让存储数据绕过 CPU 直达 GPU

一、传统 GPU I/O 为什么效率不高

数据库 MVCC 原理与实现：版本链、事务快照和可见性判断

一、为什么需要 MVCC

二、MVCC 的五个组成部分

3FS 如何使用 FoundationDB：元数据模型、事务与并发控制

一、3FS 中 FoundationDB 的定位

FoundationDB 事务如何实现？从源码看 GRV、Resolver、TLog 与 Storage Server

一、整体架构

FoundationDB 中有 Undo 和 Redo 吗？从 TLog、MVCC 到故障恢复

一、先回顾传统数据库为什么需要 Undo 和 Redo

1. 事务未提交，数据页却已经落盘

2. 事务已经提交，数据页却尚未落盘

二、FoundationDB 的事务提交流程

哈希碰撞概率与生日界：从公式到 SHA-256 / XXH128 实测

一、背景：碰撞概率的两种含义

二、生日问题：直觉的陷阱

三、生日界公式的推导

二、`SegmentDesc`

二、`nvfs_io_init` 做了什么