如何在 Go 中实现一个基于令牌桶的毫秒级限流器-Golang-PHP中文网

time.Now().UnixNano() 是毫秒级限流的关键起点，因为它提供纳秒级精度的绝对时间戳，除以 1e6 后可得稳定、无浮点误差、无系统调度依赖的毫秒整数时间轴，确保令牌填充计算严格线性、边界精准、零漂移。

为什么 `time.Now().UnixNano()` 是毫秒级限流的关键起点

go 标准库的 time.ticker 最小精度受系统调度影响，通常达不到稳定毫秒级；而限流器必须精确知道“此刻距上次请求过了多少毫秒”，否则令牌填充逻辑会漂移。直接用 time.now().unixnano() 获取纳秒时间戳，再除以 1e6 转为毫秒整数，是唯一可控、无依赖、零额外开销的方式。

注意：不能用 time.Since() 或 time.Sub() 后四舍五入——它们返回 time.Duration，底层仍是纳秒，但做毫秒对齐时若用浮点或非截断转换（如 int64(d / time.Millisecond)），在边界时刻可能多算或少算 1 毫秒，导致令牌数突变。

正确做法：ms := time.Now().UnixNano() / 1e6
错误示例：int64(time.Since(last).Seconds()*1000)（浮点误差 + 时区/闰秒干扰）
所有时间比较和填充计算，必须基于同一套毫秒整数时间轴，而非 time.Time 对象本身

`atomic.LoadInt64` 和 `atomic.CompareAndSwapInt64` 必须成对用于令牌计数

令牌桶的核心状态只有一个：tokens 当前剩余令牌数。它被多个 goroutine 并发读写，但绝不能用 sync.Mutex——锁会成为性能瓶颈，尤其在高 QPS 场景下，简单加锁会使 P99 延迟飙升数毫秒。

用原子操作实现无锁更新：每次 Allow() 先 atomic.LoadInt64(&t.tokens) 读当前值，再根据毫秒差计算应填充量，得到期望新值；最后用 atomic.CompareAndSwapInt64(&t.tokens, old, new) 尝试提交。失败则重试（通常 1–2 次即成功）。

填充公式：newTokens = min(capacity, oldTokens + (nowMs - lastMs) * ratePerMs)，其中 ratePerMs 是每毫秒新增令牌数（如 100 QPS → 0.1，需用定点乘法避免浮点）
务必在 CAS 前完成全部计算，且不修改任何共享状态，否则重试时逻辑错乱
不要用 atomic.AddInt64 直接加——它无法判断是否超出容量上限，会导致令牌溢出

如何处理 `ratePerMs` 小于 1 的情况（比如 50 QPS）

50 QPS 意味着每 20 毫秒才允许一个请求，即 ratePerMs = 0.05。Go 没有原生定点数，用 float64 会累积误差，几万次运算后偏差可达 ±1 令牌。可靠解法是把时间单位放大：不再按“每毫秒”，而是按“每 baseMs 毫秒”计算。

例如设 baseMs = 20，则 50 QPS 变成“每 20ms 补 1 令牌”，此时所有计算全为整数：fillCount = (nowMs - lastMs) / baseMs，再乘以每周期令牌数（=1）。这样既无浮点误差，又保持毫秒级响应（因为 nowMs 仍是实时毫秒）。

使用Go语言搭建家庭相册系统-相关课件

下载

通用规则：选 baseMs = 1000 / gcd(1000, qps)，比如 75 QPS → gcd(1000,75)=25 → baseMs = 40，即每 40ms 补 3 令牌
实际存储两个字段：baseMs int64 和 tokensPerBase int64，填充时用整数除法
注意：(nowMs - lastMs) / baseMs 是向下取整，天然符合“未满一个周期不补”的语义

为什么不能把 `lastMs` 和 `tokens` 合并进一次 CAS

有人试图用一个 struct{ lastMs, tokens int64 } 加 atomic.CompareAndSwapPointer 来“原子更新两个值”，这看似简洁，实则引入严重竞争漏洞：当 A goroutine 读到 lastMs=1000, tokens=5，B 同时将 lastMs 更新为 1005 并填充了令牌，A 在计算时仍用 1000 做差值，导致多算了 5ms 的令牌，造成漏放行。

正确做法是只对 tokens 做 CAS，而 lastMs 用 atomic.LoadInt64 单独读——因为 lastMs 仅用于计算填充量，即使读到稍旧的值，最多少填几个令牌（安全降级），绝不会多放。