评估 Lavik Beta：SPDK 吞吐、尾延迟与容量成本

当键值数据增长、DRAM 预算受限时，你需要判断：能否把容量压力转向 NVMe，同时满足自己的尾延迟、恢复和成本要求？评估 Lavik，应把性能实测、功能验证与容量价格假设分开看。

Lavik 在 DRAM 中保留紧凑的键索引，将值存储在文件、裸块设备或 SPDK NVMe 命名空间中。

2026 年 9 月 18 日的 SPDK 报告测试了下载的 v0.1.0-beta.1 标准 x86_64 包：源码提交 3955b98，GCC/x86-64-v2 构建，未经重编译。它仍是 Beta 预发布版。本文聚焦千万键组，不混用 9 月 6 日的 io_uring 结果。

峰值结果：先对齐测试条件

服务器为 AMD EPYC 9V74，8 个物理核、16 个逻辑 CPU、约 126 GiB RAM；独立客户端为 EPYC 9V45，两端均绑定 CPU 0–15。Lavik 使用 16 个 worker、内核 TCP 和六块专用 NVMe 上的 SPDK，碎片整理开启，Tomb Raider 关闭；数据从空盘加载，未复用 io_uring 数据或检查点。

负载为 1,000 万键、每值 1 KiB，均匀随机 GET 或覆盖式 SET。memtier 2.5.1 使用 16 线程、pipeline=1、不限速，扫描 80/160/320/640/1,280 个连接；配置先进行 10 秒 GET 预热，每个测量点仅运行一次、持续 30 秒，客户端保留默认相关随机种子。Redis 和 Valkey 的数据全在内存，AOF 与自动 RDB 快照均关闭。

对照不是同期重测：全报告新增 22 个 Lavik SPDK 点，复用同主机较早扫描的 124 个其他产品对照点。产品顺序执行而非交错运行，时间变化也可能影响结果。以下保留 CSV 的 QPS 精度，p99 对应各自吞吐峰值点。

GET：Lavik SPDK 为 1,012,179.91 QPS，p99 3.599 ms，640 连接；Redis 8.8.0 为 976,800.89 QPS，p99 4.671 ms，1,280 连接；Valkey 9.1.0 为 965,696.86 QPS，p99 4.543 ms，1,280 连接。两种对照均选择 16 个 I/O 线程；I/O 线程与 Lavik worker 的职责不同。

SET：三者峰值均在 1,280 连接。Lavik SPDK 为 930,464.99 QPS，p99 4.799 ms；Redis 为 910,426.33 QPS，p99 4.831 ms，16 个 I/O 线程；Valkey 为 802,519.39 QPS，p99 4.383 ms，8 个 I/O 线程。对照配置从 1/2/4/8/16 个 I/O 线程中按命令选择。

这组峰值中 Lavik 吞吐领先，但不代表尾延迟全面更低：SET 峰值 p99 高于 Valkey；GET 增至 1,280 连接后，Lavik 降到 940,713.30 QPS，p99 升至 9.791 ms。评估时应看延迟预算内的吞吐，而不只看最大连接数或峰值排名。这些短窗口测试也不能证明相同的崩溃持久性或应用 SLA。

先验证功能，不把冒烟测试当压测

set -euo pipefail
mkdir -p /tmp/lavik-example
fallocate -l 512M /tmp/lavik-example/data
exec lavik --bind 127.0.0.1 --port 6379 --metrics-port 0 \
  --threads 2 --no-pin-workers --registered-buffer-mb-per-worker 64 \
  --shutdown-checkpoint --data-file /tmp/lavik-example/data \
  --log-dir /tmp/lavik-example/logs

$ redis-cli --raw PING
PONG

$ redis-cli --raw SET greeting 'hello from Lavik'
OK

$ redis-cli --raw GET greeting
hello from Lavik

$ redis-cli --raw HSET user:42 name Ada
1

