Lavik容量与延迟，为什么同时成为问题？
成熟缓存中昂贵的部分往往是长尾：商品变体、渲染片段、租户专属响应，以及读取不频繁但重建昂贵的对象。缩短 TTL 或加大淘汰力度能够释放内存，却会把压力转移回源站。
采用 SSD 的缓存只有在磁盘驻留数据的读取仍满足应用预算时，才真正解决问题。热缓存的平均值会掩盖广泛的键访问、缓存更替，以及超时带来的回源流量。应比较截止时间前返回的有效响应，而不仅是存下了多少数据。
为这条数据路径而设计
Lavik 在架构中的位置
将 Lavik 放在应用与源数据库或对象存储之间。沿用旁路缓存与失效处理模式，把保留值移到 NVMe SSD。更大的缓存为重建代价高的对象留出空间；通过命中率与回源流量衡量扩大覆盖范围的价值。
适用场景：可重建的大量值数据、昂贵的未命中路径，以及足以影响容量成本的保留规模。
影响采用结果的设计决策
明确缓存语义
在应用中定义旁路缓存读取、过期、失效处理和旧值策略。模式或渲染版本变化时使用带版本的键。合并并发未命中并限制回源重试，避免清空或集中到期放大故障。
为扇出与响应大小预留预算
一个页面需要多次串行查询时，每次查询可用的时间会减少。对照当前客户端行为验证有界 MGET 批次，包括缺失键处理。限制响应大小，并分别测量源站耗时与存储服务耗时。
同时规划键与值的容量
记录键数、平均键长、值大小分位数、TTL 分布、内存预留与 SSD 可用余量。小对象仍可能主要消耗索引和运行时内存；键数量增长并非没有成本。
试用这一命令模式
Redis 兼容命令先按快速入门启动 Lavik 0.2.0，再用这些示例键尝试场景中的基本操作。命令参考提供选项与返回值说明。
查看示例命令
redis-cli SET catalog:v3:sku42 "{\"name\":\"Trail shoe\",\"version\":3}" EX 300
redis-cli GET catalog:v3:sku42
redis-cli MGET catalog:v3:sku42 catalog:v3:missing
redis-cli DEL catalog:v3:sku42
redis-cli GET catalog:v3:sku42用什么标准决定迁移？
先写下业务预算，再做流量回放。以下标准需要通过你自己的系统验证；已发布基准是起点。
长尾读取
以计划保留的数据集大小回放同一键访问轨迹，包含低局部性和重启后的访问。
应用 p99/p99.9、超时率和回源 QPS 均满足既定预算。
集中到期与回填
测试真实 TTL 分布、失效突发与并发回填流量。
命中率恢复时不会使源站饱和，也不会耗尽客户端重试预算。
目标负载下的容量
增加保留对象时，同时测量常驻内存、设备占用、写入流量与成本。
在相同延迟目标、相同保留数据集下比较完整部署，并预留恢复余量。
先迁移一个缓存命名空间。在相同 TTL 下比较命中率、回源请求与应用 p99，再利用新增容量延长保留时间。
从业务规模推导容量
值数据量 ≈ 保留对象数 × 平均序列化字节数 × 同时保留的缓存版本数