从零开发分布式文件系统（5.1）:告别传统I/O栈，开启用户态驱动与异步并发的NVMe时代

零开发分布式文件系统（5.1）：告别传统I/O栈，开启用户态驱动与异步并发的NVMe时代

把面试官当陪练，在找工作中才会越战越勇

大家好我是小义同学，这是大厂面试拆解，如果有误，请指正。

本文主要解决的一个问题

为了避免眼高手低，自吹自擂 本文根据

论文 <<What Modern NVMe Storage Can Do, And How To Exploit It: High-Performance I/O for High-Performance Storage Engines>>

如果不熟悉文件系统有没关系，想想如何从进程，线程，协程角度考虑 如何解决并发问题

提问：论文解决的 6 个问题

裸盘：单台服务器内 多块NVMe SSD 可实现每秒千万

什么样的存储引擎设计榨这些特性，弥合硬件与软件之间的性能鸿沟（说明目前ceph不行）# 从三万英尺角度谈一下Ceph

深刻影响一个分布式文件系统的存储引擎设计因素那些？ 论文的代码：https://github.com/leanstore/leanstore/tree/io （4KB页的优势、SPDK/io_uring的选择、用户态任务调度的重要性、全对全I/O模型等）

1. Q1: Can arrays（阵列） of NVMe SSDs achieve （取得）the performance promised in the hardware specifications?
   • 研究 NVMe SSD 阵列是否能达到硬件规格所承诺的性能。
   • 实验中验证了 8 块 Samsung PM1733 SSD 能达到 12.5 M （千万）IOPS，略高于理论值 12 M IOPS 。
   • 一块高性能的 SATA SSD 的随机读取IOPS约为 10万 (0.1M) 级别。 一块消费级 NVMe SSD 的随机读取IOPS可达 50万至100万 (0.5-1M) 级别。 论文中通过8块企业级NVMe SSD组成的阵列，实现了 1250万 (12.5M) IOPS。这比单块高端消费级SSD快了10倍以上。这已经接近了测试所用 PCIe 4.0 x8 总线带宽的理论上限，充分“榨干”了硬件潜力
2. Q2: Which I/O API (pread/pwrite, libaio, io_uring) should be used? Is it necessary to rely on kernel-bypassing （内核旁路）(SPDK Storage Performance Development Kit”)?
   • 比较不同 Linux 异步 I/O 接口的性能与适用性，并探讨是否需要采用 SPDK 这种内核旁路方案。
   • 结论：io_uring（开启轮询）可达到全带宽，SPDK CPU 效率更高但在实际部署上有局限
3. Q3: Which page size should storage engines use to get good performance while minimizing I/O amplification?
   • 确定存储引擎的最佳页大小，以在性能与 I/O 放大之间取得平衡。
   • 实验表明 4 KB 页在随机读 IOPS、吞吐、延迟方面是最佳折衷 。
4. Q4: How to manage the parallelism required for high SSD throughput?
   • 如何管理实现高 SSD 吞吐量所需的并行度。
   • 提出使用协作式多任务（cooperative multitasking）与轻量级用户态线程，避免线程过度订阅 。
5. Q5: How to make a storage engine fast enough to be able to manage tens of millions of IOPS?
   • 如何让存储引擎足够快以支撑千万级 IOPS 的管理。
   • 通过分区锁、无锁数据结构、微优化关键路径等手段提升扩展性 。
6. Q6: Should I/O be performed by dedicated I/O threads or by each worker thread?
   • I/O 应由专用 I/O 线程执行，还是由每个工作线程直接处理。
   • 结论：采用 all-to-all 模型，由工作线程直接处理 I/O，可避免消息传递与同步开销，提高鲁棒性

Part1 NVMe is King

前面写不少文章 关于

如何在不升级硬件的前提下,小文件并发读写性能提升十倍，

• 从零开发分布式文件系统(一) :100G读写带宽,百万IO请求文件系统怎么实现的
• 从零实现分布式文件系统(二) 如何在不升级硬件的前提下,小文件并发读写性能提升十倍)
• 从零开发分布式文件系统(三) :JuiceFS｜沧海｜3FS 百万 OPS 答疑
• 从零开发分布式文件系统（四):一道经典面试题，深度对比 CephFS 与 3FS 的元数据架构优劣

理想是美好的，但是现实是,这样不挣钱呀

2025 长沙世界计算大会

• 闭源的 华为 Atlas 950 SuperCluster 50 万卡超集群 依靠数量取胜，根本不依靠单个性能

肯定必须使用 NVMe阵列，不然根本无法支持这样计算

• 浪潮信息HF5000G5是一款面向企业核心应用的中端全闪存储系统，拥有更低的时延、更高的性能、更强的弹性扩展能力等特性。HF5000G5采 用全新的NVMe架构

查缺补漏 什么是NVMe

HDD、NVMe SSD、SAS SSD区别

HDD NVMe SSD SAS SSD NVMe 协议

NVMe的全称是 Non-Volatile Memory Express， 即非易失性存储器快速通道。 它是一种用于连接计算机系统与闪存存储设备（如固态硬盘）之间的通信协议和接口标准

目的是为了解决传统的 SATA 和 AHCI 接口在支持闪存技术（尤其是PCIe SSD）时的性能瓶颈。 基于PCIe总线的设计使得NVMe能够充分发挥闪存的高性能潜力

为NVMe的出现，硬盘的性能得到了极大的提升

读带宽从500MB/s提高到了3200MB/s， 写带宽从400MB/s提高到了1200MB/s左右。而读IOPS则达到了50万，

