因为ZINCRBY仅支持对单个member的score做原子加法，无法读取当前score、关联其他key（如热度衰减因子、用户权重、时间戳）并按自定义公式重算，涉及“当前分×衰减系数+新增权重×用户等级”等逻辑时，纯命令组合会丢失原子性，导致并发下分数覆盖或重复累加。
为什么直接用 ZINCRBY 无法满足多维度加权排序需求
因为 ZINCRBY 只支持对单个 member 的 score 做原子加法，无法同时读取当前 score、关联其他 key（比如热度衰减因子、用户权重、时间戳）、再按自定义公式重算。一旦涉及「当前分值 × 衰减系数 + 新增权重 × 用户等级」这类逻辑，纯命令组合会丢失原子性——中间状态可能被并发修改。
常见错误现象：ZSCORE + ZADD 两步走，在高并发下导致分数覆盖或重复累加；或者用客户端计算后再写入，出现竞态条件。
- 必须在服务端一次性完成：读取旧 score、读取辅助数据（如
HGET user:123 level）、执行加权公式、写回新 score - Lua 脚本是唯一能保证原子性 + 支持分支/循环 + 可调用 Redis 命令的方案
- 注意 Redis 7.0+ 支持函数式 Lua 沙箱，但老版本需确保脚本不带全局变量或
math.random()等禁用函数
如何编写安全可复用的加权更新 Lua 脚本
核心是把加权逻辑封装成参数化函数，避免硬编码字段名和权重系数。以下是一个典型场景：对 feed:zset 中的 member，按「当前分 × 0.99（每小时衰减） + 新互动分 × 用户等级」更新：
local zset_key = KEYS[1]
local member = ARGV[1]
local new_score = tonumber(ARGV[2])
local user_id = ARGV[3]
<p>-- 读取当前分（不存在则为 0）
local old_score = tonumber(redis.call('ZSCORE', zset_key, member)) or 0</p><p>-- 读取用户等级（假设存于 hash）
local level = tonumber(redis.call('HGET', 'user:'..user_id, 'level')) or 1</p><p>-- 加权计算：衰减 + 权重放大
local final_score = old_score <em> 0.99 + new_score </em> level</p><p>-- 写回
redis.call('ZADD', zset_key, final_score, member)</p><p>return final_score
-
KEYS和ARGV必须严格区分：key 名走KEYS（用于沙箱校验），动态值（member、数值、ID）走ARGV - 所有
redis.call()返回值需显式类型转换，tonumber()防止 nil 导致脚本中断 - 避免在脚本里做耗时操作（如大范围
ZRANGE），否则阻塞 Redis 主线程
如何在不同语言客户端中正确调用并传参
关键不是“怎么连 Redis”，而是“怎么把参数组织成 Lua 能安全解析的格式”。不同客户端对 KEYS/ARGV 的传递方式略有差异，容易踩坑：
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- Python（redis-py）：
r.eval(script, 1, 'feed:zset', 'post:456', '2.5', 'user:789')—— 第二个参数是numkeys，必须等于KEYS数量，且KEYS必须连续排在ARGV最前面 - Java（Lettuce）：
redis.eval(script, ScriptOutputType.VALUE, Collections.singletonList("feed:zset"), "post:456", "2.5", "user:789")—— 注意Collections.singletonList传的是 key 列表，不是数量 - Node.js（ioredis）：
redis.eval(script, 1, 'feed:zset', 'post:456', '2.5', 'user:789')—— 和 Python 一致，但漏写1会导致所有参数进ARGV，KEYS[1]取不到 key
常见错误：把 user_id 当作 key 放进 KEYS，触发 Redis 的 key 预检失败（报错 ERR Error running script (call to f_...): @user_script:...: wrong number of arguments）。
性能与边界问题必须提前验证
Lua 脚本不是银弹。当加权逻辑变复杂（比如要查多个 hash、做条件分支、遍历小范围 zset），性能下降会非常陡峭：
- 单次脚本执行超过 5ms 就该警惕；Redis 默认
lua-time-limit是 5000ms，超时会强制终止并返回BUSY错误 - 如果加权公式依赖实时时间（如
redis.call('TIME')），注意主从时钟差可能导致分数不一致 - 不要在脚本里用
while循环暴力重试，Redis 不允许长时间运行；改用客户端退避重试 - 上线前务必用
redis-cli --eval手动测试边界：member 不存在、user hash 不存在、分数为负数等场景
真正麻烦的从来不是写对脚本，而是当业务方突然说“再加一个基于地域的权重系数”时，你得立刻判断：这个新字段要不要进 KEYS？会不会让脚本跨 slot？要不要拆成两个脚本分步执行？
