Redis卡顿是设计使然，因其单线程模型下Lua脚本原子独占主线程，执行长耗时操作会阻塞所有请求，包括过期、AOF、心跳等；复杂聚合应迁出至应用层。
Redis 本身不擅长复杂聚合运算，卡顿是设计使然，不是配置或硬件问题。 它的单线程模型和原子性保障机制决定了 EVAL 中执行长耗时 Lua 脚本会阻塞整个 Redis 实例——包括键过期、AOF 写入、其他客户端命令，甚至心跳检测。
为什么 Lua 脚本在 Redis 里一跑就卡
Redis 的 Lua 执行是原子且独占主线程的。哪怕脚本里只做一次 for i=1,100000 do redis.call("GET", "key:"..i) end，这 10 万次 redis.call 调用都会串行阻塞所有请求。
- Redis 不会对 Lua 执行做超时中断（
lua-time-limit只控制“是否终止”，但终止后仍需清理状态，且默认 5 秒才触发） -
redis.call每次都走完整命令分发路径，开销远高于纯内存循环 - 脚本中若混用
redis.pcall+ 错误重试逻辑，失败后反复重入更易拖垮响应毛刺 - 集群模式下，跨 slot 的
EVAL直接报错CROSSSLOT Keys in request don't hash to the same slot，逼你改逻辑或拆脚本
哪些聚合场景必须搬出 Redis
以下 Lua 脚本行为，基本都该移去应用层：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 遍历 SCAN 结果做条件累加（如：统计近 7 天活跃用户中 VIP 等级 ≥ 3 的总积分）
- 对多个 Hash 结构做字段级 join 和排序（如：
HGETALL user:123+HGETALL profile:123合并后按 score 排序取 top10） - 在脚本里实现分页逻辑（
table.sort+table.slice），尤其数据量 > 1k - 调用
redis.call("ZRANGEBYSCORE")后再逐条HGET补全详情——这本质是 N+1 查询，网络往返已不可控
迁移时的关键实操要点
不是简单把 Lua 代码复制粘贴到 Go/Python 里就完事，得兼顾正确性、延迟和资源消耗：
- 用
SCAN替代KEYS，并在业务层做游标管理；注意SCAN不保证一次返回全量，需循环 + 去重 - 批量操作优先走
MGET/HMGET/ZMPOP，避免在循环里单 key 请求；例如原脚本中for k in keys do redis.call("GET", k) end→ 改为redis.call("MGET", unpack(keys))（Lua 层）或直接用客户端的mget(keys)（业务层） - 对结果集排序、过滤、分组等，交给语言原生能力（如 Python 的
sorted()、Go 的sort.Slice()），别依赖table.sort+ 自定义比较函数 - 若原脚本靠
redis.call("INCRBY")做并发安全计数，迁出后需用分布式锁（如SET key val NX PX 10000）或数据库乐观锁兜底，不能只靠本地变量
容易被忽略的边界问题
最常翻车的不是逻辑迁移，而是状态一致性被悄悄破坏：
- 原 Lua 脚本里
redis.call("HSET", "user:123", "last_update", time())是原子写入；搬到业务层后，若先查再算再写，中间可能被其他客户端覆盖 - 使用
WATCH/MULTI/EXEC模拟事务？它只对 key 级别 watch 有效，且高并发下失败率陡增，不如直接用 Lua 做小粒度原子更新，或改用 Redlock + 数据库事务 - 本地缓存（如 Go 的
sync.Map）存了聚合中间结果？要小心过期策略和多实例间不一致——Redis 原本靠单实例天然解决这个问题
真正难的不是“怎么搬”，而是判断哪部分该搬、哪部分还得留在 Redis 里用 Lua 快速兜底。比如“用户今日签到次数 + 连续天数”这种轻量状态更新，依然适合 Lua；但“按地域+设备类型+时间段三维分析昨日订单转化漏斗”，就该彻底交给 Flink 或业务服务异步计算。
