如何使用Golang在高并发场景下处理大量请求_Golang高并发请求与负载控制

直接用 goroutine 处理大量请求会因失控并发导致内存耗尽、调度风暴、OOM 等问题；必须用信号量（如 semaphore.NewWeighted）在业务执行层限流，并配合 context、超时、连接层防护与 panic 恢复保障稳定性。

为什么直接用 goroutine 处理大量请求会崩

不加控制地为每个请求起 goroutine，在 QPS 上千时极易耗尽内存或触发调度风暴。Go 运行时无法优雅处理数万级并发 goroutine 的抢占与栈分配，常见现象是 RSS 暴涨、GC 频繁停顿、runtime: failed to create new OS Thread 报错，甚至进程被 OOM killer 杀掉。

关键不是“能不能并发”，而是“谁来决定并发多少”——必须把并发权收归可控的调度层，而非放任 http handler 自由 spawn。

• 默认 HTTP server 每个连接一个 goroutine，但连接数 ≠ 有效请求数；TCP 连接可能空闲、慢速、恶意保活
• http.Server.ReadTimeout 和 WriteTimeout 只管单次读写，不管整个请求生命周期
• 真正需要限流的是业务逻辑执行环节，比如调用下游 DB 或 rpc，而非 Accept 阶段

用 semaphore 控制并发执行数（最简可靠方案）

用 golang.org/x/sync/semaphore 实现信号量限流，比 channel 手动计数更轻量、无泄漏风险，且支持带上下文的 acquire。

var sem = semaphore.NewWeighted(100) // 允许最多 100 个并发执行 <p>func handler(w http.ResponseWriter, r *http.Request) { ctx := r.Context() if err := sem.Acquire(ctx, 1); err != nil { http.Error(w, "too many requests", http.StatusTooManyRequests) return } defer sem.Release(1)</p><pre class="brush:php;toolbar:false;">// 这里放真实业务逻辑：DB 查询、RPC 调用等 result, err := doHeavyWork(ctx) if err != nil {     http.Error(w, err.Error(), http.StatusInternalServerError)     return } json.NewEncoder(w).Encode(result)

}

立即学习“go语言免费学习笔记（深入）”；

• 数值 100 不是拍脑袋定的，应基于压测：观察 P95 响应时间拐点 + GC pause 稳定区间
• 务必用 ctx 传入 Acquire，否则超时请求仍会卡住信号量
• 不要在 Acquire 前做任何重操作（如解析大 body），否则限流失效

结合 http.Server 的 ConnContext 和 IdleTimeout 做连接层防护

信号量管业务执行，而连接本身需防慢连接、长连接堆积。靠 http.Server 原生字段就能筛掉大部分无效压力。

srv := &http.Server{     Addr:         ":8080",     Handler:      mux,     ReadTimeout:  5 * time.Second,     WriteTimeout: 10 * time.Second,     IdleTimeout:  30 * time.Second,     ConnContext: func(ctx context.Context, c net.Conn) context.Context {         // 可在此注入连接级 traceID 或限流标记         return context.WithValue(ctx, connKey, c.RemoteAddr().String())     }, }

• IdleTimeout 是关键：防止客户端建连后不发数据，长期占着 fd 和 goroutine
• ReadTimeout 必须设，否则 POST 大 body 上传卡住时，goroutine 一直挂起
• 避免在 ConnContext 中做同步阻塞操作（如 DB 查询），它运行在 accept goroutine 中

别忽略 panic 恢复和 context 取消传播

高并发下 panic 更容易引发雪崩，而没检查 ctx.Err() 会导致 goroutine 泄漏——这两点在线上事故中占比极高。

• HTTP handler 必须包一层 defer func() { if r := recover(); r != nil { log.printf("panic: %v", r) } }()
• 所有下游调用（db.QueryContext、http.Do、time.Sleep）都必须传入原始 r.Context()，不能用 context.background()
• 自定义中间件里若用 context.WithTimeout，记得用 defer cancel()，否则 timeout 后 context 仍存活

真正难的不是写限流代码，而是让每个函数、每条调用链都尊重 context 生命周期，并在 panic 后不破坏信号量状态——这需要持续 code review 和故障演练验证。