直接用 time.Sleep 控制速率会出问题，因其只停顿不考虑调度延迟和处理耗时，导致吞吐波动、偶发超速、并发失控；应使用 rate.Limiter 实现基于时间窗口的令牌桶限流。
为什么直接用 time.Sleep 控制速率会出问题
批量导入时加“每秒最多 N 条”的限制，很多人第一反应是循环里塞 time.Sleep。但实际跑起来常发现：吞吐忽高忽低、偶发超速、并发下速率完全失控。根本原因是 time.Sleep 只管“停顿”，不管“调度延迟”和“处理耗时”。比如某条数据解析花了 800ms，再睡 200ms，这一轮就用了整整 1s；下一轮如果解析只花 50ms，那剩下的 950ms 全白等——速率变成锯齿状，且无法收敛。
真正可控的速率控制必须基于“固定时间窗口内的完成数”，而不是“每次执行后等待”。推荐用 golang.org/x/time/rate 的 Limiter，它内部维护一个“令牌桶”，支持平滑、可并发、带预热能力的限流。
- 初始化时指定
rate.Limit(100)表示每秒最多 100 个令牌（即最多 100 次操作） - 每次导入前调用
limiter.Wait(ctx)，它会自动计算需等待多久才能拿到下一个令牌 - 如果批量任务本身是并发执行的（比如起 10 个 goroutine），
Limiter是并发安全的，无需额外锁 - 注意别用
Allow()做非阻塞判断——它不保证后续立刻能执行，容易绕过限流
如何把 Limiter 和批量导入逻辑真正串起来
关键不是“在循环里加限流”，而是让限流成为数据流动的节拍器。典型错误是先读完所有数据再限流，导致内存暴涨；或者把整个批次当一个单元去限流，失去“速率上报”的意义。
正确做法是：边拉取、边限流、边导入，并在每次成功提交后主动上报当前速率。示例结构如下：
// 初始化限流器：每秒最多 50 条
limiter := rate.NewLimiter(rate.Limit(50), 1)
<p>// 启动一个 goroutine 定期打印当前速率（可选）
go func() {
ticker := time.NewTicker(1 * time.Second)
defer ticker.Stop()
for range ticker.C {
fmt.Printf("current rps: %.1f\n", limiter.Limit())
}
}()</p><p>for _, item := range items {
if err := limiter.Wait(ctx); err != nil {
log.Printf("rate limit wait failed: %v", err)
continue
}</p><pre class="brush:php;toolbar:false;">if err := importOne(item); err != nil {
log.Printf("import failed for %v: %v", item.ID, err)
continue
}
// 上报：这里可以发 metrics、写日志、或更新 prometheus counter
reportImportSuccess(item.ID)}
- 务必把
limiter.Wait(ctx)放在importOne调用之前，否则限流失效 - 如果
importOne本身耗时波动大（如含网络 I/O），建议对它也设超时，避免单次卡住整个限流节奏 - 上报逻辑不要阻塞主流程，尤其不能放在
limiter.Wait前面，否则速率统计失真
并发导入时怎么避免速率被“撑爆”
如果起多个 goroutine 并行导入，又共用同一个 Limiter，看起来没问题——但实际中常出现“前几秒狂打 200+ QPS，之后骤降到 0”。这是因为 Limiter 允许突发（burst 参数），默认 burst=1，但如果你初始化时写了 rate.NewLimiter(rate.Limit(50), 10)，它就能一次性放出 10 个令牌，配合多个 goroutine 就可能瞬间打满。
- burst 值建议设为 1，除非你明确需要容忍短时突发（例如允许最多 1 次“双倍速”导入）
- 更稳妥的做法是：用一个 goroutine 负责从 channel 拉数据 + 限流，其他 goroutine 只负责消费已限流过的任务
- 例如：
for item := range rateLimitedChan { go worker(item) }，其中rateLimitedChan由单独的“限流协程”按节奏推入 - 避免在多个地方重复调用
Wait，比如每个 worker 都自己 Wait——这会让限流器误判为多个独立消费者，实际速率翻倍
速率上报本身要不要限流
上报动作（比如调用 Prometheus counter.Inc() 或写 Kafka）如果太频繁，可能反成瓶颈。但对速率指标来说，“每条都报”和“每秒聚合报一次”语义不同：前者反映真实请求毛细粒度，后者只反映宏观趋势。
实践中建议分层处理：
- 核心业务逻辑里只做轻量标记，例如原子计数器
atomic.AddInt64(&successCount, 1) - 另起一个 goroutine，每 100ms 读一次计数器、算差值、发一次聚合指标（如 “last_100ms_success: 4”）
- 如果上报通道（如 HTTP client）可能阻塞，一定要设超时，失败时记录 warn 日志但不 panic
- 切忌在
limiter.Wait后立刻同步发网络请求——这会让限流器以为“我已经放行了”，结果上报卡住，后续请求全堵在 Wait 上
真正难的不是实现速率控制，而是让限流、处理、上报三者节奏对齐。错位一毫秒，速率曲线就抖一下；错位一秒钟，监控图上就是一根刺。所以别只测“平均速率”，一定压测首尾 5% 的 P95 延迟分布。
