Go 中高效实现每秒 1000 次 HTTP 请求的并发控制与连接优化

本文详解如何在 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,
        // 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 批量调用的真正方法论。