面试专题

Difficulty: Advanced
Status: Stable
Last reviewed: 2026年8月

Valkey 面试不要只回答“Redis 是单线程、Valkey 是多线程”。更准确的回答必须指出并行边界、队列拓扑、主线程数据所有权，以及 BIO 和 fork 的不同成本模型。

先给答案：Valkey 面试的主线是并行边界，而不是线程数量

先说明主线程仍是数据状态 owner，再按生产者和消费者数量解释 SPSC、SPMC、MPSC 队列为何各有用途，最后区分 IO worker、BIO 和 fork child 的生命周期与成本。这样才能回答“哪些工作并行、结果如何回到主线程、失败时积压在哪里”。

性能问题也要按边界定位：命令 CPU 高看主线程，响应不返回看 inbox/outbox 与 sleep hook，后台释放慢看 BIO，RSS 峰值看 fork COW。网络 IO 多线程并不承诺命令执行并行，也不消除单 owner 的延迟上限。

1. Valkey 的多线程做了什么

并行：accept / poll / socket read / socket write
串行：命令执行、数据结构 mutation、核心状态推进

源码证据：src/io_threads.c:285 是 worker 循环，读写分派在 :509、:550；主事件循环仍由 src/server.c:7890 的 aeMain 驱动。这样做保留了数据结构无需全局锁的优势，同时缓解网络 IO 成为瓶颈的问题。

2. 为什么混用 SPMC、SPSC、MPSC

回答顺序：先数清每条边的生产者和消费者，再选择最小同步协议。主线程到 worker 适合 SPMC；主线程到指定 worker 适合 SPSC；多个 worker 回报主线程适合 MPSC。统一 MPMC 会把不需要的竞争成本带进所有路径。

源码证据：初始化与队列编排在 src/io_threads.c:484，worker 消费在 :285，完成处理在 :895。

3. 主线程为什么仍然重要

主线程是数据状态 owner，不只是“调度线程”。它解析命令、推进事件状态并决定对象生命周期；IO worker 完成系统调用后仍要把结果交回主线程。若让 worker 直接修改共享 dict，就要引入锁、分片或事务协调，语义和复杂度都会变化。

4. BIO 和 IO worker 有什么区别

BIO 是后台任务执行器，典型任务是文件操作和 lazy free；IO worker 是网络 IO 执行器。BIO 的任务完成可以延后，IO worker 的结果则必须接回 client 读写生命周期。src/bio.c:179 是任务提交，:241 是执行；IO worker 逻辑位于 src/io_threads.c。

5. fork 为什么不能等同于异步线程

线程共享地址空间，fork child 以写时复制获得进程级隔离。fork 可把重写工作移出主线程，但父进程写热页时会产生 COW 内存成本。回答时应同时提吞吐收益、暂停时间和 RSS 峰值。

6. outbox 不 drain 如何排查

先看 worker 是否完成 socket 操作，再看完成任务是否进入 shared outbox，最后检查主线程在 sleep 前后是否 drain。src/io_threads.c:84 是 drain 关键位置，:116 和 :152 是 sleep 边界。现象通常是 CPU 不高、worker 看似正常，但响应延迟持续增长。

7. Valkey 与 Redis 如何谈兼容

分三层回答：RESP/命令协议、RDB/AOF/复制等数据语义、模块 ABI 和运维工具等工程生态。src/version.h 的 VALKEY_VERSION 与 REDIS_VERSION 7.2.4 说明产品身份和兼容基线被有意区分；兼容不是所有私有实现都永久不变。

8. tagged pointer 的风险

低位编码依赖指针对齐；必须保证分配器和 ABI 满足前提，读写通过统一掩码完成，并处理调试器、序列化和跨平台场景。源码坐标：src/io_threads.c:42、:46。

追问清单

网络 IO 已经多线程，为什么命令 CPU 仍可能成为瓶颈？
如果让每个 worker 绑定一组 client，如何处理 client 迁移和公平性？
outbox 的完成通知为什么不能直接在 worker 中执行命令回调？
BIO 队列积压和 fork COW 内存上涨分别如何监控？