Lavik容量与延迟，为什么同时成为问题？
一个前 100 名组件背后，可能保留着数百万成员与数千个并行榜单。即使展示窗口很小，在线保留历史赛季与地域分组也会使状态成倍增长。
将这些状态移到磁盘会改变成本结构，但点查询 QPS 无法充分说明排名更新、范围读取或高争用榜单的表现。必须在分数突发写入和保留清理期间测量尾延迟，而不只是测试空闲数据集。
为这条数据路径而设计
Lavik 在架构中的位置
使用 ZADD、ZINCRBY 与排名、范围读取，沿用 Redis 应用的榜单模式。Lavik 0.2.0 将大型集合分组，使操作可以处理存储对象的相关部分。按成员数、榜单数与保留赛季规划容量，并用实际榜单大小测量排名更新与范围读取。
适用场景：持续增长的保留榜单集合，具备明确分组边界和可回放源事件。
影响采用结果的设计决策
按业务含义划分榜单
在排名契约允许的情况下，以赛季、游戏、地域或分组划分边界。单个热点有序集合键仍然存在争用；增加工作线程不会自动拆分一个榜单。跨多个榜单的全局排名需要应用逻辑实现。
定义分数与重试语义
在 ZADD 绝对分数与 ZINCRBY 增量更新之间做出选择。除非应用提供去重，重试一次增量操作可能导致重复加分。保持并列分数排序、排名方向以及离线玩家处理规则一致。
限制范围查询与保留清理工作量
分页读取有界排名窗口。决定赛季是整键到期，还是需要显式删除成员，并在写入同时测量清理开销。若排名状态需要重建，应保留可回放的得分源。
试用这一命令模式
Redis 兼容命令先按快速入门启动 Lavik 0.2.0，再用这些示例键尝试场景中的基本操作。命令参考提供选项与返回值说明。
查看示例命令
redis-cli ZADD board:season7:eu 100 alice 120 bob 90 carol
redis-cli ZINCRBY board:season7:eu 30 alice
redis-cli ZREVRANGE board:season7:eu 0 1 WITHSCORES
redis-cli ZREVRANK board:season7:eu alice
redis-cli EXPIRE board:season7:eu 3600用什么标准决定迁移？
先写下业务预算，再做流量回放。以下标准需要通过你自己的系统验证；已发布基准是起点。
热点榜单的分数突发
采用真实榜单规模分布与直播活动期间的更新集中度。
分数更新与 top-N 查询的 p99/p99.9 满足产品截止时间，客户端队列保持有界。
排名与回放正确性
对比并列分数、排名方向、分页、重复事件与重启重建。
排名符合现有契约，回放不会重复应用分数变化。
赛季切换
保留旧榜单的同时创建新分组，并对旧状态执行过期或裁剪。
可用容量与内存保持在预算内，同时不破坏在线榜单延迟。
使用实际成员数量与分数更新分布测试有序集合操作。GET/SET 报告说明存储基础，榜单容量应按 ZSET 流量规划。
从业务规模推导容量
保留成员数 ≈ 每榜成员数 × 分组数 × 赛季数；每成员字节数需实测