本文详解如何在 go 中安全、稳定、高性能地实现约 1000 qps 的 http 请求调度，涵盖连接复用调优、goroutine 协作模型设计、速率控制策略及错误退避机制。
本文详解如何在 go 中安全、稳定、高性能地实现约 1000 qps 的 http 请求调度，涵盖连接复用调优、goroutine 协作模型设计、速率控制策略及错误退避机制。
要稳定支撑每秒 1000 次 HTTP 请求（1000 QPS），关键不在于“盲目启动 1000 个 goroutine 并发执行”，而在于资源可控、连接复用、节流精准、失败可恢复。你当前的代码存在几个典型瓶颈：
- 每轮 for i := 0; i < 100 启动新 goroutine，但未限制总并发数，易触发系统级连接耗尽（如 ulimit -n 不足）；
- time.Sleep(waitTime - time.Now().Sub(now)) 依赖时间精度，易因调度延迟导致请求堆积或超限；
- http.DefaultClient 虽默认启用 Keep-Alive，但若未显式配置 MaxIdleConnsPerHost，高并发下可能创建过多空闲连接，甚至被服务端拒绝（如 429 或连接重置）；
- ID 生成无同步保护，虽靠闭包捕获避免竞争，但逻辑耦合度高、扩展性差，且无法保证严格单调连续。
✅ 推荐方案：固定 Worker 池 + 精确速率控制 + 连接池调优
1. 优化 HTTP 客户端连接复用
client := &http.Client{
Transport: &http.Transport{
MaxIdleConns: 2000, // 全局最大空闲连接数
MaxIdleConnsPerHost: 2000, // 每 host 最大空闲连接数（必须设！）
IdleConnTimeout: 30 * time.Second,
// 可选：禁用 keep-alive 仅当服务端明确不支持时启用
// DisableKeepAlives: true,
},
}⚠️ 注意：MaxIdleConnsPerHost 默认为 2，远低于 1000 QPS 所需——若不调大，大量请求将阻塞在连接获取阶段，甚至触发 net/http: request canceled (Client.Timeout exceeded while awaiting headers)。
2. 使用固定 Worker 数 + Token Bucket 控制 QPS
相比“每秒启动 1000 goroutine”，更健壮的方式是启动固定数量 worker（如 50–100），通过 channel 或 ticker 实现全局速率整形：
func startWorkers(client *http.Client, totalQPS int, quit <-chan struct{}) {
rateLimiter := time.Tick(time.Second / time.Duration(totalQPS))
var lastID uint64 = 1234567890
for i := 0; i < 50; i++ { // 50 个 worker 足够平滑分发 1000 QPS
go func() {
for {
select {
case <-quit:
return
case <-rateLimiter:
id := atomic.AddUint64(&lastID, 1)
if err := scrape(client, id); err != nil {
handleScrapeError(err, &lastID)
}
}
}
}()
}
}3. 错误处理：智能退避而非 panic
遇到 429 Too Many Requests 时，应暂停并指数退避，而非 panic 终止整个程序：
func handleScrapeError(err error, lastID *uint64) {
if strings.Contains(strings.TrimSpace(err.Error()), "Too Many request to server") {
log.Printf("Rate limited: backing off...")
time.Sleep(100 * time.Millisecond) // 初始退避
atomic.AddUint64(lastID, ^uint64(0)) // 回退 ID（可选，避免跳号）
return
}
// 其他错误（网络超时、DB 写入失败等）按需重试或记录
}4. 系统层准备：调整 ulimit 与内核参数
Ubuntu 下务必检查并提升资源限制：
# 查看当前限制 ulimit -n # 临时提升（建议 ≥ 4096） sudo ulimit -n 8192 # 永久生效：编辑 /etc/security/limits.conf # * soft nofile 8192 # * hard nofile 8192
同时确认内核 net.core.somaxconn 和 net.ipv4.ip_local_port_range 足够支撑高频短连接。
? 总结最佳实践
- ✅ 连接池必调优：MaxIdleConnsPerHost >= QPS（推荐设为 1.5× QPS）；
- ✅ Worker 数量宜少不宜多：50–100 个 goroutine + ticker 控制，比 1000 个 goroutine 更省资源、更易监控；
- ✅ ID 生成用 atomic：安全、无锁、高性能，替代闭包捕获+手动递增；
- ✅ 429 处理用退避，非 panic：保障服务韧性，避免雪崩；
- ✅ 压测验证：上线前用 wrk 或 vegeta 模拟 1000 QPS，观察 netstat -an | grep :PORT | wc -l 和 GC 压力。
最终目标不是“跑满 1000 QPS”，而是“在服务端限流阈值内，长期稳定、低延迟、零丢请求地完成数据采集”——这才是生产级 HTTP 批量调用的真正方法论。
