ClickHouse Silk：协作式纤程调度器的 NUMA 感知设计与 io_uring 集成

在高吞吐数据库系统中，并发模型的选择直接影响延迟分布与资源利用率。传统线程池模型在应对海量连接时面临上下文切换开销大、内存占用高的问题，而纯异步回调模式又导致代码复杂度攀升。ClickHouse 近期开源的 Silk 项目提供了一种中间路径 —— 基于用户态协作多任务的纤程（Fiber）调度器，通过每 CPU 调度线程配合 NUMA 感知的工作窃取策略，在 Linux 平台上实现了高性能的并发抽象。

每 CPU 调度模型：从线程到纤程的架构跃迁

Silk 的核心架构采用 "每 CPU 一个调度线程" 的设计。每个逻辑 CPU 运行独立的调度循环，拥有私有的 io_uring 实例（默认 128 个条目）、就绪队列、睡眠树以及跨 CPU 唤醒的事件通知机制。这种设计与传统线程池的本质区别在于：调度线程本身不执行用户代码，仅负责管理和分发纤程。

纤程作为轻量级有栈协程，每个实例拥有 64KB 的独立栈空间（通过 mmap 分配，两端设置 guard page），状态机涵盖 SUSPENDED、READY、RUNNING、STOPPED 四个阶段。上下文切换基于 Boost.Context 的 fcontext_t 实现，单次切换开销约 3.3 纳秒，而完整的调度 yield（包含队列操作和状态转换）约 40 纳秒。相比内核线程切换的数百纳秒甚至微秒级开销，纤程在用户态完成调度，避免了内核态陷入。

这种架构的收益在 I/O 密集型场景中尤为显著。以网络服务为例，Silk 的 TCP echo 基准测试显示，单条消息的端到端处理延迟约 23 微秒，其中 4 次 io_uring 操作（服务端读写 + 客户端读写）各贡献约 3.8 微秒，其余为内核 TCP 处理开销。

NUMA 感知的工作窃取：负载均衡的精细化策略

协作式调度面临的关键挑战是负载不均 —— 某些 CPU 纤程堆积而另一些空闲。Silk 通过 NUMA 感知的工作窃取机制解决这一问题，其设计体现了对现代硬件拓扑的深度理解。

在初始化阶段，Silk 读取 /sys/devices/system/cpu 下的拓扑信息，构建每个 CPU 的窃取候选列表，按估计成本排序：

• 超线程兄弟核：约 1 微秒成本，共享 L1/L2 缓存
• 同插槽核心：约 50 微秒成本，共享 L3 缓存
• 跨插槽访问：约 500 微秒成本，涉及 NUMA 远程内存访问

窃取操作分为两个层面：一是窃取其他 CPU 就绪队列中的纤程，二是 "认领" 其他 CPU 的服务循环（处理 io_uring 完成队列、睡眠超时等）。后者成本更低（约 2KB 数据量），因此优先级更高。窃取预算根据当前空闲时长动态计算，确保不会过度消耗在远程内存访问上。

这种分层策略在 32 核 Intel Xeon 上的基准测试中得到验证：当单纤程工作负载达到 350 微秒时，16 个并发纤程可实现约 11 倍的并行加速，接近线性扩展。

io_uring 与纤程的协同：异步 I/O 的无缝集成

Silk 的另一核心特性是与 Linux io_uring 的深度集成。每个调度线程拥有独立的 io_uring 实例，支持 read、write、poll 等操作的异步提交。纤程发起 I/O 请求后，调度器将 SQE（提交队列条目）送入 io_uring，随后纤程挂起；当 CQE（完成队列条目）到达时，调度器从用户数据中提取关联的 IoFuture 并唤醒对应纤程。

这种设计消除了传统异步 I/O 中的回调地狱，纤程代码可以写成同步风格：

// 伪代码示意
void fiber_handler() {
    auto result = async_read(fd, buffer);  // 挂起当前纤程
    // CQE 到达后自动恢复执行
    process(result);
}

对于需要执行阻塞系统调用或重 CPU 计算的场景，Silk 提供 Thread Mode 逃逸机制。纤程可临时切换到线程池模式，在独立的工作线程上执行阻塞操作，完成后自动回归协作调度。这一设计通过双队列系统实现：CPU 就绪队列用于正常纤程，共享就绪队列用于 Thread Mode 纤程及溢出任务。

同步原语与时间管理

Silk 实现了完整的纤程级同步原语体系，包括 FiberMutex、FiberFutex、FiberSequencer、FiberEvent 等。这些原语直接集成在调度器中，利用等待者表（waiter table）实现高效的纤程阻塞与唤醒。

时间管理采用 TSC（时间戳计数器）而非系统时钟，通过 rdtsc 指令读取，配合启动时检测的 CPU 频率进行纳秒级转换。转换使用定点乘移操作（cycles * nsPerCycleFp >> 20），热路径上避免了除法运算。睡眠取消通过原子状态位（IN_TABLE 和 CANCELLED）配合无锁栈实现，取消操作可在 O (log n) 时间内从睡眠树中移除条目。

性能考量与适用边界

从 Silk 的基准测试数据可以提炼出若干工程参数：

这些数据揭示了协作式调度的适用边界：当纤程工作负载较短（<1 微秒）时，调度开销占比显著；当工作负载达到数十微秒以上时，并行收益才能充分体现。此外，纤程栈的 64KB 空间在百万级并发场景下将消耗数十 GB 内存，需要根据实际连接数进行容量规划。

总结

Silk 代表了数据库系统向用户态调度演进的重要尝试。其每 CPU 调度模型配合 NUMA 感知的工作窃取，在保持代码可维护性的同时实现了接近裸机的性能。io_uring 的深度集成消除了异步 I/O 的复杂性，而 Thread Mode 机制则为混合工作负载提供了灵活性。

对于构建高并发服务的开发者而言，Silk 的设计提供了可落地的参考范式：通过纤程抽象隐藏并发复杂性，通过 NUMA 感知调度优化多核扩展性，通过用户态异步 I/O 降低系统调用开销。这些技术要素的组合，正是现代高性能数据库系统的关键支撑。

资料来源

• ClickHouse/silk — 项目仓库与构建文档
• Silk 调度器设计文档 — 调度循环、工作窃取、性能基准详细说明

systems