$ redis-cli --raw HGET user:42 name
Ada

{
  "recipeId": "basic-commands",
  "platform": "Linux-6.17.0-1022-azure-x86_64-with-glibc2.39",
  "steps": [
    {
      "argv": [
        "redis-cli",
        "--raw",
        "PING"
      ],
      "expected": "PONG",
      "actual": "PONG"
    },
    {
      "argv": [
        "redis-cli",
        "--raw",
        "SET",
        "greeting",
        "hello from Lavik"
      ],
      "expected": "OK",
      "actual": "OK"
    },
    {
      "argv": [
        "redis-cli",
        "--raw",
        "GET",
        "greeting"
      ],
      "expected": "hello from Lavik",
      "actual": "hello from Lavik"
    },
    {
      "argv": [
        "redis-cli",
        "--raw",
        "HSET",
        "user:42",
        "name",
        "Ada"
      ],
      "expected": "1",
      "actual": "1"
    },
    {
      "argv": [
        "redis-cli",
        "--raw",
        "HGET",
        "user:42",
        "name"
      ],
      "expected": "Ada",
      "actual": "Ada"
    }
  ],
  "status": "passed",
  "binaryVersion": "lavik 0.1.0-beta.1",
  "sourceCommit": "3955b98d43b312324aa8d52775df52cfb111c0d0",
  "packageVersion": "v0.1.0-beta.1",
  "gracefulRestart": "passed"
}

上方示例在 2026 年 9 月 20 日的实际执行记录来自同版本的 Linux x86_64 minimal 二进制，平台为 Linux 6.17.0-1022-azure、glibc 2.39。PING、SET、GET、HSET、HGET 依次返回 PONG、OK、hello from Lavik、1、Ada，正常停机后的重启检查也通过。minimal 使用内核 TCP/io_uring，不含 SPDK；这验证的是该 x86_64 环境下的示例功能，不是 ARM64 执行证据，也不是上述 SPDK 性能、断电恢复能力或 SLA 的验证。

写入成功的响应并不代表同步 fsync 已完成。请按实际工作负载评估持久性、复制和恢复要求。

20:1 单价假设，为什么不是整机省 95%

以下是计算器假设，不是硬件报价或实测内存比例。按同一币种、同一计费周期，将 SSD 与 DRAM 单价归一化为每 GiB 1 和 20 个成本单位：仅替换值数据的容量介质，这一组件成本降低 95%。默认另计有效数据容量 2% 的索引 RAM，以及双方相同的其他成本——金额为 Redis 值数据内存成本的 10%；假设副本数相同、不压缩、存储放大为 1。

以 1 GiB 数据计算，共同成本为 2：Redis 模型成本为 20+2=22，Lavik 为 1+0.02×20+2=3.4。因此 Redis/Lavik 成本比为 6.47:1，模型中 Lavik 低 84.5%，而非 95%。索引和共同开销越大，百分比收益越小。实际 SPDK 测试另有 8 GiB 大页预留，不能用 2% 索引假设代替总内存测量；性能要求还可能改变服务器数量。这不是延迟、持久性或可用性预测。

历史实例估算也要区分服务边界：2026 年 8 月 12 日更新的报告记录了用户提供的估算，Azure Managed Redis Flex 480 GB/16 vCPU 每月 2,414.28 美元，Lavik 的 Standard_L16s_v3 服务器 VM 每月 1,152.67 美元。两者均不含压测客户端；托管服务与自管 VM 的责任不同，这既不是当前报价，也不是完整总拥有成本。

实际选型：按目标负载和总成本验收

先验证应用关键命令，再用真实值大小、热点分布和读写混合比例做长时间并发扫描，观察后台回收、RSS 与尾延迟。单独验证恢复和复制要求，最后把实际内存、存储余量、CPU、网络及运维费用代入预算。短窗口峰值说明值得继续测试；是否适合你的 SLA、是否真正省钱，仍取决于这些验收结果。