立项原因： 业务热点数据读取激增，关系型数据库 I/O 瓶颈显著，现有缓存层在容量成本、恢复速度上难以兼顾，需要一款可内嵌、高吞吐、低写放大、可崩溃恢复的轻量级 KV 存储引擎，同时沉淀可复用的线程池与网络协议组件。
行业场景： 电商短链投放平台。大促期间商品短链 302 重定向 QPS 破百万，埋点日志需高吞吐顺序写入，营销元数据需毫秒级读取。本项目用自研 Bitcask 引擎 + 可插拔线程池 + 自定义 TCP 协议，在 4 核机器上实现读 ~1 MiB/s、写 ~696 KiB/s，自研线程池与工业级 Rayon 吞吐打平，支撑低资源环境下的高 SLA。
功能模块：
Bitcask 存储引擎（KvStore + Sled 适配层）
可插拔线程池（Naive / SharedQueue / Rayon 三种）
TCP 网络协议栈（自定义线协议 + Serde Visitor）
服务端（TCP Listener、请求分发、优雅停机）
客户端（无锁连接池、Builder 配置、请求响应通道）
CLI 命令行（kvs-server / kvs-client）
工程化（CI 流水线、集成测试、Criterion 基准）
主要功能描述：
提供 set/get/rm 基础 KV 操作，段文件追加写入 + 1 MiB 自动轮转，后台线程在 stale 条目达阈值时触发 compaction，原子切换索引。
崩溃后按序回放段文件重建内存索引，保证数据一致性；懒刷盘机制降低突发写入的 syscall 开销。
三种线程池共享 spawn 接口，共享队列池内置 catch_unwind 防止单任务 panic 导致整体饥饿。
自定义 2 字节 opcode 行帧协议，零拷贝解析；服务端对 TCP 流 try_clone 实现读写分离，支持 2 包优雅停机。
客户端采用 fetch_add 无锁轮询的长连接池，可选 crossbeam 响应通道与 AtomicU64 完成计数编排批量压测。
CLI 支持 --engine kvs|sled 切换引擎、--addr 指定地址；GitHub Actions 自动跑 fmt、clippy、test，并有 Criterion 基准对比自研引擎与 Sled、自研线程池与 Rayon。
负责任务： 本人独立负责整体方案设计与全流程落地：① Bitcask 存储引擎（追加式段日志、段轮转、后台 compaction、崩溃回放）；② 可插拔线程池的 trait 抽象与实现；③ 自定义行帧 TCP 线协议及 Serde Visitor 编解码；④ 服务端请求分发、原子停机协议、客户端无锁长连接池；⑤ Criterion 基准与集成测试。
技术栈与架构： Rust、clap、serde、thiserror、crossbeam-channel、rayon、sled、log/stderrlog、criterion。分层架构：存储层（KvsEngine trait）、并发层（ThreadPool trait）、网络层（protocol 编解码）、应用层（kvs-server / kvs-client CLI）。
实现亮点： 1）读写职责分离：只读句柄池、写头独占、内存索引三把细粒度锁拆分。 2）后台压缩线下构造新索引与临时文件，避免长时间阻塞线上读。 3）自研共享队列线程池在每个任务做 panic 兜底；基准下与工业级 Rayon 吞吐统计性打平。 4）所有共享原子推导最弱内存序，客户端长连接按条独立锁拆分读写两半。
难点与解决： 1）读写锁未分离拖慢并发：读写共享大锁，写长占，读饥饿。拆成三把细粒度锁（句柄/写头/索引），读并发显著提升。2）1000 个 TCP 连接瓶颈：短连接高频建立/关闭，TIME_WAIT 堆积等。改为客户端预建长连接池 + 无锁轮询均衡。3）长连接导致 accept 阻塞：只靠已有长连接发停机，无法唤醒监听侧阻塞等待。采用两包停机：长连接置停机 + 新建一条连接强制唤醒 accept。4）多文件 Cursor Seek 造成覆盖写：共享同一文件句柄并发 seek，偏移错乱。读侧按偏移直接定位读，全程不依赖共享 Cursor。
评论