ZSet同分时排序不可控是因为其严格按member字典序升序排列，而非插入或时间顺序；例如分数相同时，"user10"会排在"user2"前，因字符串比较中'1'<'2'，导致业务预期的“先到先得”无法满足。
为什么ZSet同分时排序不可控？
ZSet在score相同时，**严格按member字典序升序排列**（不是插入顺序，也不是时间顺序）。比如插入"user2"和"user10"且分数相同，结果一定是"user10"排在"user2"前面——因为字符串"user10" 。这不是 bug，是 Redis 明确定义的行为。
用整数拼接构造复合 score（推荐）
避免浮点精度陷阱和语义反转，直接用整数运算拼接原始分与归一化时间戳：
final_score = points * 1000000000000L + (1000000000000L - timestamp)-
timestamp必须是毫秒级（如 Java 的System.currentTimeMillis()），不能用秒级 -
1000000000000L（1e12）是位宽锚点：确保points放大后不溢出，且时间部分始终占低12位 - 时间越早 →
timestamp越小 →(1e12 - timestamp)越大 → 同分时排名越靠前 - 全程 long 运算，无精度损失；传入
jedis.zadd(key, (double) final_score, member)安全（≤2⁵³ 的 long 可被 double 精确表示）
为什么不能用小数拼接？
常见错误写法：score = points + timestamp / 1e13，问题很实在：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 时间戳越大（越晚），小数部分越大 → 同分时“后提交的反而排前面”，违反“先到先得”
- double 尾数仅 52 位，13 位毫秒时间戳除以 1e13 后有效位不足，
points稍大就截断小数部分 - 同一毫秒内并发请求，时间戳相同，又退回字典序乱序
- 无法从最终
score无损还原原始points和timestamp，调试和监控困难
必须配合原子操作读取
排行榜查询本身不涉及并发竞争，但如果你用 ZSet 做延迟队列或实时榜单更新，ZRANGEBYSCORE + ZREM 分开调用会导致重复消费。此时必须用 Lua 脚本封装：
local key = KEYS[1]
local min = ARGV[1]
local max = ARGV[2]
local tasks = redis.call('ZRANGEBYSCORE', key, min, max)
if #tasks > 0 then
redis.call('ZREM', key, unpack(tasks))
end
return tasks调用时传入当前时间范围，Redis 在脚本执行期间阻塞其他命令，保证任务只被一个消费者拿到。这点容易被忽略——业务逻辑没毛病，但并发下数据就不对了。
