Lavik容量与延迟，为什么同时成为问题？
受众画像、分组快照、创意元数据和活动变体随可触达用户与保留期增长，并不只取决于每秒展示数。小内存热集可能无法覆盖下一波身份请求或扩展后的活动受众。
截止时间不会等待：即使上下文查询最终成功，在决策之后到达也没有价值。只有当经验证的负载能按时提供足够有效响应时，SSD 容量才有意义。除了服务端 QPS，还要记录迟到响应与回退决策。
为这条数据路径而设计
Lavik 在架构中的位置
使用 Lavik 保存决策链路上的画像值、活动快照与信息补全记录。在十亿键 SPDK 基准中，320 个连接下 GET 为 652,881 QPS、p99.9 为 0.943 ms。可据此用实际扇出、记录大小与决策截止时间设计负载测试。
适用场景：高基数、可重建的信息补全值数据，且每请求延迟余量经过实测。
影响采用结果的设计决策
预算完整决策，而不只是一次 GET
从总截止时间中扣除网络、扇出、解码、模型/评分与下游耗时。在语义合适的情况下使用有界批次。负载测试前定义画像缺失或迟到的处理方式，不要让客户端重试掩盖截止时间违约。
区分值数据服务与高争用计数器
画像查询与逐事件预算/频次更新在争用和正确性方面有不同需求。为计数器使用幂等键并测试重试，在应用中明确跨键预算约束。
有计划地传播变更与删除
在应用发布程序中对受众和活动记录进行版本管理，限制数据陈旧时间，并测试所有服务副本的显式失效。缓存 TTL 是保留工具，本身并不能实现应用的同意、屏蔽或删除工作流。
试用这一命令模式
Redis 兼容命令先按快速入门启动 Lavik 0.2.0，再用这些示例键尝试场景中的基本操作。命令参考提供选项与返回值说明。
查看示例命令
redis-cli SET audience:v2:demo42 "{\"segments\":[\"outdoor\"],\"version\":2}" EX 120
redis-cli SET campaign:v4:demo7 "{\"creative\":\"banner7\",\"version\":4}" EX 120
redis-cli MGET audience:v2:demo42 campaign:v4:demo7
redis-cli DEL audience:v2:demo42
redis-cli MGET audience:v2:demo42 audience:v2:missing用什么标准决定迁移？
先写下业务预算，再做流量回放。以下标准需要通过你自己的系统验证；已发布基准是起点。
受截止时间约束的查询负载
使用控制请求到达率的发生器，采用真实扇出、值大小与冷键比例。
截止时间前的有效响应达到目标，队列与重试流量保持有界。
受众扩展与更替
发布程序更新记录时，增加键空间并切换活跃群体。
群体切换期间，决策 p99/p99.9、回退率与新鲜度保持可接受。
计数器与失效正确性
测试应用实际使用的更新脚本、重试、重复请求与删除传播。
业务不变量得到满足，不以画像读取基准成功替代验证。
在端到端决策截止时间内设置存储服务预算。跟踪迟到响应与回退，并为受众变化与活动上线预留容量。
从业务规模推导容量
值数据量 ≈ 保留身份数 × 画像字节数 + 活动/上下文快照