Golang 实现高性能的滑动窗口计数器与漏桶算法对比-Golang-PHP中文网

滑动窗口计数器不能用无锁map+time.Now()，因并发读写panic、遍历删key性能差且时间戳取整导致统计偏差；应使用预分配原子数组分片；漏桶禁用time.Ticker，需按需补token并防时钟回拨；rate.Limiter是令牌桶非漏桶；分布式必须用Redis ZSET+Lua+服务端时间。

滑动窗口计数器为什么不能用 map + time.Now() 判断过期

直接用 map[int64]int 存每个时间戳的请求数，再每次请求时遍历删掉 time.now().unix() - 60 之前的 key，这不是滑动窗口，是固定窗口，且高并发下必 panic。现象是程序运行几秒后突然崩溃，报 concurrent map read and map write ——因为没加锁，而多个 goroutine 同时读写 map 是 go 运行时明确禁止的。

就算加了 sync.RWMutex，性能也极差：每秒上千请求时，遍历 map 删除旧 key 的成本线性增长，CPU 毛刺明显。更关键的是逻辑错误：它只保留“整秒对齐”的时间戳，比如窗口是 60 秒，但请求发生在 1715532841.321 和 1715532841.999，这两个时间戳取整后都是 1715532841，会被塞进同一个 key；而 1715532840.999 却被算作上一秒，提前清掉——导致统计漏掉近 1 秒的流量。

真正滑动窗口必须支持任意时刻往前推 N 秒的累计值，所以得保留带精度的时间分片或原始时间戳。推荐做法：

单机场景：预分配 []int64，长度 = 窗口秒数 / 分片毫秒数（如 60 秒窗口、100ms 分片 → 长度 600），用 atomic.AddInt64 更新对应 slot
索引计算必须用 (now.UnixNano() / shardDuration) % int64(shards)，且 shardDuration 要能整除窗口总长，否则边界错位
过期判断不能只比索引差，得用绝对时间：某 slot 对应起始纳秒 = slotIndex * shardDuration，和 now.UnixNano() - windowSec*1e9 比较

漏桶算法为什么不能用 time.Ticker 定期补 token

用 time.Ticker 每 100ms 往 channel 塞一个 token，再从 channel 取 token 放行请求，这看着像漏桶，实则是硬编码节奏的“假漏桶”。问题在于它完全不响应请求到达节奏：如果连续 5 个请求在 2ms 内抵达，Ticker 才 tick 了一次，channel 里只有 1 个 token，其余 4 个全拒——但这不是限流，是丢包；而真正的漏桶应允许“匀速漏出”，即只要桶里有 token 就放行，没 token 才等。

更严重的是时钟回拨风险：time.Now() 可能因 NTP 校正倒退，导致补 token 时算出负增量，token 数暴增，限流形同虚设。生产环境必须用单调时钟。

正确做法是按需补桶：

记录上次更新时间 lastTime 和当前 token 数 tokens，都用 atomic.Value 或 sync.Mutex 保护
每次请求来时，用 runtime.nanotime() 算真实流逝纳秒，按速率折算应增加的 token 数：delta := (now - lastTime) * rate / 1e9
tokens = min(capacity, tokens + delta)，再判断是否 ≥ 1 并扣减
别用 float64 做中间计算，统一用 int64 纳秒+整数速率，避免浮点误差累积

rate.Limiter 是令牌桶，不是漏桶，别混淆语义

golang.org/x/time/rate.Limiter 底层是平滑令牌桶（smooth token bucket），不是严格意义的漏桶。它的 Allow() 或 Wait() 行为本质是：“检查从现在往前推 burst 容量所需时间是否已过”，而非维护一个持续流动的水桶。这意味着它天然支持突发（burst），而漏桶强调恒定输出速率。

Golang Uber Dig

使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等

下载

常见误用：

以为 rate.NewLimiter(rate.Every(200*time.Millisecond), 3) 表示“每秒 5 次”，其实它允许瞬间连发 3 次，之后必须等 200ms 才能发第 4 次
传给 AllowN() 的时间戳截断到秒级（如 time.Now().Unix()），导致窗口错位，同一秒内多次调用全被当作同一时刻，放行过多
为每个 HTTP 请求 new 一个 Limiter，既浪费内存又失去复用意义；应按用户 ID 或 IP 做 key 缓存，用 sync.Map 或分片 map

如果你真需要漏桶行为（比如日志批量上报要严格匀速），优先用 rate.Limiter.ReserveN() 查剩余等待时间，它已接近漏桶语义；自己实现时，务必处理时钟回拨和原子状态更新。

分布式场景下，Redis ZSET + Lua 是唯一靠谱方案

单机滑动窗口在多实例部署时直接失效：各机器本地时间不同步，哪怕误差仅 200ms，60 秒窗口就可能错开 1/3。用 INCR + EXPIRE 更糟——两个命令非原子，断连时 key 永久存在（漏限）或永久丢失（误限），且根本无法统计“过去 N 秒”这个动态范围。

必须用 Redis ZSET：

ZADD rate:uid ，score 用毫秒级时间戳，member 用唯一标识（如 traceID）
Lua 脚本内必须调 redis.call("TIME") 获取服务端时间，拼成毫秒级时间戳：seconds * 1000 + microseconds / 1000
三步原子执行：先 ZCOUNT key (now_ms - window_ms) +inf 统计，再判断是否 ≤ max，最后 ZADD 新请求 + ZREMRANGEBYSCORE 清理过期项
Go 层别传时间戳进去，Lua 里算；也别用 pipeline 模拟原子性，网络抖动会让结果不可靠

最容易被忽略的点：Redis 服务端必须开启 NTP（推荐 chrony），且时钟误差压到 100ms 内；否则哪怕脚本写得再完美，时间基准一歪，整个窗口就垮了。