redis+lua限流的核心是保障原子性、低延迟与可复用性；incr+expire非原子会导致key永久残留或限流失效，须用set+nx或get+incrby+expire组合兜底。
Redis + Lua 脚本实现限流，核心不是“怎么写脚本”，而是**如何让脚本真正原子、低延迟、可复用且不踩坑**。单靠 INCR + EXPIRE 组合在高并发下会丢令牌、漏判断、误放行——这不是脚本写得不够好，是没把 Redis 的原子边界和 Lua 执行模型吃透。
为什么不能直接用 INCR + EXPIRE 两步操作？
这是最常被忽略的致命点。很多人写成：
redis.call("INCR", key)
redis.call("EXPIRE", key, ttl)
看似简单，但这两条命令不是原子的：如果第一条成功、第二条因网络中断或 Redis 主从切换失败，key 就永久存在，后续所有请求都被阻塞。更糟的是，EXPIRE 在 key 不存在时返回 0，但不会报错，脚本继续执行，导致限流失效。
正确做法必须用 GET + INCRBY + EXPIRE 三者嵌套在同一个 if 分支里，且依赖 redis.call("expire", key, ttl) 的返回值做兜底判断。实际生产中建议统一用 SET key value EX ttl NX 替代，但注意它不支持自增，需配合 INCR 和 GETSET 手动模拟。
令牌桶 vs 计数器：Lua 脚本里怎么选算法？
不是“哪个算法更好”，而是“你的业务能不能容忍突刺”。计数器（固定窗口）脚本短、快，但窗口切换瞬间流量翻倍；令牌桶平滑但需维护时间戳和剩余令牌数，脚本逻辑翻倍。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 计数器适用场景：
KEYS[1]是"user:123:login"这类强隔离维度，且允许每分钟最后 1 秒集中打满 100 次 - 令牌桶必要场景：
KEYS[1]是"api:/order/create"，下游 DB 只能扛 50 QPS，必须匀速放行 - 关键差异：令牌桶脚本里必须用
redis.call("time")获取毫秒级时间戳，再算出应新增令牌数（(now - last_time) / 1000 * rate），不能只靠EXPIRE
KEYS 和 ARGV 怎么传才不出错？
Spring Boot 里用 RedisTemplate.execute() 调用时，KEYS 必须是真实 Redis key（如 "rate:uid:456"），不能带占位符或拼接逻辑；ARGV 才放动态参数。常见错误：
- 把限流阈值硬编码进脚本，每次改都要
EVAL重载，压测时 CPU 爆表 -
ARGV[1]传字符串"100"，Lua 里没用tonumber()转型，比较时变成字符串比大小，"2" > "10"返回 true - 用
KEYS[1]拼接前缀，如"prefix:" .. KEYS[1]，结果 key 冲突或命中不到数据
安全写法：Java 层拼好完整 key 传入 KEYS[1]，所有数字参数走 ARGV 并强制 tonumber()。
性能瓶颈往往卡在 Lua 脚本之外
脚本本身执行很快（微秒级），但慢在三件事：
- 网络往返：每次限流都
EVAL发送脚本文本？错。应该先SCRIPT LOAD缓存，后续用EVALSHA调用 SHA1 值，省 90% 字节传输 - 连接池耗尽：限流是高频操作，
RedisTemplate默认连接池 max-active=8，QPS 超 200 就排队，要调大并设 timeout - key 过期策略：用
EXPIRE不如用PEXPIREAT设绝对毫秒时间戳，避免因 Redis 时钟漂移导致 key 提前/延后过期
真正压测时，90% 的 TIMEOUT 或 NOAUTH 错误都不是脚本问题，而是连接池或序列化配置没对齐。