• HDD（机械硬盘）：以旋转磁盘保存数据，特点是容量大、成本低、延迟高，适合大容量与冷数据场景。顺序吞吐常见约150–200 MB/s，随机性能为几十到数百 IOPS。
• SSD（固态硬盘）：以NAND 闪存保存数据，无机械部件，低延迟、高并发，适合系统盘、数据库、虚拟化等。按接口分为SATA SSD、SAS SSD、NVMe SSD。
• NVMe 协议：专为PCIe通道设计的存储协议，命令精简、并行队列深，显著降低协议开销，释放 SSD 性能；与 SATA/AHCI、SAS/SCSI 属于不同协议栈与传输路径。
• 组合关系：NVMe SSD = NVMe 协议 + PCIe 通道；SAS SSD = SAS 协议 + 12 Gb/s（SAS3）/24 Gb/s（SAS4） 通道；SATA SSD = SATA 协议 + 6 Gb/s 通道；HDD 常见走 SATA 或 SAS 通道
• 画外音：NVMe是标准协议，本文代指 NVMe SSD盘

查缺补漏： NVMe为何比SATA快百倍

SATA的遗产：AHCI的单队列竞争模型

AHCI作为SATA设备的主流接口标准，其设计深受其所处时代的技术背景影响。 它为机械硬盘而生，其队列模型也完美地反映了这一点。

NVMe的革命：大规模并行的无锁模型

• 极致低延迟：协议栈精简，命令处理路径极短，将访问延迟从旧协议的毫秒级降低至微秒级，对数据库事务、实时分析至关重要。
• 超高吞吐量：充分利用PCIe通道的高速带宽。一个PCIe 4.0 x4的NVMe SSD理论带宽可达近8 GB/s，远超SATA III的600 MB/s上限。
• 海量并发IOPS：这是NVMe设计的精髓。它支持高达64K个I/O队列，且每个队列深度同样可达64K。相比之下，旧式AHCI协议仅支持1个队列，深度为32。
• 这使得NVMe能驱动现代多核CPU同时发起海量I/O请求，轻松实现百万级甚至千万级IOPS

Part2 What Modern NVMe Storage Can Do, And How To Exploit It

图1

图1

通过图片你会发现1 8个ssd盘 达到千万 IOPS ，未来NVMe的阵列接近直接访问内存型

在过去十年中，闪存固态硬盘（flash SSDs）已取代磁盘，成为操作型数据库系统的默认持久存储介质

In the past decade, flash SSDs have displaced magnetic disks as the default persistent storage medium for operational database systems.

NVMe的阵列接近直接访问内存型

• PCIe 5.0 are already available and corresponding(相应) SSDs with 12 GB/s per device have been announced.(宣告)

This means that arrays of NVMe

SSDs are approaching DRAM bandwidth

• PCIe 4.0

图片1 说明 现有软件因陈旧的I/O和并发模型 无法发挥硬件性能，**性能鸿沟，很大

system I/O capability: 12.5M IOPS： 系统I/O能力为每秒1250万次输入输出操作， 这是一个硬件层面的性能上限指标， 表明了当前硬件配置下能够支持的最大I/O操作频率

1. 数据结构与写入放大
   • MySQL (InnoDB)：使用B+Tree，数据以固定大小的页（如16KB） 组织。
   • 更新数据时，需要在原位置“就地更新” 整个页，并写WAL日志。
   • 这导致写入放大，且随着运行会产生碎片，影响后续读取的连续性。
   • RocksDB：使用LSM-Tree。所有写入先进入内存（MemTable），再顺序刷写到磁盘，形成多层只读的SSTable文件。
2. 读取路径与缓冲管理（这是性能差异的核心！）
   • MySQL (InnoDB)：严重依赖全局缓冲池。所有数据页必须先加载到缓冲池才能被访问。在数据量（100GB）远大于缓冲池（10GB） 时，会发生激烈且昂贵的页面淘汰。
   • RocksDB：没有传统的全局页缓存概念。读取时，它同时查询内存中的MemTable和磁盘上的多级SSTable文件。

图片1 说明 ：开启1千，2千个线程无法解决这些问题

总结

写半天，才看了论文的第一段，总结部分，第一个图片

后续：

4KB页的优势、SPDK/io_uring的选择、用户态任务调度的重要性、全对全I/O模型等

参考资料

1. https://www.ieisystem.com/global/file/2023-11-29/17012398973022c975afc8bfb91fe968018c19ccbcd6344c.pdf
2. https://zhuanlan.zhihu.com/p/1970458833076852677
3. https://www.toutiao.com/article/7572499116496831018/
4. https://www.miit.gov.cn/xwfb/bldhd/art/2025/art_047848b5da33494581c408ee80726ba2.html
5. https://www.kingston.com.cn/en/ssd/what-is-nvme-ssd-technology
6. Understanding SSD Technology: NVMe, SATA, M.2, accessed on July 27, 2025, https://www.kingston.com/en/ssd/what-is-nvme-ssd-technology
7. M.2 vs PCIe vs. NVMe vs SATA vs AHCI: Ultimate Showdown - StoredBits.com, accessed on July 27, 2025, https://storedbits.com/m-2-vs-pcie-vs-nvme-vs-sata-vs-ahci/
8. NVM Express - Wikipedia, accessed on July 27, 2025, https://en.wikipedia.org/wiki/NVM_Express
9. https://www.cnet.com/tech/computing/hard-drive-ssd-nvme-m-2-whats-best/

别想太多--只管去面