甘肃省网站建设_网站建设公司_网站制作_seo优化

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）支持和进一步优化压缩算法的长期愿景。

如果你正在寻找一个：

1. 无需配置复杂 C++ 环境；

2. 支持原子多表写入；

3. 低延迟、高性能； 的 Rust 原生 KV 数据库，Fjall 3.0 是目前最值得关注的选择之一。

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

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

文章《Investigating and fixing a nasty clone bug》

作者： 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

WebFlappyBird：用 Rust WASM 构建的小游戏

网站：https://alejandrade.github.io/WebFlappyBird/

--

From 日报小组 苦瓜小仔

社区学习交流平台订阅：

• Rustcc论坛: 支持rss

• 微信公众号：Rust语言中文社区