redis lua脚本不能解决单线程计算瓶颈，反而加剧卡顿；因其原子独占主线程，耗时操作（如遍历、排序、多key聚合）会阻塞所有请求，且redis.call()在循环中调用开销巨大，应缓存结果、批量操作，并严格使用evalsha+script load与fallback机制。
不能靠把复杂逻辑塞进Lua脚本解决Redis单线程计算瓶颈——这反而会加剧卡顿。 Redis的单线程模型下，Lua脚本是原子、独占主线程执行的，任何耗时操作都会阻塞所有请求，包括键过期、AOF写入、心跳检测。所谓“用Lua提速”，只在特定轻量场景成立；一旦涉及遍历、排序、多key聚合，性能会断崖式下跌。
为什么redis.call()在循环里调用等于自毁
每次redis.call()都走完整命令路径：解析、权限检查、键路由（集群下）、实际执行。哪怕只是重复读同一个KEYS[1]三次，也等于做了三次开销。
- 错误写法：
redis.call('GET', KEYS[1])出现在 if 分支里一次、else 里一次、最后返回前又一次 - 正确做法：用
local val = redis.call('GET', KEYS[1])缓存，后续全用val - 批量读必须用
HMGET/MGET/ZMPOP，而不是 for 循环里反复redis.call('HGET', ...) - 注意：Lua 层的
unpack(ARGV)在 ARGV 元素超 1000 时可能触发栈溢出，生产环境建议客户端分批传参
哪些聚合操作根本不能放Lua里做
以下行为在 Lua 脚本中出现，基本意味着你正在制造一个定时卡顿炸弹：
- 用
SCAN遍历结果后，在脚本里做条件累加（比如统计 VIP 用户积分总和） - 对多个 Hash 做字段级合并再排序（如
HGETALL user:123+HGETALL profile:123→ 拼成 table →table.sort()） - 在脚本里实现分页逻辑，尤其数据量 > 500 条时用
table.slice() -
redis.call('ZRANGEBYSCORE')拿 ID 列表，再循环HGET补详情 —— 这本质是 N+1 查询，网络开销已失控
这些操作该交给客户端语言处理：Python 的 sorted()、Go 的 sort.Slice()、Java 的 Stream API，它们不抢 Redis 主线程，还能并行、限流、打点监控。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
EVALSHA + SCRIPT LOAD 不是优化项，是上线硬门槛
每次用 EVAL 发送完整脚本，等于重复传输几百字节甚至几 KB 文本，还要做 SHA 计算、反序列化、编译。高频调用（如限流器、计数器）时，这部分开销远超逻辑本身。
- 所有脚本必须先
SCRIPT LOAD，缓存返回的 SHA1 值（例如用map[string]string存） - 运行时一律用
EVALSHA，失败时捕获NOSCRIPT错误，自动 fallback 到EVAL并重新SCRIPT LOAD - Redis 重启后脚本缓存清空，没做 fallback 会导致大面积
NOSCRIPT报错 - 禁止字符串拼接生成动态脚本（如
"if "..cond.." then..."），这会让SCRIPT LOAD失效，永远走EVAL
最容易被忽略的一致性陷阱
把 Lua 脚本逻辑迁出到业务层，最难的不是代码重写，而是状态一致性悄悄崩塌：
- 原脚本靠
redis.call('INCRBY')实现并发安全计数，迁出后若只用本地变量累加，会丢数据 - 原脚本用
redis.call('SET', key, val, 'NX', 'PX', 10000)做分布式锁，迁出后没加锁或锁过期未续，会出现竞态 - SCAN 游标管理不在 Redis 层，业务层需自己维护游标状态、去重逻辑、中断恢复机制
- 脚本里用
os.time()或redis.call('TIME')获取时间戳，迁出后客户端和服务端时钟偏差可能引发逻辑错乱
真正关键的不是“能不能跑通”，而是“在并发、失败、重启、时钟漂移等真实条件下，数据还对不对”。这点在压测阶段极难暴露，往往上线后才集中爆发。
