不能只用INCR+EXPIRE做滑动窗口，因其非原子操作易致竞态与漏限；必须用Lua脚本原子执行ZREMRANGEBYSCORE清理、ZCARD统计、ZADD插入三步，并以Redis服务端TIME获取时间戳确保精度。
为什么不能只用 Redis 的 INCR + EXPIRE 做滑动窗口
因为 INCR 和 EXPIRE 是两个独立命令，中间存在竞态窗口：如果服务在 INCR 后、EXPIRE 前崩溃，key 就会永久存在；更关键的是，滑动窗口需要「统计过去 N 秒内所有请求时间戳」，而单纯计数无法区分时间粒度。必须用 Lua 脚本把「读取、判断、插入、清理」原子化执行。
滑动窗口 Lua 脚本怎么写才安全可靠
核心逻辑是：用一个 sorted set 存储每次请求的时间戳（score = 当前毫秒时间），每次请求时：
• 先 ZREMRANGEBYSCORE 清理过期时间戳
• 再 ZCARD 获取当前窗口内请求数
• 如果未超限，ZADD 新时间戳并返回 1，否则返回 0
示例脚本（保存为 sliding_window.lua）：
local key = KEYS[1]
local window_ms = tonumber(ARGV[1])
local max_count = tonumber(ARGV[2])
local now_ms = tonumber(ARGV[3])
<p>-- 清理过期元素（早于 now_ms - window_ms 的）
redis.call('ZREMRANGEBYSCORE', key, 0, now_ms - window_ms)</p><p>-- 获取当前窗口请求数
local current = redis.call('ZCARD', key)</p><p>if current < max_count then
redis.call('ZADD', key, now_ms, now_ms)
return 1
else
return 0
end注意点：
-
KEYS[1]必须是唯一标识（如"rate_limit:ip:" + ip），避免不同用户共用 key -
ARGV[3]传入客户端时间不可靠，务必由 Java 侧调用System.currentTimeMillis()传入 - 不要用
TIME命令——Redis 集群下各节点时间可能不一致
Spring Boot 怎么加载并执行这个 Lua 脚本
别用 StringRedisTemplate.eval() 每次传脚本字符串，既低效又易出错。应该预加载 SHA1 值，用 evalSha 执行：
先注入 RedisTemplate 和 ResourceLoader，在 Bean 初始化时加载：
@PostConstruct
public void loadLuaScript() {
try (InputStream is = resourceLoader.getResource("classpath:sliding_window.lua").getInputStream()) {
String script = StreamUtils.copyToString(is, StandardCharsets.UTF_8);
this.slidingWindowSha = stringRedisTemplate.execute(RedisScript.of(script, Long.class));
} catch (IOException e) {
throw new RuntimeException("Failed to load Lua script", e);
}
}执行时：
public boolean tryAcquire(String key, long windowMs, int maxCount) {
long now = System.currentTimeMillis();
Object result = stringRedisTemplate.execute(
RedisScript.of("return 0", Long.class), // 占位，实际用 evalSha
Collections.singletonList(key),
String.valueOf(windowMs), String.valueOf(maxCount), String.valueOf(now)
);
// 注意：必须用 evalSha 传入 slidingWindowSha，否则上面的占位没意义
return (Long) result == 1L;
}关键细节：
- 必须用
stringRedisTemplate.execute(RedisScript, ...)形式，不能用execute(String)直接传脚本内容 - 集群模式下，
KEYS[1]必须保证所有操作落在同一 slot，所以 key 名里不能含{}分片标记，或确保大括号内部分相同 - 返回值类型要和 Lua 中
return类型严格一致（这里是Long.class）
怎么跟 Spring MVC 请求链路集成且不侵入业务代码
最轻量的方式是写一个 HandlerInterceptor，在 preHandle 里做限流判断，失败直接返回 429：
public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) {
String ip = getClientIp(request);
String key = "rate_limit:ip:" + ip;
boolean allowed = rateLimiter.tryAcquire(key, 60_000, 100); // 60秒100次
if (!allowed) {
response.setStatus(HttpStatus.TOO_MANY_REQUESTS.value());
response.setContentType("application/json;charset=UTF-8");
response.getWriter().write("{\"error\":\"rate limited\"}");
return false;
}
return true;
}但要注意：
- 别在拦截器里硬编码限流参数，应通过注解（如
@RateLimit(window = 60, count = 100)）提取到方法上 - IP 获取不能只依赖
request.getRemoteAddr()，需兼容 Nginx 转发场景（检查X-Forwarded-For） - Redis 连接池配置要调高
max-active和max-wait，否则限流本身成瓶颈
脚本执行耗时虽短，但高频调用下 Lua 解析、网络往返、序列化开销叠加起来，容易成为性能拐点。真正上线前，务必用 jmeter 或 wrk 在压测中验证 Redis 的 used_cpu_sys 和 latency 指标。
