Gin框架滑动窗口流量控制机制-Golang-PHP中文网

滑动窗口不能直接用time.now()算时间差，因为gin并发处理时多goroutine调用time.now().unixmilli()无法对齐窗口起点、区分同一秒内不同区间请求，且无分桶加权就不是真滑动窗口；必须用truncate对齐桶起始时间，按用户维度隔离状态，用sync.rwmutex+[]*atomic.int64保证并发安全。

gin框架滑动窗口流量控制机制

滑动窗口为什么不能直接用 time.Now() 算时间差

因为 Gin 是并发处理请求的，多个 goroutine 同时调用 time.Now().UnixMilli() 并做减法，既无法对齐窗口起点，也无法区分「同一秒内不同 100ms 区间」的请求分布。更关键的是：没有分桶，就谈不上加权；没加权，就不是滑动窗口——只是个带时间戳的计数器，和固定窗口没本质区别。

典型错误现象：rate limit triggers too early or too late、burst traffic bypasses limit、高并发下 data race 报错（尤其用了全局 map 或 sync.Map 存时间戳）。

必须用 time.Now().Truncate(shardDur) 对齐每个桶的起始时间点，否则同一窗口内请求可能被散落到相邻桶
桶的 key 不该是原始时间戳（会导致频繁创建/删除），而应是截断后的时间点 + 用户维度标识（如 ip:127.0.0.1 或 user_id:1001）
别把桶数组存在 c.Request.Context() 里——它随请求生命周期销毁，限流状态必须跨请求持久

SlidingWindow 结构体怎么定义才安全

核心是隔离维度、避免锁争抢、防止溢出。推荐用 sync.RWMutex + 固定长度 []*atomic.Int64，而不是 sync.Map（不支持原子增减）或普通 map[time.Time]int64（并发写 panic）。

示例关键字段：

type SlidingWindow struct {
    mu       sync.RWMutex
    shards   []*atomic.Int64
    shardDur time.Duration // 如 100ms
    window   time.Duration // 如 1s
    maxReq   int64         // 理论上限，非硬阈值
}

shards 数量建议 10～100：太少（如 2）导致窗口跳变剧烈；太多（如 1000）增加内存与锁开销
每个 *atomic.Int64 用于单桶计数，避免 int 溢出（高 QPS 下 1 秒内可能超万次请求）
maxReq 是「窗口总容量 × 分桶数」的参考值，实际放行量 = 各桶当前值 × 权重之和，所以真实通过量可能略高于它——这是滑动窗口的正常行为，不是 bug