ZINCRBY 不够安全因无法满足“查-判-写”原子性需求，需用Lua脚本将ZSCORE判断与ZADD更新封装为单次原子操作，返回1/0标识业务结果。
为什么直接用 ZINCRBY 不够安全？
Redis 的 ZINCRBY 本身是原子的，但排行榜常需「先查当前分数、再决定是否更新、最后写入」这类复合逻辑——比如用户只在新分数更高时才覆盖旧分。这种“读-判-写”三步操作在并发下会丢失更新：两个客户端同时读到旧分，各自算出新分后写回，后到者覆盖前者结果。
真正需要原子性的是整个业务逻辑，不是单个命令。Lua 脚本能将多条命令打包进 Redis 单线程执行，天然规避竞态。
怎么写一个安全更新排行榜的 Lua 脚本？
核心思路：用 EVAL 把判断和更新压进一个脚本里，传入 key、member、new_score 三个参数。
常见错误是把条件判断写在客户端，或漏掉返回值校验。正确做法是让 Lua 返回操作结果（如 1 表示已更新，0 表示被拒绝），方便上层决策。
-
redis.call("ZSCORE", KEYS[1], ARGV[1])先查原分，注意返回nil表示不存在 - 用
tonumber()转换结果，避免字符串比较出错 - 只在
new_score > old_score时调用ZADD，并用XX选项确保不新增成员（可选） - 最后
return 1或0，别依赖ZADD返回值——它返回的是插入数量，不是业务成功与否
eval "local old = redis.call('ZSCORE', KEYS[1], ARGV[1]); if not old then old = '-inf' end; if tonumber(ARGV[2]) > tonumber(old) then redis.call('ZADD', KEYS[1], ARGV[2], ARGV[1]); return 1 else return 0 end" 1 leaderboard:user:weekly user_123 876
使用 EVALSHA 还是 EVAL？
如果脚本固定且高频调用，优先用 EVALSHA。Redis 会缓存已加载的 Lua 脚本 SHA1 值，省去每次传输和解析开销。
容易踩的坑是没做脚本预加载（SCRIPT LOAD），导致首次 EVALSHA 返回 NOSCRIPT 错误；或者服务重启后未重新 LOAD，就直接用旧 SHA 调用。
- 上线前用
SCRIPT LOAD加载一次，记录返回的 SHA 值 - 代码中先尝试
EVALSHA，捕获NOSCRIPT后 fallback 到EVAL并重试 - 不要把 SHA 硬编码在配置里——不同 Redis 实例可能因版本/配置差异导致脚本哈希不一致
排行榜分页查询时，Lua 能帮上忙吗？
不能。Lua 脚本适合写操作或简单读判断，但分页查榜（比如“第 100–109 名”）必须用 ZREVRANGE 或 ZRANGE 配合 WITHSCORES，这些命令本身已足够高效且原子。
有人试图在 Lua 里做分页裁剪，反而拖慢响应——脚本执行期间阻塞整个 Redis 单线程，而原生命令由 C 实现，更轻量。
真正要注意的是：用 ZREVRANGEBYSCORE 做分数区间分页时，若大量用户同分，LIMIT 可能漏数据；此时得靠唯一递增字段（如时间戳拼接）做二级排序，这一步必须在客户端或写入时完成，Lua 无法绕过这个限制。
Redis 的 Lua 支持很稳，但它的价值只在“必须原子执行多步逻辑”时才不可替代。多数场景下，滥用脚本反而掩盖了设计问题——比如该用 ZADD 的 CH 选项就别手写判断，该用 ZREMRANGEBYRANK 清理就别循环删。脚本不是银弹，只是把锁从客户端搬进了服务端。
