redis不支持跨key join或聚合，lua脚本是唯一服务端原子聚合方案，但须严守keys声明、同槽限制、时间约束及避免高开销操作。
Redis 本身不支持跨 key 的 JOIN 或聚合（如 SUM、AVG、GROUP BY），业务层拉取多个 key 再计算不仅慢，还容易因网络/并发导致数据不一致。Lua 脚本是唯一能在服务端原子执行、访问多个 key 并完成简单聚合的方案——但必须严格遵循其限制，否则反而引入 bug 或性能瓶颈。
为什么不能直接用 redis.call("GET", key1) + redis.call("GET", key2) 做任意聚合
Lua 脚本在 Redis 中运行时受沙箱约束：不能调用外部库、不能 sleep、不能做 IO，且所有 key 必须显式声明为 KEYS 参数（否则集群模式下会报错 CROSSSLOT Keys in request don't hash to the same slot）。更重要的是，Redis 对 Lua 执行时间有硬限制（默认 lua-time-limit 5000 毫秒），超时会强制中断并返回错误。
- 脚本中未通过
KEYS[1],KEYS[2]等方式访问 key，而是拼接字符串再调用redis.call→ 集群环境直接失败 - 对大量 key 循环调用
redis.call("HGETALL", ...)→ 数据量稍大（比如每个 hash 有 100+ 字段）就极易超时 - 在脚本里做复杂浮点运算或字符串分割 → Lua 解释器性能差，且 Redis 的 Lua 不支持
math.fmod等部分函数
聚合前必须确保所有 key 在同一 slot（尤其 Redis Cluster）
Redis Cluster 要求一个 Lua 脚本内所有操作的 key 必须落在同一个哈希槽，否则拒绝执行。最稳妥的方式是用 {} 包裹 key 名强制哈希对齐，例如：user:{1001}:profile 和 user:{1001}:stats 会被哈希到同一 slot；而 user:1001:profile 和 user:1001:stats 则大概率分散。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 检查方式：用
redis-cli --cluster check <host>:<port></port></host>确认目标 key 是否同 slot - 迁移存量 key：用
redis-cli --cluster reshard或客户端重写 key 名（加{...}） - 如果业务无法统一 key 结构，只能改用客户端分片 + 多次请求，放弃原子性
典型场景：多 Hash key 的数值字段求和（如用户订单总金额 + 优惠券抵扣总和）
假设 order:{uid}:summary 存订单金额（field total），coupon:{uid}:used 存已用优惠券面额（field amount），需原子获取两者之和：
local order_key = KEYS[1]
local coupon_key = KEYS[2]
local order_total = tonumber(redis.call("HGET", order_key, "total")) or 0
local coupon_amount = tonumber(redis.call("HGET", coupon_key, "amount")) or 0
return order_total + coupon_amount
注意：tonumber() 不可省略，因为 HGET 返回的是字符串；若字段不存在，HGET 返回 nil，tonumber(nil) 是 nil，再参与加法会得 nil，所以必须用 or 0 容错。
- 调用方式（redis-cli）：
eval "<script>" 2 user:{123}:order_summary user:{123}:coupon_used</script> - 如果字段是数组（如多个订单分别存为
order:{uid}:1,order:{uid}:2），应改用SCAN+KEYS模式预过滤，但需承担 scan 非原子、可能漏数据的风险 - 不要在脚本里遍历整个 hash（
HGETALL）再循环 sum —— 字段数 > 50 就可能超时
真正难的不是写 Lua，而是判断哪些聚合能放进脚本、哪些必须放回业务层。比如需要按时间范围筛选再分组统计，或者涉及外部数据源比对，这类逻辑强行塞进 Lua 只会让问题更隐蔽——超时、内存溢出、结果不可测，都比多一次网络往返代价高得多。
