容量与延迟，为什么同时成为问题？
受众画像、分组快照、创意元数据和活动变体随可触达用户与保留期增长，并不只取决于每秒展示数。小内存热集可能无法覆盖下一波身份请求或扩展后的活动受众。
截止时间不会等待：即使上下文查询最终成功，在决策之后到达也没有价值。只有当经验证的负载能按时提供足够有效响应时，SSD 容量才有意义。除了服务端 QPS，还要记录迟到响应与回退决策。
为这条数据路径而设计
Lavik 在架构中的位置
对于通过已知 Redis 命令访问且容量较大的画像与活动读取模型，可评估 Lavik。其已发布的十亿键随机读取扫描为受延迟约束的测试提供了具体起点。明确每条服务链路的截止时间，选择具有余量的较低负载运行点，而不是把峰值吞吐量当作 SLO。
优先评估：高基数、可重建的信息补全值数据，且每请求延迟余量经过实测。
影响采用结果的设计决策
预算完整决策，而不只是一次 GET
从总截止时间中扣除网络、扇出、解码、模型/评分与下游耗时。在语义合适的情况下使用有界批次。负载测试前定义画像缺失或迟到的处理方式，不要让客户端重试掩盖截止时间违约。
区分值数据服务与高争用计数器
画像查询与逐事件预算/频次更新在争用和正确性方面有不同需求。GET/SET 基准不能证明恰好一次增量、跨键预算约束或拍卖框架兼容性。应分别验证这些路径。
有计划地传播变更与删除
在应用发布程序中对受众和活动记录进行版本管理，限制数据陈旧时间，并测试所有服务副本的显式失效。缓存 TTL 是保留工具，本身并不能实现应用的同意、屏蔽或删除工作流。
在 Lavik 上执行的命令示例
Docker 测试通过以下是使用示例数据、独立实例和真实回复的功能测试。它验证展示的命令序列，不是该行业工作负载的性能或端到端正确性测试。
查看实际请求与回复
> SET audience:v2:demo42 "{\"segments\":[\"outdoor\"],\"version\":2}" EX 120
"OK"
> SET campaign:v4:demo7 "{\"creative\":\"banner7\",\"version\":4}" EX 120
"OK"
> MGET audience:v2:demo42 campaign:v4:demo7
["{\"segments\":[\"outdoor\"],\"version\":2}","{\"creative\":\"banner7\",\"version\":4}"]
> DEL audience:v2:demo42
1
> MGET audience:v2:demo42 audience:v2:missing
[null,null]版本与验证范围
lavik 0.1.0-beta.1 · Minimal 发布包 · aarch64 · 2026-09-21
离线、只读容器根文件系统；临时数据目录，逐场景清空。示例使用已认证的本地连接。TTL 返回范围与具体参数保存在验证记录中。
执行记录 ↗用什么标准决定迁移？
先写下业务预算，再做流量回放。以下标准需要通过你自己的系统验证；已发布基准是起点。
受截止时间约束的查询负载
使用控制请求到达率的发生器，采用真实扇出、值大小与冷键比例。
截止时间前的有效响应达到目标，队列与重试流量保持有界。
受众扩展与更替
发布程序更新记录时，增加键空间并切换活跃群体。
群体切换期间，决策 p99/p99.9、回退率与新鲜度保持可接受。
计数器与失效正确性
测试应用实际使用的更新脚本、重试、重复请求与删除传播。
业务不变量得到满足，不以画像读取基准成功替代验证。
峰值基准不能证明严格的微秒级或端到端亚毫秒截止时间。应使用完整连接数扫描并测试实际到达过程；如果无法满足截止时间预算，应拒绝该迁移方案。
从业务规模推导容量
值数据量 ≈ 保留身份数 × 画像字节数 + 活动/上下文快照
更低的值容量成本
当 DRAM 每 GiB 的价格是 NVMe SSD 的 20 倍，相同值数据的介质容量成本为 1/20，即降低 95%。索引内存、CPU、副本、存储放大与恢复余量仍需计入完整部署。
用你的容量价格计算 →