容量与延迟，为什么同时成为问题？
日活用户数不能代表保留数据集。移动设备会重连，用户会保留多个会话，画像文档不断积累偏好和应用状态。延长保留期可能显著增加存储字节数，却不会同比增加峰值 QPS。
全内存容量使这些保留上下文成本高昂。使用磁盘存储方案时，重连风暴会让冷画像直接进入关键请求路径。相关指标是登录或恢复体验的尾部延迟，包括后端回退与重试。
为这条数据路径而设计
Lavik 在架构中的位置
Lavik 可用于评估较大且可重建的会话上下文与用户画像值。保留由应用管理的 TTL 和删除语义，并保留权威身份/画像系统。在值数据保留量主导账单的路径上利用 NVMe SSD 容量优势，再单独验证可用性与撤销行为。
优先评估：有相当规模的保留用户上下文值数据，且具备现有权威源与有界重建路径。
影响采用结果的设计决策
区分上下文与认证权威状态
确定哪些字段可以重建或返回旧值，哪些在不可用时必须拒绝请求。缺失缓存偏好可以回退到画像服务；缺失或过期的撤销记录必须遵循认证设计中明确的故障策略。
让过期与退出登录可验证
区分绝对到期与滑动空闲到期。测试刷新使用的准确 SET 选项、退出登录时的显式 DEL，以及多设备并发更新。存储级 TTL 本身不能实现完整会话生命周期。
避免将画像变成热点锁
限制记录大小与更新粒度，在键中区分租户和模式标识。避免大上下文更新与小型关键计数器争用同一个热点键。若数据集包含大量短生命周期小会话，应实际测量索引内存。
在 Lavik 上执行的命令示例
Docker 测试通过以下是使用示例数据、独立实例和真实回复的功能测试。它验证展示的命令序列，不是该行业工作负载的性能或端到端正确性测试。
查看实际请求与回复
> SET context:tenant1:session42 "{\"user\":\"demo42\",\"theme\":\"dark\"}" EX 900
"OK"
> GET context:tenant1:session42
"{\"user\":\"demo42\",\"theme\":\"dark\"}"
> TTL context:tenant1:session42
900
> DEL context:tenant1:session42
1
> GET context:tenant1:session42
null版本与验证范围
lavik 0.1.0-beta.1 · Minimal 发布包 · aarch64 · 2026-09-21
离线、只读容器根文件系统；临时数据目录，逐场景清空。示例使用已认证的本地连接。TTL 返回范围与具体参数保存在验证记录中。
执行记录 ↗用什么标准决定迁移？
先写下业务预算，再做流量回放。以下标准需要通过你自己的系统验证；已发布基准是起点。
集中恢复连接
回放空闲后、部署重启后及地域流量切换后的回访用户请求。
登录/恢复 p99 与超时率满足应用目标，且不会压垮权威服务。
过期与撤销竞争
使用真实会话库测试过期、刷新、退出与并发读取。
不会因过期或缺失状态而违背既定认证策略错误授权请求。
故障与重建
测试超时、连接丢失、重启与从权威数据源恢复。
在存储权威会话前，明确验收恢复流程以及拒绝/回退行为。
本地 TTL/删除示例不构成安全、复制或故障转移认证。值数据很少的小令牌，其容量节约可能远低于较大的画像记录。
从业务规模推导容量
值数据量 ≈ 保留会话数 × 上下文字节数 + 保留画像数 × 画像字节数
更低的值容量成本
当 DRAM 每 GiB 的价格是 NVMe SSD 的 20 倍，相同值数据的介质容量成本为 1/20，即降低 95%。索引内存、CPU、副本、存储放大与恢复余量仍需计入完整部署。
用你的容量价格计算 →