Lavik容量与延迟，为什么同时成为问题？
日活用户数不能代表保留数据集。移动设备会重连，用户会保留多个会话，画像文档不断积累偏好和应用状态。延长保留期可能显著增加存储字节数，却不会同比增加峰值 QPS。
全内存容量使这些保留上下文成本高昂。使用磁盘存储方案时，重连风暴会让冷画像直接进入关键请求路径。相关指标是登录或恢复体验的尾部延迟，包括后端回退与重试。
为这条数据路径而设计
Lavik 在架构中的位置
将画像属性与应用会话上下文存入 Lavik，由身份服务继续负责认证与撤销。沿用现有键命名与 TTL 策略。画像大小、设备数量和保留历史越多，NVMe SSD 容量的价值就越明显。
适用场景：有相当规模的保留用户上下文值数据，且具备现有权威源与有界重建路径。
影响采用结果的设计决策
区分上下文与认证权威状态
确定哪些字段可以重建或返回旧值，哪些在不可用时必须拒绝请求。缺失缓存偏好可以回退到画像服务；缺失或过期的撤销记录必须遵循认证设计中明确的故障策略。
让过期与退出登录可验证
区分绝对到期与滑动空闲到期。测试刷新使用的准确 SET 选项、退出登录时的显式 DEL，以及多设备并发更新。存储级 TTL 本身不能实现完整会话生命周期。
避免将画像变成热点锁
限制记录大小与更新粒度，在键中区分租户和模式标识。避免大上下文更新与小型关键计数器争用同一个热点键。若数据集包含大量短生命周期小会话，应实际测量索引内存。
试用这一命令模式
Redis 兼容命令先按快速入门启动 Lavik 0.2.0，再用这些示例键尝试场景中的基本操作。命令参考提供选项与返回值说明。
查看示例命令
redis-cli SET context:tenant1:session42 "{\"user\":\"demo42\",\"theme\":\"dark\"}" EX 900
redis-cli GET context:tenant1:session42
redis-cli TTL context:tenant1:session42
redis-cli DEL context:tenant1:session42
redis-cli GET context:tenant1:session42用什么标准决定迁移？
先写下业务预算，再做流量回放。以下标准需要通过你自己的系统验证；已发布基准是起点。
集中恢复连接
回放空闲后、部署重启后及地域流量切换后的回访用户请求。
登录/恢复 p99 与超时率满足应用目标，且不会压垮权威服务。
过期与撤销竞争
使用真实会话库测试过期、刷新、退出与并发读取。
不会因过期或缺失状态而违背既定认证策略错误授权请求。
故障与重建
测试超时、连接丢失、重启与从权威数据源恢复。
在存储权威会话前，明确验收恢复流程以及拒绝/回退行为。
先迁移画像读取，再通过应用检查过期、登出与删除，覆盖客户端重试期间续期的会话。
从业务规模推导容量
值数据量 ≈ 保留会话数 × 上下文字节数 + 保留画像数 × 画像字节数