容量与延迟，为什么同时成为问题？
同时在线玩家决定流量，而注册玩家、地域、游戏模式与保留赛季决定容量。将不活跃玩家从内存中移除能够降低成本，却会提高下次回归或活动触发重新活跃时的访问代价。
磁盘服务层需要在活跃会话持续运行时处理回归玩家。应一起测量画像加载突发、进度事件写入与排名读取；平滑平均流量低估了上线或赛季重置时的压力。
为这条数据路径而设计
Lavik 在架构中的位置
当保留值数据主导 Redis 容量时，可使用 Lavik 评估应用准备的玩家上下文与单独验证的排名状态。保留权威游戏状态或事件系统，以及回放/重建路径。低延迟模拟与关键账户余额应与读取模型评估分开。
优先评估：持续增长的保留玩家上下文，具备持久权威源与明确地域或赛季边界。
影响采用结果的设计决策
区分服务上下文与权威进度
缓存或物化画像时附带明确的源版本。除非已证明等价故障语义，权益、库存与余额不变量仍由权威工作流负责。读取模型重建不能重复发放奖励或重复应用事件。
有计划地划分玩家群体
当游戏、地域和赛季改变语义时，将其纳入键设计。限制画像/文档大小与排名窗口。分别测量小型热门群体和广泛回归玩家的读取；一个全局榜单可能与多个地域榜单表现完全不同。
设计回归与赛季切换路径
在重启或活动上线后的重建中实施限流。定义旧赛季保留、过期与回放顺序。应验证实际会话与有序集合命令序列，不要从 RESP 支持推断框架兼容性。
在 Lavik 上执行的命令示例
Docker 测试通过以下是使用示例数据、独立实例和真实回复的功能测试。它验证展示的命令序列，不是该行业工作负载的性能或端到端正确性测试。
查看实际请求与回复
> HSET profile:game1:eu:demo42 avatar ranger source_version 18 region eu
3
> HMGET profile:game1:eu:demo42 avatar source_version missing_field
["ranger","18",null]
> EXPIRE profile:game1:eu:demo42 1800
1
> DEL profile:game1:eu:demo42
1
> HMGET profile:game1:eu:demo42 avatar source_version
[null,null]版本与验证范围
lavik 0.1.0-beta.1 · Minimal 发布包 · aarch64 · 2026-09-21
离线、只读容器根文件系统；临时数据目录，逐场景清空。示例使用已认证的本地连接。TTL 返回范围与具体参数保存在验证记录中。
执行记录 ↗用什么标准决定迁移？
先写下业务预算，再做流量回放。以下标准需要通过你自己的系统验证；已发布基准是起点。
活动与重连突发
在持续进度写入与社交/画像读取同时回放回归玩家负载。
玩家可见尾延迟与超时率满足上线预算，且源站流量可控。
赛季转换
在新群体写入和旧数据到期时，保持历史赛季可访问。
赛季切换不超出内存/SSD 余量，且不会破坏当前赛季读写截止时间。
投影重建
注入重复和乱序事件，并在中断后重建服务状态。
画像与排名和权威状态一致，奖励与增量不会重复应用。
这些是建议的服务架构，不代表已验证游戏引擎、匹配系统、反作弊或商业客户。生产采用前，应验证集群、恢复与实际命令组合。
从业务规模推导容量
值数据量 ≈ 保留玩家数 × 上下文字节数 × 游戏/地域变体数；排名成员另行规划
更低的值容量成本
当 DRAM 每 GiB 的价格是 NVMe SSD 的 20 倍，相同值数据的介质容量成本为 1/20，即降低 95%。索引内存、CPU、副本、存储放大与恢复余量仍需计入完整部署。
用你的容量价格计算 →