在如今这个云原生满天飞、数据库多如牛毛的时代，可能很多人会问：为什么还要费劲巴力地去手写一个 KV 存储引擎？市面上不是已经有 Redis、Etcd、TiKV 甚至 RocksDB 了吗？
这是一个好问题，但也是一个让无数技术人止步于“调用 API”层面的借口。
大家都能把 Raft 协议背得滚瓜烂熟，能把 LSM-Tree 的写放大聊得头头是道，但真让他去处理一个 Log Replication 在网络分区下的边界情况，或者去调试一个 Compaction 导致的 CPU 抖动时，很多人就懵了。因为“知道原理”和“写出生产级代码”之间，隔着一万个工程细节的坑。
这也是我发起 NoKV (github.com/feichai0017…) 这个项目的初衷。
NoKV 不是为了去重复造一个轮子，而是为了造一个能让你看懂、能拆解、能魔改的“精密引擎”。
它是一个纯 Go 原生的分布式存储引擎，但在设计上，我并没有“安分守己”。我尝试把 RocksDB 那种严谨的 Manifest 显式约束 与 Badger 高效的键值分离（Key-Value Separation） 思想融合在一起。如果你读过 Badger 的论文，你会知道对于大 Value 场景，把 Value 扔到 Value Log 里，LSM 树只存偏移量，能带来多么恐怖的写性能提升。NoKV 就想在这个方向上做得更彻底一点。
更硬核的是，NoKV 不仅仅是一个单机引擎。通过一个简单的拓扑配置文件，你可以把它变成一个嵌入式的本地库，也可以瞬间启动一个基于 Multi-Raft 驱动的分布式集群。这意味着你可以在代码里亲眼看到：数据是如何被切分成不同的 Region，Raft Group 是如何在节点间选举和复制日志，以及当一个节点宕机时，集群是如何自我愈合的。为了方便调试和接入，我甚至还给它套了一层 Redis 协议网关，让你用 redis-cli 就能直接跟底层的 Raft 状态机对话。
但是，一个人的精力终究是有限的。
目前的 NoKV 已经搭建好了核心骨架：LSM 的写入流程、WAL 的持久化、基础的 Raft 同步都已经跑通了。但要让它真正成为一个能在工业界“秀肌肉”的项目，或者成为一个完美的分布式系统教学靶场，还有很长的路要走。
所以我现在想寻找一些“同好”，一些长期的合作伙伴。
不需要你一定是 P7、P8 的架构师，也不需要你对 Go 语言精通到能背诵 GC 源码。更加注重的是你对“底层技术”的渴望。
如果你厌倦了整天写 CRUD 的业务代码，如果你想搞懂为什么 fsync 会阻塞主线程，如果你想亲手实现一遍布隆过滤器的优化，或者想挑战一下在分布式环境下如何做线性一致性读（Linearizable Read），那么 NoKV 就是你最好的练兵场。
在这个项目里，我们没有 KPI 的压力，没有上线的时间表。我们可以为一个锁的粒度争论一晚上，也可以为了优化 5% 的 QPS 去重写整个内存分配器。
未来我们想做的事情还有很多： 比如引入更智能的 Compaction 策略以适应不同的读写负载； 比如支持更复杂的分布式事务模型（Percolator 或者两阶段提交）； 甚至激进一点，尝试在 Go 语言里引入 io_uring 来突破内核态切换的瓶颈。
我希望 NoKV 能成为这样一个社区：大家聚在一起，不是为了拼凑代码，而是为了通过代码去验证那些经典的分布式理论，去感受掌控每一个比特流动的快感。
如果你对这些感兴趣，别犹豫了。去 GitHub 上 Clone 下来跑一跑，看看源码，哪怕只是提一个关于代码风格的 Issue，或者在 Discussion 里聊聊你对 LSM 树的理解，都是我们故事的开始。
咱们在代码里见。
