redis zset不支持多字段排序，可行方案为压缩多维数据至单score（需控精度与量级）或用sort联动外部索引；必须用lua统一计算score以避免客户端浮点差异，且score总和须≤1e14防精度丢失。
Redis 的 ZSet 本身不支持多字段排序，强行塞 JSON 字符串当 score 会直接报 ERR value is not a valid float；真正能落地的方案只有两类：一是把多维数据压缩进单个 score（需严控量级和精度），二是用外部索引 + SORT 命令联动查。前者快但有坑，后者灵活但多一次网络往返。
用 Lua 脚本统一计算复合 score，避免客户端精度不一致
不同语言对浮点数的舍入、溢出处理不一致（比如 Python 的 round() 和 Java 的 Math.round() 对负数结果不同），如果让各服务端自己算 score，同一组输入可能生成不同值，导致 ZSet 排序错乱。
- 必须把计算逻辑下沉到 Redis 服务端，用
EVAL执行 Lua -
ARGV是字符串数组，Lua 里要显式转成数字：tonumber(ARGV[1]) - 时间戳必须由客户端传入，不能在脚本里调
redis.call('TIME')——score必须是确定性的 - 示例脚本：
EVAL "return tonumber(ARGV[1])*1000000 + (tonumber(ARGV[2])%1000000)*100 + tonumber(ARGV[3])" 0 8.5 1717023456 95（质量×10⁶ + 时间后6位×100 + 热度）
score 总和不能超 9007199254740992（2^53），否则丢精度
Redis 内部用 double 存 score，有效十进制精度约 15 位。一旦你把三个维度全拉高位（比如质量 × 1e12 + 时间 × 1e6 + 热度），总和超过 9007199254740992，就会开始出现两个不同输入被存成同一个 score 的情况，排序失效。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 推荐上限控制在
1e14以内，留出安全余量 - 错位相加时，各维度的乘数要按实际取值范围严格对齐（例如热度 0–100 就别乘 1e6，该乘 1）
- 不要用毫秒级时间戳直接参与计算——13 位时间戳本身已占 13 位，再左移极易溢出
- 验证方法：在 Redis CLI 里执行
ZADD test 9007199254740992 a和ZADD test 9007199254740993 b，再ZRANGE test 0 -1 WITHSCORES，看是否显示相同分数
用 SORT + 外部 key 实现真·多字段动态排序
当排序维度经常变化（比如用户可随时切“按价格升序”“按销量降序”“按好评率+上架时间”），硬编码复合 score 维护成本高，此时更适合用 SORT 命令配合外部结构。
- 把商品 ID 存进一个 List 或 Set（如
shop:8182:items） - 每个维度单独建 ZSet：
shop:8182:price存价格，shop:8182:sales存销量，shop:8182:eva存好评率 - 排序时用：
SORT shop:8182:items BY shop:8182:price->* ASC LIMIT 0 10 GET # - 注意：
BY引用的 key 必须是 String 类型，ZSet 不支持直接BY shop:8182:price，得先用 Hash 存详情，再通过->field取值
同分场景下按时间保序，小数位法比 bit 位法更稳
常见误区是用 41bit 时间戳 + 22bit 分数拼 long，再转 double 存——但 Redis 的 score 是 double，强制类型转换会截断低比特，且无法跨语言还原原始时间戳。
- 更可靠的做法是：用整数部分存主分，小数部分存归一化时间（如
score = main_score + (1 - timestamp / 1e13)） - 这样同分时，时间越早（timestamp 越小），小数部分越大，
ZREVRANGE自然靠前 - 小数部分只承担“保序”作用，不用于还原时间，规避了精度丢失风险
- Java 示例：
double combined = score * 1e13 + (1e13 - System.currentTimeMillis())，注意1e13是 double 字面量，运算全程保持 double 精度
最易被忽略的一点：所有方案都依赖「排序维度值必须预先写入 Redis」。如果某个商品的价格或销量更新了，但对应 ZSet 没同步更新，ZRANGE 或 SORT 查出来的就是脏数据——没有自动触发机制，必须靠业务代码保证写操作的原子性或最终一致性。
