Storforge
原理预计 50 分钟

运维人的 Rust 心智模型

不从零学语法，只讲运维人最容易卡住的四件事：所有权像文件句柄、Result 像 exit code、trait 像接口约定、生命周期像挂载引用计数。

学完这节你能做到

  • 用自己的话解释所有权、借用、move 在解决什么问题
  • 写出用 Result / ? 传播错误的函数，不再滥用 unwrap
  • 读懂 trait 约束的函数签名，知道去哪里查文档

不学语法,学心智模型

你不需要把《The Rust Programming Language》从头啃一遍才能开工 —— AI 会补语法细节。你需要的是心智模型:Rust 的几个核心概念到底在解决什么问题。 好消息是,这几个问题你在运维里全都见过,只是当时它们叫别的名字。

这节课只讲四件事:所有权、借用、Result、trait。生命周期标注、async、unsafe 都刻意不讲 —— 到用它们的那节课再学,带着问题学才记得住。

所有权:谁负责 close 这个 fd

运维时你处理过 fd 泄漏:进程打开文件不关,lsof 一看几万个句柄。 根源是 C/C++ 世界的老问题:资源是谁的、谁负责释放,全靠人肉约定。

Rust 把这个约定写进了编译器:

fn main() {
    let f = std::fs::File::open("/etc/hosts").unwrap(); // f 拥有这个文件句柄
    read_all(f);       // 所有权 move 给了 read_all
    // read_all(f);    // 编译错误!f 已经被移走,你手里没有了
}   // read_all 结束时,句柄自动 close —— 不存在"忘了关"

三条规则,就这么多:

  1. 每个值有且只有一个所有者
  2. 所有权可以转移(move),转走后原变量作废
  3. 所有者离开作用域,值被自动释放(文件关闭、内存回收、锁释放)

fd 泄漏、double free、use-after-free —— 这一类 bug 在安全 Rust 里编译期灭绝。 对存储系统来说这就是命:我们后面要管理的是盘上 extent、内存 buffer、网络连接, 每一样都是「忘了释放会出事」的资源。

借用:读写锁的编译期版本

把值 move 来 move 去太麻烦,更多时候你只是想「借来用用」:

fn checksum(data: &[u8]) -> u32 { /* 只读借用:& */ }
fn compress(data: &mut Vec<u8>) { /* 可变借用:&mut */ }

借用规则你一听就懂,因为它就是你熟的读写锁语义:

  • 同一时刻,要么任意多个只读借用,要么恰好一个可变借用 —— 读共享、写独占

区别在于:读写锁在运行时拦截违规(死锁、竞争让你半夜起来), 借用检查器在编译期拦截 —— 数据竞争根本活不到上线。 你会经常被它拦下来骂,记住:它拦的每一下,都是别的语言里的一次线上事故。

Checkpoint单选

Rust 的借用规则「多个只读 XOR 一个可变」,最贴切的运维类比是?

Result:错误是 exit code,不是异常

你写 shell 脚本时的信条:set -e,每个命令都检查返回码。 Rust 的错误处理和这个思路同源 —— 错误是返回值的一部分,不是从天而降的异常:

fn read_superblock(path: &Path) -> Result<Superblock, StoreError> {
    let bytes = std::fs::read(path)?;        // ? = "失败就带着错误提前 return"
    let sb = Superblock::decode(&bytes)?;    // 相当于 shell 的 || return
    if sb.magic != MAGIC {
        return Err(StoreError::BadMagic { found: sb.magic });
    }
    Ok(sb)
}
  • Result<T, E> 要么 Ok(值) 要么 Err(错误),调用者必须表态,想装看不见,编译器不让
  • ? 运算符 = 「失败就向上传播」,相当于 set -e 但精确到每个表达式
  • unwrap() = 「失败就崩」。测试里随便用;生产路径上每个 unwrap 都要能答出"为什么这里不可能失败"

存储系统里错误处理就是产品本身:一次 EIO 是该重试、该标坏盘、还是该报给上层? Result 强迫每一层把这个决定写清楚 —— 再也没有「被吞掉的异常」。

trait:接口约定,引擎可插拔的根基

trait 声明「会干什么」,类型各自实现 —— 你可以理解为「协议/接口」:

/// 任何"能当存储后端用"的东西
pub trait BlobStore {
    fn put(&mut self, key: &[u8], value: &[u8]) -> Result<(), StoreError>;
    fn get(&self, key: &[u8]) -> Result<Option<Vec<u8>>, StoreError>;
}

L1 我们写真引擎实现它;L5 的确定性模拟测试再写一个故意注入故障的假引擎, 也实现它 —— 上层代码一行不改就能在两种后端上跑。面向 trait 编程, 就是给未来的自己留后门,这个伏笔六个阶段后兑现。

读文档时你会见到 fn open<P: AsRef<Path>>(path: P) 这种签名,读法: 「P 是任何能当作 Path 引用的类型」—— 所以 &str、String、PathBuf 都能传。 看不懂的签名,直接抓给 AI:「用人话解释这个签名」。

×转型期最常见的三个坑

1. 见错就 unwrap:AI 示例代码尤其爱这样。生产路径一律 ? + 明确的错误类型。
2. 和借用检查器硬顶:被拦住时先别 clone 了事,问 AI「为什么这里过不了,惯用解法是什么」—— 十有八九是设计在提醒你所有权没想清。
3. 过早优化生命周期:到处标 &'a 想省拷贝。前三个阶段大方地用 clone() 和 Vec,先把系统跑通,L5 调优时再算这笔账。

Checkpoint单选

AI 生成的落盘代码里有一行 file.write_all(&buf).unwrap(),你该怎么处理?

⚡AI 结对:给 forge-util 加校验和模块pair with ai

注意提示词最后一句 —— 让 AI 反过来考你,是检验「代码是不是真看懂了」的好办法。 这个 checksum 模块不是练习品:L1 的 blob store、WAL,L3 的 EC 条带,全都要用它。

在 forge workspace 的 forge-util crate 里新增一个 checksum 模块:

1. 定义 trait Checksum { fn update(&mut self, data: &[u8]); fn finalize(&self) -> u32; }
2. 用 crc32c crate 实现 Crc32c 结构体,实现该 trait;
3. 提供便捷函数 crc32c_of(data: &[u8]) -> u32;
4. 单元测试:空输入、"hello world" 的已知 crc32c 值、分两次 update 与一次性 update 结果一致;
5. 所有公开项写文档注释,说明为什么存储引擎选 crc32c(硬件加速指令)而不是 md5。

完成后跑 cargo test -p forge-util 和 cargo clippy,贴结果。做完请向我提问 3 个问题,检验我是否理解了 trait 在这段代码里的作用。

小结

  • 所有权 = 编译期的资源台账;借用 = 编译期的读写锁;这两样消灭的都是你熬过夜的那类事故
  • Result + ? = 精确到表达式的 set -e;生产路径禁裸 unwrap
  • trait = 接口约定,给 L5 的可测试性埋下伏笔
  • L0 到此结束 —— 仓库有了、CI 绿了、心智模型建好了。L1 开始造真东西:单机存储引擎

延伸资料

下一课：文件 IO 的三条通路 →