容量与延迟，为什么同时成为问题？
一个前 100 名组件背后，可能保留着数百万成员与数千个并行榜单。即使展示窗口很小，在线保留历史赛季与地域分组也会使状态成倍增长。
将这些状态移到磁盘会改变成本结构，但点查询 QPS 无法充分说明排名更新、范围读取或高争用榜单的表现。必须在分数突发写入和保留清理期间测量尾延迟，而不只是测试空闲数据集。
为这条数据路径而设计
Lavik 在架构中的位置
Lavik 通过 Redis 协议提供经过示例测试的有序集合命令，并通过其存储引擎存储数据。初始评估可选择多个独立且规模适中的榜单。应测量完整内存占用；字符串值基准并不能说明每个有序集合成员的字节开销或排名更新吞吐量。
优先评估：持续增长的保留榜单集合，具备明确分组边界和可回放源事件。
影响采用结果的设计决策
按业务含义划分榜单
在排名契约允许的情况下，以赛季、游戏、地域或分组划分边界。单个热点有序集合键仍然存在争用；增加工作线程不会自动拆分一个榜单。跨多个榜单的全局排名需要应用逻辑实现。
定义分数与重试语义
在 ZADD 绝对分数与 ZINCRBY 增量更新之间做出选择。除非应用提供去重，重试一次增量操作可能导致重复加分。保持并列分数排序、排名方向以及离线玩家处理规则一致。
限制范围查询与保留清理工作量
分页读取有界排名窗口。决定赛季是整键到期，还是需要显式删除成员，并在写入同时测量清理开销。若排名状态需要重建，应保留可回放的得分源。
在 Lavik 上执行的命令示例
Docker 测试通过以下是使用示例数据、独立实例和真实回复的功能测试。它验证展示的命令序列，不是该行业工作负载的性能或端到端正确性测试。
查看实际请求与回复
> ZADD board:season7:eu 100 alice 120 bob 90 carol
3
> ZINCRBY board:season7:eu 30 alice
"130"
> ZREVRANGE board:season7:eu 0 1 WITHSCORES
["alice","130","bob","120"]
> ZREVRANK board:season7:eu alice
0
> EXPIRE board:season7:eu 3600
1版本与验证范围
lavik 0.1.0-beta.1 · Minimal 发布包 · aarch64 · 2026-09-21
离线、只读容器根文件系统；临时数据目录，逐场景清空。示例使用已认证的本地连接。TTL 返回范围与具体参数保存在验证记录中。
执行记录 ↗用什么标准决定迁移？
先写下业务预算，再做流量回放。以下标准需要通过你自己的系统验证；已发布基准是起点。
热点榜单的分数突发
采用真实榜单规模分布与直播活动期间的更新集中度。
分数更新与 top-N 查询的 p99/p99.9 满足产品截止时间，客户端队列保持有界。
排名与回放正确性
对比并列分数、排名方向、分页、重复事件与重启重建。
排名符合现有契约，回放不会重复应用分数变化。
赛季切换
保留旧榜单的同时创建新分组，并对旧状态执行过期或裁剪。
可用容量与内存保持在预算内，同时不破坏在线榜单延迟。
已验证示例只证明一个小型命令序列，并不证明百万成员性能、赛事正确性或队列/框架兼容性。应根据实测计算有序集合容量，而不是直接套用 1 KiB 字符串基准。
从业务规模推导容量
保留成员数 ≈ 每榜成员数 × 分组数 × 赛季数；每成员字节数需实测
更低的值容量成本
当 DRAM 每 GiB 的价格是 NVMe SSD 的 20 倍，相同值数据的介质容量成本为 1/20，即降低 95%。索引内存、CPU、副本、存储放大与恢复余量仍需计入完整部署。
用你的容量价格计算 →