StringIncrement 无法可靠限流，因其不能原子性完成“读值→判断→更新”，并发时会导致计数漂移、旧数据残留及窗口滑动异常。
为什么不用 StackExchange.Redis 的 StringIncrement 直接做限流
直接用 StringIncrement + 过期时间看似简单，但会漏掉关键边界：窗口滑动时旧数据未清理、并发写入导致计数漂移、无法原子判断“是否超限并更新”。比如两个请求同时读到当前值为 9，都执行 INCR，结果变成 11 而不是预期的 10 —— 这就突破了限制。
真正可靠的方案必须在一个 Redis 原子操作中完成「读当前值 → 判断是否
用 Lua 脚本实现滑动窗口限流（令牌桶兼容）
下面这个脚本支持两种模式：固定窗口（简单高效）和滑动窗口（更精确）。它利用 Redis 的 EVAL 原子执行，避免竞态：
local key = KEYS[1] local limit = tonumber(ARGV[1]) local window_ms = tonumber(ARGV[2]) local is_sliding = tonumber(ARGV[3]) == 1local current = redis.call("GET", key) if current == false then current = 0 end
if is_sliding == 1 then -- 滑动窗口：用 ZSET 存时间戳，自动剔除过期项 local now = tonumber(ARGV[4]) redis.call("ZREMRANGEBYSCORE", key, 0, now - window_ms) local count = tonumber(redis.call("ZCARD", key)) if count < limit then redis.call("ZADD", key, now, now .. ":" .. math.random(1000, 9999)) redis.call("EXPIRE", key, math.ceil(window_ms / 1000) + 1) return 1 else return 0 end else -- 固定窗口：用 String + EXPIRE if tonumber(current) < limit then redis.call("INCR", key) if tonumber(current) == 0 then redis.call("EXPIRE", key, math.ceil(window_ms / 1000)) end return 1 else return 0 end end
注意：ARGV[4] 是客户端传入的毫秒时间戳（如 DateTimeOffset.UtcNow.ToUnixTimeMilliseconds()），用于滑动窗口对齐；math.random 避免 ZSET 成员重复。
C# 中调用脚本的正确姿势（StackExchange.Redis）
别把 Lua 脚本硬编码在 C# 字符串里拼接，容易出错且无法复用。应预加载并缓存 LuaScript.Prepare(...) 实例：
-
ConnectionMultiplexer必须启用AbortOnConnectFail = false，否则网络抖动会导致限流逻辑静默失败 - 使用
IDatabase.ScriptEvaluateAsync，传入RedisKey[]和RedisValue[]，不要用字符串数组 - 检查返回值是
True（允许）还是False（拒绝），null表示 Redis 执行异常（如连接中断）
示例调用：
private static readonly LuaScript _rateLimitScript = LuaScript.Prepare(@"
... // 上面的 Lua 脚本内容
");
// key 格式建议：rate:api:/users/{id}:192.168.1.100
var db = _redis.GetDatabase();
var result = await db.ScriptEvaluateAsync(
_rateLimitScript,
new RedisKey[] { key },
new RedisValue[] {
limit.ToString(),
windowMs.ToString(),
isSliding ? "1" : "0",
DateTimeOffset.UtcNow.ToUnixTimeMilliseconds().ToString()
});
if (result.IsNull || !(bool)result)
{
throw new InvalidOperationException("Rate limit exceeded");
}
Key 设计与内存泄漏风险
Key 如果不带业务维度（比如只用 "rate:login"），所有用户共享一个计数器，完全失去意义；如果粒度太细（如 "rate:login:123456789" 但没清理），长期运行会堆积海量 key。
推荐组合方式：rate:{area}:{endpoint}:{client_id_or_ip}，其中：
-
{area}区分服务模块（auth、payment） -
{endpoint}用路由模板（/api/v1/orders，而非带参数的完整 URL） -
{client_id_or_ip}优先用认证 ID，未登录时 fallback 到HttpContext.Connection.RemoteIpAddress
滑动窗口模式下，ZSET 自动过期，但固定窗口仍依赖 EXPIRE。务必确认 Redis 配置中 maxmemory-policy 不是 noeviction，否则内存满后新 key 写入失败，限流失效。
最易被忽略的是：Lua 脚本里的 EXPIRE 只在 key 初始创建时生效，后续 INCR 不重置 TTL —— 所以固定窗口必须靠首次写入时设置过期，不能依赖后续操作。
