【Rust日报】 Fjall：日志结构化、可嵌入的键值存储引擎-深圳市維司達科技有限公司

Fjall：日志结构化、可嵌入的键值存储引擎

Fjall 发布了 v3.0，它是一个用纯 Rust 编写的、基于 LSM-tree（日志结构合并树）的高性能嵌入式键值（KV）存储引擎。

核心定位：Fjall 旨在为 Rust 生态提供一个无 C 依赖（Pure Rust）、轻量级且功能强大的 RocksDB 替代方案。它解决了在使用 RocksDB 时常见的交叉编译困难和复杂的配置问题。

3.0 版本是一个重大的架构升级，主要亮点包括：

引入 Keyspace 概念：这是 3.0 最核心的变化。一个 Keyspace 对应磁盘上的一个目录，内部可以包含多个“分区”（Partitions，类似于 RocksDB 的 Column Families）。这些分区共享同一个预写日志（WAL）和写入缓冲区（Memtable）。
跨分区原子写入：得益于 Keyspace 架构，用户现在可以在单个原子操作中向多个分区写入数据，极大地增强了事务性保证。
性能大幅提升：
- 并行压缩（Compaction）：重写了压缩流程，使其更加高效。
- 分层压缩策略：支持 Size-tiered 和 Leveled 压缩，适应不同的读写负载。
- 改进的索引与缓存：优化了 Bloom Filter 和索引块的加载，减少了磁盘 IO。
资源管理优化：可以通过全局限流器（Rate Limiter）控制整个 Keyspace 的写入吞吐量，并能跨分区分配块缓存（Block Cache）。
API 简化：重新设计了 API，使其更加符合 Rust 的习惯，降低了上手门槛。

社区反馈与讨论：

纯 Rust 的优势：社区最看重的是它没有 C++ 依赖。这意味着在交叉编译到 ARM、Android 或 Windows 时，不会遇到 RocksDB 那样繁琐的工具链问题。
性能对比：作者在讨论中提到，在某些基准测试中，Fjall 的性能已经接近甚至在特定场景下超过了 RocksDB，尤其是考虑到它更轻量、编译更快的特点。
与 Sled 的对比：有用户将其与 Sled（另一个知名的 Rust KV 引擎）进行对比。作者指出，Fjall 选择了 LSM-tree 架构（而 Sled 是 B-tree 变体），在写入密集型任务和持久化稳定性上具有优势。
稳定性与生产环境使用：讨论涉及了 WAL 的可靠性、fsync的处理以及在断电情况下的数据一致性，作者对此给出了技术实现上的信心。
未来计划：作者表达了对异步（Async）支持和进一步优化压缩算法的长期愿景。

如果你正在寻找一个：

阅读：https://fjall-rs.github.io/post/fjall-3/

仓库：https://github.com/fjall-rs/fjall

作者： Kobzol

本文详细记录了他在开发 Rust 合并机器人bors时，排查并修复一个导致 HTTP 请求体在重试过程中神秘消失的“诡异 Bug”的全过程。

问题背景：在对bors进行大规模重构时，一些集成测试偶尔会失败。现象是：bors向模拟的 GitHub API 发送PATCH请求时，请求体（Body）有时是空的，导致服务端解析 JSON 失败。

艰难的排查过程：

初步怀疑：作者起初怀疑是自己的代码逻辑有问题，或者是模拟服务器wiremock或底层库hyper的 Bug。
抓包分析：通过 Wireshark 抓包发现，发送端在第一次请求失败（模拟 500 错误）后，自动发起了第二次请求，而第二次请求确实没有携带 Body。
锁定元凶：作者发现octocrab（GitHub SDK）默认开启了重试机制。当请求失败时，它会尝试重试，但问题就出在重试时的“克隆”逻辑上。

Bug 的根源：浅拷贝（Shallow Clone）：

错误的 Clone 实现：octocrab定义了一个包装类型OctoBody，其内部使用Arc<RwLock<BoxBody>>。
致命缺陷：它的Clone实现只是简单地克隆了Arc指针。
后果：HTTP 请求体通常是流式且“一次性”的。当第一次请求发送后，Body 已经被消费完。重试时，由于克隆的是同一个Arc指针，指向的依然是那个已被消费完的 Body。
静默失败：由于http-body协议的设计，底层库hyper发现 Body 已结束（is_end_stream为 true），便直接发送了一个空请求，而没有报错。

解决方案：

引入深拷贝：作者向octocrab提交了 PR，修改了OctoBody的设计。
缓冲机制：利用bytes库，在创建请求时将 Body 缓冲到内存中（适用于大多数 GitHub API 的小型 JSON 负载）。
try_clone方法：新增了一个可以真正复制 Body 内容的方法。如果 Body 无法被克隆（例如是真正的流），重试机制将安全地跳过而非发送损坏的请求。
修复版本：该修复已在octocrabv0.49.1中发布。

延伸思考

人体工学克隆（Ergonomic Cloning）：作者提到这正说明了 Rust 社区讨论的“显式 Handle 克隆”的重要性——如果能清晰区分“克隆引用（Handle）”和“克隆数据”，这种 Bug 就能在编译期或通过代码审查更容易被发现。
LLM 辅助调试：作者测试了 Claude 是否能发现该 Bug。虽然 LLM 最终指出了问题，但在过程中容易被“异步生命周期”等虚假原因误导，仍需要人类开发者的引导。

总结：这是一个典型的因Arc+ 内部可变性（RwLock）导致Clone语义失效的案例。作者建议开发者在使用依赖库的默认重试机制时要保持警惕，并推荐在遇到不可思议的网路问题时使用抓包工具（Wireshark）直观地观察数据。

阅读：https://kobzol.github.io/rust/2025/12/30/investigating-and-fixing-a-nasty-clone-bug.html