Redis有序集合仅按score排序，不支持多字段或条件排序；需用Lua脚本在服务端原子重排，如score相同时按name字典序，避免客户端排序导致的性能与一致性问题。
Redis 有序集合本身不支持多字段或条件排序
zset 的 score 是单一数值，所有排序逻辑都基于它。想按字符串长度、时间戳+优先级组合、或者“score 相同时按 name 字典序”来排？ZRANGE 或 ZREVRANGE 做不到——它们只认 score，不看 value 内容。
常见错误现象：ZRANGEBYSCORE myzset 0 100 WITHSCORES 返回结果顺序看似“合理”，其实是 score 碰巧对齐了业务逻辑；一旦数据写入方式变化（比如用时间戳当 score），顺序立刻错乱。
- 真正能控制排序细节的，只有 Lua 脚本——它在服务端原子执行，能读取每个 member 的完整信息（包括 value）
- 不能把排序逻辑放到客户端：网络延迟 + 多次
ZRANGE+ 内存组装，既慢又可能被并发写入破坏一致性 - 注意 Redis 集群模式下，Lua 脚本里只能操作同一个 slot 的 key；如果 zset 和辅助 hash 存在不同 slot，脚本会报
CROSSSLOT Keys in request don't hash to the same slot
用 Lua 脚本实现“score 相同时按 name 排序”
这是最典型的扩展需求：避免相同 score 导致的返回顺序不确定（Redis 6.2 之前 zset 内部用 skiplist，相同 score 的插入顺序影响遍历顺序，但不保证稳定）。
核心思路：用 redis.call('ZRANGE', ...) 拿出原始数据，再在 Lua 里用 table.sort 重排。示例脚本：
local members = redis.call('ZRANGE', KEYS[1], 0, -1, 'WITHSCORES')
local t = {}
for i = 1, #members, 2 do
table.insert(t, {member = members[i], score = tonumber(members[i+1])})
end
table.sort(t, function(a, b)
if a.score ~= b.score then return a.score < b.score end
return a.member < b.member -- score 相同，按 member 字典序升序
end)
local result = {}
for _, v in ipairs(t) do
table.insert(result, v.member)
table.insert(result, tostring(v.score))
end
return result- 这个脚本返回的是
member和score交错的数组，和原生ZRANGE ... WITHSCORES格式一致，可直接替换调用 -
table.sort在 Lua 5.1（Redis 内置版本）中是不稳定排序，但上面的比较函数已确保完全有序（score + member 双条件），不影响结果 - 别在脚本里用
redis.call('GET', ...)查额外字段——那会极大拖慢性能；如需 name 以外的字段（比如 status），应提前存进 zset 的 member 字符串里，例如"user:1001|active"，再用string.match解析
性能临界点：什么时候不该用 Lua 做排序
脚本执行是单线程阻塞的。zset 有 10 万成员？哪怕只取 top 10，ZRANGE key 0 -1 也会把全部数据拉进 Lua 内存，再排序——这比客户端分页还慢。
- 安全阈值参考：zset 成员数 ≤ 5000 时，Lua 全量排序较稳妥；超过 1 万，必须改用分段策略
- 分段策略示例：先用
ZRANGEBYSCORE key min max LIMIT 0 100拿出候选集（比如 score 在 [10, 20] 区间的所有人），再对这 100 条做 Lua 排序 - 如果排序规则涉及外部状态（如用户实时在线状态），Lua 更不合适——它无法实时查哨兵或外部 API，这类场景该由业务层兜底，Redis 只存快照
调试 Lua 脚本时最容易忽略的类型陷阱
Redis 返回的 score 是字符串，tonumber() 转换失败会得 nil，导致 table.sort 报错 attempt to compare nil with number。
- 永远对 score 做容错：
local s = tonumber(members[i+1]) or 0 - member 是二进制安全的，但 Lua 字符串比较默认按字节序；如果 member 含中文或 emoji，
a.member 可能不符合预期，此时应提前转成规范编码（如 UTF-8 归一化）或改用哈希值比较 - 用
redis.log(redis.LOG_WARNING, ...)打日志？没用——Redis 默认关闭 Lua 日志，且生产环境通常禁用；真要调试，先在本地redis-cli --eval测试，再检查redis.call返回值是否为空表
复杂排序真正难的不是写脚本，而是想清楚哪些维度必须在服务端定序，哪些可以妥协到客户端补全。一旦引入 Lua，就等于把一部分业务逻辑锁死在 Redis 版本和集群拓扑里。
