Redis + Lua 实现原子性限流更可靠，因单靠INCR+EXPIRE存在崩溃导致key永久残留风险，而Lua脚本在服务端原子执行，彻底规避竞态；必须将计数、过期设置、超限判断封装于同一脚本中。
Redis + Lua 实现原子性限流为什么比单纯用 StringRedisTemplate 更可靠
因为单靠 INCR + EXPIRE 两步操作无法保证原子性：如果服务在 INCR 成功后、EXPIRE 前崩溃，key 就会永久存在；而 Lua 脚本在 Redis 服务端一次性执行，天然规避竞态。Spring Boot 中直接调用 redisTemplate.execute() 执行内联 Lua 或预加载脚本是最稳妥的方式。
常见错误现象：RateLimiter.tryAcquire() 在高并发下漏放行、限流阈值漂移、同一请求被重复计数。
- 必须把“计数 + 过期设置 + 判断是否超限”全部写进一个 Lua 脚本里，不能拆成多次 Redis 命令
- 脚本中用
redis.call('INCR', KEYS[1])而非redis.call('GETSET', ...)，避免覆盖旧值导致计数丢失 - 首次调用时需用
redis.call('EXPIRE', KEYS[1], ARGV[2])设置过期，而不是SETEX——后者在 key 已存在时不重设 TTL - 返回值建议统一为整数：0 表示拒绝，1 表示通过，-1 表示系统异常（如脚本执行报错）
如何封装一个线程安全、可复用的 RedisRateLimiter 类
别直接在 Controller 里硬写 Lua 调用逻辑。应该抽成一个 Bean，支持按 key（如用户 ID、接口路径）、permitsPerSecond、timeoutSeconds 动态限流。
关键点在于：Lua 脚本要预加载进 Redis，而不是每次拼字符串；RedisTemplate 的序列化器必须设为 StringRedisTemplate 或显式指定 StringRedisSerializer，否则 KEYS[1] 可能被序列化成乱码。
- 使用
DefaultRedisScript<Long>加载脚本，设置setScriptText(...)或从 classpath 读取rate_limit.lua - 执行时传入
Arrays.asList(key)作为 keys，Arrays.asList(String.valueOf(permits), String.valueOf(windowSeconds))作为 args - 捕获
RedisSystemException和LuaScriptException，避免因 Redis 不可用导致整个接口失败 - 不要在脚本里做复杂逻辑（比如拼接 key），key 应由 Java 层生成并传入，减少出错可能
tryAcquire 返回 false 却没触发限流日志？检查这几点
很多团队发现限流看似生效，但日志里看不到“被拒绝”的记录，其实是调用方没处理返回值，或拦截器吞掉了响应。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
典型场景：Feign 调用下游接口前做限流，但 if (!limiter.tryAcquire(...)) { throw new RuntimeException("rejected"); } 没写，或者异常被全局 @ExceptionHandler 吞掉并返回了 200。
- 确保限流判断后有明确分支：放行走业务逻辑，拒绝走
ResponseEntity.status(HttpStatus.TOO_MANY_REQUESTS).build()或抛自定义异常 - 如果用 Spring Cloud Gateway，别在 route filter 里手动调 Lua，优先用内置的
redis-rate-limiter配置，它底层就是 Lua - 注意 Lua 脚本返回值类型：Spring 默认把
Long当作布尔处理（0=false, 非0=true），但你实际需要的是数值对比，所以 execute 方法应声明返回Long，而非Boolean - 本地测试时禁用 Redis 密码或配置
spring.redis.password=，否则RedisConnectionFailureException会掩盖真实限流逻辑问题
为什么用 RateLimiter（Guava）+ Redis 同步状态是危险的组合
Guava 的 RateLimiter 是纯内存的，分布式环境下每个实例都有一份独立状态，根本起不到“分布式”限流作用。有人试图用 Redis 存储剩余 permits 并定时同步，这既增加延迟又引入一致性难题。
正确做法只有一种：所有限流决策必须由 Redis 单点完成。Guava 的 RateLimiter 只适合单机压测或降级兜底，绝不能作为主限流器。
- 删掉所有类似
rateLimiter.tryAcquire() && updateRedisCount()的代码——这是典型的伪分布式 - 如果你需要平滑限流（比如令牌桶动态填充），Lua 脚本里必须自己实现时间戳差值计算，用
redis.call('TIME')获取秒级时间，别依赖客户端时间 - 注意 Redis 集群模式下，key 必须落在同一个 slot，所以 key 命名要带
{xxx}前缀，例如{user:123}:rate_limit
真正麻烦的不是写脚本，而是验证它在分片、故障转移、时钟偏移下的行为。上线前务必用 redis-cli --eval 手动跑几次 Lua，观察返回值和 TTL 变化。
