原理预计 35 分钟

你要造的东西：解剖 Weka NeuralMesh

先看终点再出发。把 Weka 的前端/计算/驱动三层、bucket 虚拟元数据、条带化 EC 拆开讲，倒推出我们 6 个阶段的路线图。

学完这节你能做到

说清 Weka NeuralMesh 与 Ceph 在架构取舍上的三个本质区别
把一个分布式文件系统拆成数据通路、元数据、集群管理三个子问题
对照路线图说出每个阶段的里程碑分别验证什么能力

从你挂载过的东西说起

做存储运维的人,大概率碰过这几类文件系统:NFS 挂上就能用但快不起来;CephFS 功能全但延迟抖; GPFS/Lustre 快,但架构里总有几个「专职角色」(MDS、NSD server)让你半夜心惊; 而如果你摸过 Weka,会发现它宣传的东西听起来不太科学 —— 全 NVMe、延迟接近本地盘、元数据性能随节点数线性扩展、重建反而是节点越多越快。

这节课回答两个问题:Weka(现在叫 NeuralMesh)凭什么做到这些?以及, 我们接下来六个阶段要仿制它的哪一部分?

Weka 的三层进程模型

传统文件系统的服务端是「一个大进程管一台机器」。Weka 反着来:把每台机器切成若干个 独占 CPU 核的小进程,各干一件事:

角色	干什么	类比
Frontend	接客户端请求(POSIX/NFS/S3),做协议翻译	Ceph 的 client + MDS 入口
Compute	文件系统逻辑:元数据、条带、EC 计算	Ceph 的 OSD 逻辑层 + MDS
Drive	直接驱动一块 NVMe(用户态,SPDK 思路)	Ceph 的 BlueStore 底层

三个关键决策,每个都和你运维时见过的痛点对得上:

独占 CPU 核、busy polling —— 没有上下文切换,没有中断,延迟稳定。你在监控里看过 %si 飙高、进程被调度走导致的延迟毛刺,Weka 用「不共享 CPU」直接消灭这类问题。
用户态 NVMe 驱动 —— IO 不经过内核块层和文件系统层。你调过 scheduler、nr_requests 这些参数,Weka 的答案是:整条内核 IO 栈都不要了。
网络也是用户态(DPDK) —— 同理,绕开内核协议栈。

iNeuralMesh 是什么

2025 年起 Weka 把产品线更名为 NeuralMesh,架构主体仍是上述 WekaFS 核心, 加上面向 AI 负载的编排与增强(如 Augmented Memory Grid)。本教程说「Weka」指这套核心架构。

bucket:元数据为什么能横向扩展

CephFS 的 MDS、Lustre 的 MDT、GPFS 的 token manager —— 你运维过的系统里, 元数据几乎总是那个「加机器也没用」的瓶颈。

Weka 的做法:把整个文件系统的元数据空间哈希切成海量小份(bucket), 每个 bucket 是一个独立的「虚拟元数据服务器」,由某个 Compute 进程持有。节点挂了,它持有的 bucket 会被其他节点接管;扩容了,bucket 重新分布。

元数据不再是「一个或几个 MDS」,而是成千上万个可搬运的小单元
两个目录、甚至同一目录的两个文件,元数据可能由不同节点服务 —— 并发天然摊开
bucket 的接管、搬迁由集群共识层协调

这就是「元数据性能随节点数线性扩展」的原理 —— 没有魔法,是分片粒度足够细。

数据通路:条带 + EC + 日志式聚合

数据面上,Weka 把文件切成 chunk,凑成条带(stripe)做纠删码,并行写到不同故障域的盘上。和你熟悉的 Ceph EC 池不同的是它对小写的处理:小 IO 先以日志形式追加落盘(保证持久), 后台再聚合成满条带写 —— 所以它的 4k 随机写不遭受 EC 读改写惩罚。

