INCR+EXPIRE非原子导致限流丢失，须用Lua封装；Lettuce应复用连接而非频繁close；redis-cell运维复杂且不兼容集群；Gateway限流需正确配置RedisRateLimiter参数。
为什么 INCR + EXPIRE 组合在高并发下会丢限流？
因为 Redis 命令不是原子的——INCR 成功后，如果紧接着的 EXPIRE 失败（比如网络中断、Redis 重启），这个 key 就变成永不过期，后续所有请求都可能被错误放行。
实操建议：
- 改用
INCR+SETNX+EXPIRE三步？不行，还是非原子 - 必须用 Lua 脚本封装逻辑，确保
INCR和过期设置在同一原子上下文中执行 - 示例脚本中，先
INCR，再判断是否首次写入，是则立即PEXPIRE（毫秒级精度更稳）
Java 里用 Lettuce 连 Redis 做分布式限流，怎么避免连接泄漏？
Lettuce 是基于 Netty 的异步客户端，StatefulRedisConnection 是线程安全且可复用的，但很多人误以为每次都要 connect() + close()。
实操建议：
- 全局单例一个
RedisClient，按需获取StatefulRedisConnection，用完不 close - 不要在限流逻辑里调用
connection.close()，这会关闭底层 Netty channel - 若用 Spring Boot，直接注入
ReactiveRedisTemplate或RedisTemplate，它已管理好连接生命周期 - 注意：Lettuce 默认开启
ping-before-activate，高频限流场景可关掉减少冗余命令
redis-cell 模块真能替代手写限流？什么情况下别碰它
redis-cell 提供了 CL.THROTTLE 命令，原生支持漏桶算法，返回剩余次数、重试时间等字段，看起来很省事。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
实操建议：
- 它依赖 Redis 加载外部模块，K8s 环境里要改镜像、加
--loadmodule启动参数，运维成本陡增 - 不兼容 Redis Cluster ——
CL.THROTTLE是多 key 操作，集群模式下会报CROSSSLOT错误 - 如果你的限流粒度是「用户 ID + 接口路径」，而 key 分布在不同 slot，
redis-cell直接不可用 - 小规模单节点 Redis 可试，但上线前务必压测验证吞吐是否反低于 Lua 方案
Spring Cloud Gateway 里集成 Redis 限流，为什么 RequestRateLimiterGatewayFilterFactory 总是 429 却没生效？
这个过滤器默认用内存计数器（RedisRateLimiter 需显式配置），很多项目只配了类名，没配 redis-rate-limiter.replenishRate 和 burstCapacity，导致 fallback 到空实现。
实操建议：
- 确认配置里有
spring.cloud.gateway.filter.request-rate-limiter.deny-empty-key=false，否则 key 为空时直接拒绝 - key 解析器（
KeyResolver）必须返回非空字符串，常见错误是用了exchange.getRequest().getRemoteAddress()，但云环境里拿的是 LB 地址 - 检查 Redis 中实际生成的 key 是否含非法字符（如空格、斜杠），
CLUSTER模式下 key 名不规范会导致MOVED重定向失败 - 调试时可在 Lua 脚本里加
redis.log(redis.LOG_WARNING, "key: "..KEYS[1])，通过MONITOR命令观察真实调用
真正难的不是写对一条 Lua 脚本，而是把 key 的语义、生命周期、跨服务一致性，和业务降级策略对齐。比如“每分钟最多 5 次”在支付回调里可能是硬性闸门，在搜索接口里可能只是触发告警的信号。这些边界不厘清，Redis 再快也没用。
