服务扛不住并发时，先校准连接池和超时链路

服务扛不住并发时先校准连接池和超时链路连接池大小不能简单等同于入口并发。数据库连接过少会排队过多也会压垮数据库合适数值取决于查询耗时、数据库容量和其他服务的连接使用情况。先从监控中看等待时间、打开连接数和慢查询再调整配置。请求超时应从入口向下游传递数据库查询使用QueryContext外部调用也使用同一请求上下文。限流与熔断分别限制进入流量和隔离持续失败的下游不能互相替代。ctx, cancel : context.WithTimeout(parent, timeout) defer cancel() rows, err : db.QueryContext(ctx, query, arg)过载时先保护核心操作拒绝非必要功能、限制请求大小、设置在途上限并返回可操作的错误。验证要包括数据库变慢、连接耗尽、客户端取消和下游持续失败。所有压测结论都应附带硬件、连接配置、数据规模与持续时间。连接池是等待队列不是扩容按钮连接池的上限增大后应用侧等待可能下降但数据库会同时承担更多活动查询、锁竞争和内存占用。尤其是慢查询存在时更多连接只会让阻塞扩散。调参前先确认查询是否有合适索引、事务是否过长、连接是否被正确归还否则很难判断瓶颈到底在应用还是数据库。从小范围配置开始观察连接获取等待、数据库执行耗时和错误类型的变化。不要只看 HTTP 平均耗时少量请求长时间占用连接时分位延迟和等待队列通常更早暴露问题。连接池还需要考虑同一个数据库被其他服务共享的总连接预算。超时要留出收尾空间入口设置了超时不代表下游会自动停止。每次查询、RPC 和重试都要使用派生的ctx并给上游响应预留一点收尾时间。反例是下游超时设置得比入口更长客户端已经断开数据库仍在执行昂贵查询。验证可通过可控地延迟查询或限制可用连接来完成检查调用是否在期限内结束、rows是否被关闭、连接数是否回落以及服务恢复后是否能立即处理新请求。持续失败的下游还应触发熔断或降级避免每个请求重复做无效尝试。3. 重试要避开已经拥堵的通道连接等待或数据库超时时立即重试通常只会再占一个位置。只有网络短断、明确的可重试状态才值得在有限次数内重试每次等待应可被取消并带一点退避避免多个请求在同一时刻重新冲入。对写操作还要先确认幂等性否则超时后的第二次请求可能写出两份数据。监控里把首次失败和重试后的结果分开看。若成功率看起来很好、但大部分请求都依赖重试用户实际体验仍可能很差。关闭重试后跑一次对照压测能更清楚地看到它是在掩盖偶发抖动还是在放大数据库的持续故障。4. 查询生命周期要有统一的收尾数据库调用结束后rows、事务和临时计时器都要按同一规则释放。异常路径最容易漏掉扫描中返回、上下文取消、事务提交失败任何一个分支都不应把连接留给池子等待超时回收。把获取、使用和释放放在相近位置评审时更容易沿着资源生命周期检查。线上出现池耗尽时先看在途查询的年龄和来源而不是立刻把上限调大。若很多连接停在同一条语句或同一个接口问题通常在调用链或查询本身。用慢查询和连接等待记录把两者关联起来修复才能落到具体位置。