4. 连接池耗尽场景一：业务流量突增，连接数达到 MaxOpenConns 上限

在 Go 的 database/sql 标准库中，连接池通过 sql.DB 对象管理。当业务流量在短时间内急剧上升，而连接池的 MaxOpenConns 配置不足以承载并发请求时，所有可用连接被迅速占满，后续请求被迫排队等待空闲连接释放。这是连接池耗尽最典型、最直接的触发场景。

4.1 场景特征与故障表现

当连接数达到 MaxOpenConns 上限时，系统会表现出以下可观测特征：

4.2 故障演进过程

从流量突增到系统雪崩，通常经历以下四个阶段：

1. 连接抢占阶段：流量上升，所有 MaxOpenConns 连接被快速分配，InUse 指标逼近上限。
2. 排队等待阶段：新请求无法获取连接，进入 sql.DB 内部等待队列，WaitCount 开始增长。
3. 超时失败阶段：等待超过 connMaxLifetime 或 connMaxIdleTime 的隐式约束，或应用层设置了 context.WithTimeout，请求开始超时返回错误。
4. 雪崩放大阶段：超时请求在上游被重试，产生更多并发连接请求，形成正反馈循环，最终导致系统不可用。

4.3 连接池状态与流量突增的关系

下面的 SVG 图展示了正常状态与连接池耗尽状态下，连接池内部结构的对比：

4.4 流量突增的典型触发源

在实际生产环境中，以下场景最容易引发连接池耗尽：

• 秒杀/大促活动：瞬时 QPS 暴涨数倍到数十倍，连接池配置未同步扩容。
• 上游重试风暴：网关或客户端配置了激进重试策略，一次失败触发多次重试，放大并发量。
• 慢查询阻塞连接：少量慢查询长时间占用连接，导致连接周转率下降，有效连接数减少。
• 连接泄漏：代码中未正确调用 rows.Close() 或 stmt.Close()，连接无法归还池中。
• 突发定时任务：大量定时任务在同一时刻触发数据库操作，形成并发尖峰。

4.5 快速验证与定位方法

当怀疑连接池耗尽时，按以下步骤快速验证：

1. 采集连接池指标：在 Go 服务中暴露 /debug/vars 或 Prometheus 指标，获取 sql.DB.Stats()。
2. 检查 InUse 与 MaxOpenConns：如果 InUse == MaxOpenConns 持续超过 5 秒，确认连接池已满。
3. 检查 WaitCount 增长率：计算每秒新增等待数，判断排队压力。
4. 检查 WaitDuration：平均等待时间超过 100ms 时，应用层已明显受影响。
5. 确认数据库端连接数：执行 SELECT count(*) FROM pg_stat_activity WHERE state = 'active'; 确认 PostgreSQL 端连接数。

func poolStatsHandler(w http.ResponseWriter, r *http.Request) {
    stats := db.Stats()
    fmt.Fprintf(w, "MaxOpenConns: %d\n", stats.MaxOpenConns)
    fmt.Fprintf(w, "OpenConnections: %d\n", stats.OpenConnections)
    fmt.Fprintf(w, "InUse: %d\n", stats.InUse)
    fmt.Fprintf(w, "Idle: %d\n", stats.Idle)
    fmt.Fprintf(w, "WaitCount: %d\n", stats.WaitCount)
    fmt.Fprintf(w, "WaitDuration: %s\n", stats.WaitDuration)
}

4.6 连接池耗尽时的请求生命周期

下面的 SVG 图展示了一个请求在连接池耗尽时的完整生命周期，从请求到达直到超时失败：

4.7 核心参数与配置建议

针对流量突增场景，连接池参数配置需要平衡资源利用与抗压能力：