重建也是「众包」的:每块盘上的数据条带均匀散布在全集群,一块盘挂掉, 全集群的盘一起参与补齐 —— 节点越多,每个节点分摊的重建量越小,重建越快。 (对照你运维 RAID 组时「一块 20T 盘重建两天」的体验。)

Checkpoint单选

以下哪一项最准确地概括了 Weka 与 Ceph 在元数据设计上的本质区别?

我们的仿制品:forge

照原样复刻 Weka 需要一支工程师团队干几年。我们砍掉工程量巨大但教学价值低的部分, 保留每一个核心机制:

机制	Weka	forge(我们造的)
语言	C/C++	Rust
NVMe 驱动	SPDK 用户态驱动	io_uring(L2 讲为什么这是合理的折中)
网络	DPDK 用户态协议栈	tonic/gRPC over 内核 TCP
元数据扩展	64k 个 bucket	按 inode 哈希分片(粒度粗一些,机制相同)
数据保护	EC + 日志式小写聚合	同样:reed-solomon 4+2 + 日志聚合
集群共识	自研	openraft
客户端	自研内核模块 + POSIX	FUSE(慢,但先能跑)
快照/分层/S3	有	不做

✓为什么这些简化不毁掉教学价值

io_uring 对 SPDK、FUSE 对内核客户端,都是「同一个问题的低一档解法」—— 问题本身(绕开慢路径、减少拷贝和切换)你会完整经历,并且在里程碑的性能数据里亲眼看到这一档差在哪。看懂了 forge,再读 Weka 白皮书就是「哦,他们把每一层都做到头了」。

六个阶段的路线图

整条路线的设计逻辑:每个阶段解决一个不可回避的问题,收尾于一个可验收的里程碑。

L0 从运维到研发 —— 工具链与心智。出口:forge 仓库骨架 + CI。
L1 单机存储引擎 —— 数据怎么可靠地落一块盘。出口:里程碑① kill -9 不丢数据。
L2 榨干硬件性能 —— 一块 NVMe 的性能怎么吃满。出口:里程碑② 达到标称 IOPS 70%。
L3 走向分布式 —— 多台机器怎么共同存数据。出口:里程碑③ 3 节点掉 1 个不中断。
L4 NeuralMesh 式文件系统 —— 对象存储怎么长成文件系统。出口:里程碑④ mount 上编译代码。
L5 工程化收官 —— demo 和产品之间的距离。出口:forge 1.0。

Checkpoint单选

为什么 L1 要先造单机引擎,而不是直接从分布式开始?

⚡AI 结对:让 AI 当你的架构讲解员pair with ai

这是你的第一个 AI 结对任务 —— 还不用写代码,先练习把 AI 当讲解员用: 把下面的提示词贴进 Claude Code(或你选的工具),对照本节内容看它讲得对不对。重点体会:你给的上下文越具体(「我懂 Ceph」「我见过 EC 小写慢」),它讲得越贴合你。

我是一名存储运维工程师,正在学习分布式存储研发。请阅读 Weka(WekaFS/NeuralMesh)架构白皮书的公开信息,然后:
1. 用 Ceph 的概念做对照(MDS、OSD、CRUSH、BlueStore),解释 Weka 的 frontend/compute/drive 三层进程模型;
2. 解释 bucket 虚拟元数据服务器机制,以及它和 CephFS 多活 MDS 的本质区别;
3. 我运维中见过"EC 池小写性能极差"的现象,解释 Weka 的日志式小写聚合是怎么绕开读改写惩罚的。
每一点都请用"你运维时见过的现象 → 背后的架构原因"的方式讲。

小结

Weka 的快没有魔法:独占 CPU + 用户态 IO/网络消灭延迟抖动,bucket 分片消灭元数据瓶颈, 日志式聚合消灭 EC 小写惩罚,众包重建消灭重建风暴。
forge 保留全部核心机制,把「做到头」的工程(SPDK/DPDK/内核客户端)换成低一档的等价物。
下一节先解决一个更基础的问题:你的代码,谁来写?

延伸资料

下一课：AI 结对开发：你的第二双手 →