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 命令，原生支持漏桶算法，返回剩余次数、重试时间等字段，看起来很省事。
mallcloud商城
下载
mallcloud商城基于SpringBoot2.x、SpringCloud和SpringCloudAlibaba并采用前后端分离vue的企业级微服务敏捷开发系统架构。并引入组件化的思想实现高内聚低耦合，项目代码简洁注释丰富上手容易，适合学习和企业中使用。真正实现了基于RBAC、jwt和oauth2的无状态统一权限认证的解决方案，面向互联网设计同时适合B端和C端用户，支持CI/CD多环境部署，并提
实操建议：
- 它依赖 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 再快也没用。
