Rust中处理部分借用的最佳实践困境

核心问题

开发者在使用Rust时遇到一个持续性的难题：当结构体包含多个相关数据字段时，由于借用检查器不能理解跨函数边界的部分借用，导致常见的代码模式无法通过编译。

具体案例

struct Data {
    stuff: Vec<u32>,
    queue: Vec<u32>,
}

在 process_all 方法中，当试图遍历 self.stuff 的同时调用修改 self.queue 的 process 方法时，编译器报错：无法借用 self，因为 self.stuff 已被借用。

开发者的困惑

• 是否应该放弃使用结构体，改为分别传递各个成员？
• 是否需要根据具体情况手动拆分结构体成员？
• 如何有效地处理这个问题？

这位有2年以上Rust开发经验的程序员表示：

• 这个问题严重影响开发体验，甚至考虑放弃使用Rust
• 感到非常沮丧，因为结构体本应是基础的抽象单元和数据分组方式
• 只想"把事情做完"，但似乎必须在性能和代码组织之间做出妥协（如使用中间Vec来传递值或按需拆分数据）

https://old.reddit.com/r/rust/comments/1rg3ftw/whats_the_most_idiomatic_way_to_deal_with_partial/

Apache Iggy 迁移到基于 io_uring 的线程核心架构

背景

Apache Iggy 以性能为核心原则，在原有架构达到硬件极限后，需要寻求新的方法来突破性能瓶颈。

迁移原因

• 原架构问题：Apache Iggy 使用 tokio 作为异步运行时，采用多线程工作窃取执行器

  • 缺乏精细控制
  • 任务在工作线程间迁移导致缓存失效
  • 执行路径不可预测

• 关键痛点：tokio 处理块设备 I/O 的方式

  • 基于通知机制（epoll）不适合块设备
  • Linux 内核将常规文件视为始终"就绪"，导致 I/O 操作仍会阻塞线程
  • 依赖线程池（默认最多 512 个线程）处理阻塞 I/O
  • 高性能系统会快速耗尽线程池能力

新架构：线程每核心无共享架构

核心理念：

• 将单个线程固定到每个 CPU 核心
• 基于启发式方法（通常是哈希）对资源进行分区
• 消除共享状态，减少锁竞争
• 提高缓存局部性
• 使用消息传递在线程（分片）之间通信

关键改进：

• 从"工作窃取"转向"工作引导"
• 采用 io_uring 实现真正的异步 I/O

io_uring 的优势

• 基于完成而非就绪通知：提交操作后由内核驱动至完成
• 核心机制：用户空间和内核之间共享两个无锁环形缓冲区
  • 提交队列（SQ）：应用程序排队 I/O 请求
  • 完成队列（CQ）：内核放置操作结果
• 虽然与 Rust Future 的轮询模型不完全兼容，但性能开销可忽略不计

https://iggy.apache.org/blogs/2026/02/27/thread-per-core-io_uring/

--

From 日报小组 Mike

社区学习交流平台订阅：

• Rustcc论坛: 支持rss
• 微信公众号：Rust语言中文社区