容量与延迟，为什么同时成为问题？
成熟缓存中昂贵的部分往往是长尾：商品变体、渲染片段、租户专属响应，以及读取不频繁但重建昂贵的对象。缩短 TTL 或加大淘汰力度能够释放内存，却会把压力转移回源站。
采用 SSD 的缓存只有在磁盘驻留数据的读取仍满足应用预算时，才真正解决问题。热缓存的平均值会掩盖广泛的键访问、缓存更替，以及超时带来的回源流量。应比较截止时间前返回的有效响应，而不仅是存下了多少数据。
为这条数据路径而设计
Lavik 在架构中的位置
Lavik 将键索引保留在 DRAM 中，使用 NVMe SSD 存储值。这改变了保留更大缓存的容量成本，同时保留 Redis 兼容请求接口。优先从可重建的缓存对象开始，保留源数据系统，并测量增加保留量对命中率和源站负载的影响。
优先评估：可重建的大量值数据、昂贵的未命中路径，以及足以影响容量成本的保留规模。
影响采用结果的设计决策
明确缓存语义
在应用中定义旁路缓存读取、过期、失效处理和旧值策略。模式或渲染版本变化时使用带版本的键。合并并发未命中并限制回源重试，避免清空或集中到期放大故障。
为扇出与响应大小预留预算
一个页面需要多次串行查询时，每次查询可用的时间会减少。对照当前客户端行为验证有界 MGET 批次，包括缺失键处理。限制响应大小，并分别测量源站耗时与存储服务耗时。
同时规划键与值的容量
记录键数、平均键长、值大小分位数、TTL 分布、内存预留与 SSD 可用余量。小对象仍可能主要消耗索引和运行时内存；键数量增长并非没有成本。
在 Lavik 上执行的命令示例
Docker 测试通过以下是使用示例数据、独立实例和真实回复的功能测试。它验证展示的命令序列，不是该行业工作负载的性能或端到端正确性测试。
查看实际请求与回复
> SET catalog:v3:sku42 "{\"name\":\"Trail shoe\",\"version\":3}" EX 300
"OK"
> GET catalog:v3:sku42
"{\"name\":\"Trail shoe\",\"version\":3}"
> MGET catalog:v3:sku42 catalog:v3:missing
["{\"name\":\"Trail shoe\",\"version\":3}",null]
> DEL catalog:v3:sku42
1
> GET catalog:v3:sku42
null版本与验证范围
lavik 0.1.0-beta.1 · Minimal 发布包 · aarch64 · 2026-09-21
离线、只读容器根文件系统；临时数据目录，逐场景清空。示例使用已认证的本地连接。TTL 返回范围与具体参数保存在验证记录中。
执行记录 ↗用什么标准决定迁移？
先写下业务预算，再做流量回放。以下标准需要通过你自己的系统验证；已发布基准是起点。
长尾读取
以计划保留的数据集大小回放同一键访问轨迹，包含低局部性和重启后的访问。
应用 p99/p99.9、超时率和回源 QPS 均满足既定预算。
集中到期与回填
测试真实 TTL 分布、失效突发与并发回填流量。
命中率恢复时不会使源站饱和，也不会耗尽客户端重试预算。
目标负载下的容量
增加保留对象时，同时测量常驻内存、设备占用、写入流量与成本。
在相同延迟目标、相同保留数据集下比较完整部署，并预留恢复余量。
Lavik 0.1.0 是 beta 版本。已发布的 GET/SET 测试不能证明你的命中率、淘汰策略、多地域可用性或应用 SLA。调整生产缓存前，应验证准确的客户端与故障行为。
从业务规模推导容量
值数据量 ≈ 保留对象数 × 平均序列化字节数 × 同时保留的缓存版本数
更低的值容量成本
当 DRAM 每 GiB 的价格是 NVMe SSD 的 20 倍，相同值数据的介质容量成本为 1/20，即降低 95%。索引内存、CPU、副本、存储放大与恢复余量仍需计入完整部署。
用你的容量价格计算 →