Go 高并发实战:从运行时到生产排障的 6 期路线
Rainy
雨落无声,代码成诗 —— 致力于技术与艺术的极致平衡
4 MIN READ•... VIEWS
目标不是背 API,而是建立一套能设计容量、约束资源、证明正确性并处理线上事故的并发工程方法。
这个系列围绕同一个“高扇出聚合服务”逐期演进:入口接收请求,并发访问数据库、缓存和 RPC,最后聚合结果。每一期都会保留可复现实验、错误版本、修复版本和验收指标。

这张由 ImageGen 生成的系列概念图把高并发抽象成一条受控数据流:左侧大量青色任务先进入有界队列,中间由少量执行核心调度,右侧连接多个下游节点;少量橙色信号表示被监控和限制的过载,而不是任其扩散成雪崩。
系列地图
| 期数 | 主题 | 核心问题 | 实战产物 |
|---|---|---|---|
| Go-1 | 运行时与容量模型 | goroutine 如何调度,并发上限怎么算 | 调度实验、Little's Law 容量表 |
| Go-2 | 结构化并发 | goroutine 如何创建、取消、回收 | fan-out/fan-in、worker pool |
| Go-3 | 生产服务 | HTTP、RPC、数据库如何统一 deadline | 有超时和优雅停机的聚合 API |
| Go-4 | 背压与系统韧性 | 过载时如何拒绝、隔离和恢复 | 限流、bulkhead、重试预算 |
| Go-5 | 共享状态与正确性 | 锁、atomic、channel 怎么选 | 竞态修复、分片与并发测试 |
| Go-6 | 压测与线上排障 | 如何从指标走到 profile 和代码 | pprof/trace/race 故障实验 |
贯穿全系列的服务目标
假设系统入口目标为 10,000 RPS,每请求扇出 3 个下游调用,下游平均 20 ms、P99 200 ms。我们不把“高并发”定义成单次峰值,而用以下验收标准:
- 容量内 P99 满足 SLO,吞吐随负载稳定增长;
- 超过容量时快速返回
429/503,已接纳请求不雪崩; - goroutine、队列、内存、连接和下游 in-flight 都有硬上限;
- 客户端断开或 deadline 到期后,子任务能停止并释放许可;
- 流量恢复后,资源和延迟能回到基线;
- 每一种故障都能从指标定位到 profile、栈或 trace 证据。
最终实战架构
这不是“每个请求开三个 goroutine”的演示,而是三层资源模型:网关控制到达速率,应用准入控制在途请求,依赖 bulkhead/连接池控制真实稀缺资源。Context 将 deadline 从入口传播到所有分支,结构化并发保证 handler 返回前子任务已结束或收到取消。
故障时按业务重要性处理:required DB 失败返回明确错误,optional recommendation 可降级;过载拒绝与依赖失败分别计数。Go-1~Go-6 会逐步实现图中的每条边,并说明如何用 pprof/trace 证明它按设计工作。
学习方式
每一期建议按“基线 → 注入故障 → 保存证据 → 修复 → 再压测”完成。不要只复制最终代码:高并发问题最重要的能力,是能解释错误版本为什么在低流量正常、在压力下失效。
从 Go-1:运行时、调度器与容量模型 开始。