KiviDB：用 Rust 写的 Redis 替代品，多核并行，自带全文和向量检索
01它解决什么问题
Redis 执行命令基本靠一个线程，单机核心再多，也很难把 CPU 吃满，想扩容通常要上 Redis Cluster 拆分片。KiviDB 的做法是在一台机器内部就把数据按分片放到每个核心上，各核心并行处理命令，思路和 Dragonfly 相近。
它对外说的是 Redis 协议（RESP2 和 RESP3），所以对应用来说，连接地址换一下就行，代码不用改。支持哪些命令，以仓库里的 COMMANDS.md 为准，不是 Redis 的全部命令都一定覆盖。
02主要功能
- 键值存储：内存分片，支持快照和可选的 AOF 追加日志持久化；开启 AOF 后崩溃最多丢约 1 秒的写入。
- 检索：兼容 Redis Stack 的 FT.* 命令，可做全文检索（BM25）、标签和数值过滤，以及向量近邻搜索（FLAT 或 HNSW）。快照会把 HNSW 图一起存下，重启后不必重建索引。
- 其他：主从复制、集群模式、ACL 账号、TLS（需编译时开启）、Lua 脚本（需编译时开启）。
- Linux 上默认优先用 io_uring 处理网络 I/O，内核不支持时退回 Tokio。
03官方性能数据
以下是项目方 2026 年 10 月在 AWS Graviton3 裸金属机上测的结果：服务端限定 32 核，压测机为同机房另一台 c7gn.metal，1000 万个键、每个值 100 字节，各引擎依次单独运行。本站未复测。
| 每秒操作数 | KiviDB 1.1.0 | Dragonfly 2.0.2 | Redis 8.10 |
|---|---|---|---|
| GET，流水线 16 | 2120 万 | 910 万 | 240 万 |
| SET，流水线 16 | 1920 万 | 850 万 | 200 万 |
| GET，不用流水线 | 307 万 | 335 万 | 132 万 |
| 每个键占内存 | 177 字节 | 134 字节 | 178 字节 |
“流水线”指客户端一次连发多条命令再统一取结果，批量读写时常用。可以看到，KiviDB 的优势主要在流水线场景；不用流水线时略低于 Dragonfly，内存占用也比 Dragonfly 高。向量检索方面，在 glove-25 数据集上低召回率设置下每秒查询数领先，召回率调高（ef 256、512）后不如 Dragonfly，建索引耗时 31 秒，也慢于 Dragonfly 的 13 秒。官方自己也提醒：结果取决于环境，应在自己的硬件和负载上实测。
04上手
最快的方式是 Docker（以下命令来自官方 README，本站未实际运行）：
docker run -d -p 6380:6380 kividb/kividb redis-cli -p 6380 PING # 返回 PONG 即成功
注意它默认监听 6380 端口，而不是 Redis 的 6379，方便两者并存对比；需要时加 --port 6379。也可以从 GitHub Releases 下载 Linux（x86_64、aarch64）和 macOS 的二进制，或用 deb、rpm 包安装。
05许可证
KiviDB 采用 AGPL-3.0。官方说明：应用程序通过 Redis 客户端连接 KiviDB，不会因此受 AGPL 约束，闭源商用也可以；只有修改了 KiviDB 本身并通过网络对外提供服务时，才需要公开修改后的源码。公司另提供商业许可，贡献代码需签署 CLA。
06适合谁、要注意什么
适合已经在用 Redis、单机 CPU 吃不满、又不想马上上集群的团队，或者想在同一个服务里同时做缓存和向量检索的场景，可以先在测试环境压一压。
需要清醒看待的是：项目 10 月 16 日才在 GitHub 公开，核对时约 300 星、57 次提交，背后是一家新成立的公司（KIVIDB PRIVATE LIMITED），生产环境的使用案例还看不到。性能数据都来自项目方自测。生产环境替换 Redis 前，建议先对照 COMMANDS.md 确认自己用到的命令都支持，并用自己的数据做压测和故障演练。
DeepSeek
Claude Code
Timestral