凌晨两点的并发度：动态优化调整不是许愿池

凌晨两点，告警群炸了。订单服务 P99 从 120ms 飙到 2.3s，值班同学手一抖，把线程池从 200 调到 500。你猜怎么着？更慢了。为什么？因为数据库连接池只有 50，线程全堵在拿连接上。这个场景我见过不止一次。大家一着急就想“动态优化调整”一下，仿佛加个自动调参的开关，系统就能自己回血。真不是。

动态优化调整，拆开看就两件事：动态是根据运行时信号改策略，优化是朝着一个明确目标拧杠杆。它不负责变出资源，也不负责替你找瓶颈。它更像开车握方向盘——你得看路、看后视镜、看车速，手上不停微调。但方向盘打猛了，车会画龙。

先把“动态”和“优化”拆开看

很多人把动态优化调整理解成“系统自己调参数”。这只说对一半。真正难的是反馈回路：观测信号、判断偏差、执行动作、验证效果。四个环节缺一个，动态就变成瞎动。

观测信号得有代表性。CPU 高不一定代表过载，可能是 GC；QPS 高不一定代表压力大，可能请求都很轻。判断偏差得有目标函数，比如“在 P99 不超过 300ms 的前提下把吞吐顶上去”。执行动作得有护栏，上下限、步长、冷却时间。验证效果得有对比窗口，不然你调完都不知道是变好了还是运气好。

这里有个容易忽略的点：反馈有滞后。你十秒前调的并发度，可能三十秒后才反映到延迟上。指标又是分钟级聚合。拿慢信号去驱动快动作，系统不震荡才怪。空调压缩机不会每秒开关，它有个死区。动态优化调整也需要死区、滞回、冷却期。别把反馈回路调成洗衣机。

微服务自适应并发度动态调整反馈回路示意图

一次并发度调整的翻车现场

一次并发度调整的翻车现场

去年我参与一个订单服务，流量从日常 800 QPS 冲到 3000。团队想上自适应并发度：延迟高了就降并发，延迟低了就慢慢加。听着很合理，对吧？

一开始用 Little's law 估：并发 ≈ 吞吐 × 延迟。2000 QPS、平均延迟 50ms，理论并发 100。可线上 P99 是 800ms，长尾把平均值骗了。我们拿 P95 做反馈信号，阈值设 300ms，调整周期 10 秒，步长 20%。结果流量一抖，并发度从 120 跳到 180，延迟没降，数据库连接池先爆了。为什么？因为瓶颈在连接池，不在应用线程。你把门口拓宽，检票口还是那么窄，人只会堵得更凶。

后来我们把约束链画出来：网关 → 应用线程 → 数据库连接池 → 慢 SQL。连接池上限 50，慢 SQL 占了三成。先把连接池加到 120，并发度上限锁在 180，步长降到 5%，冷却时间 30 秒。系统才稳住。你看，动态优化调整动手之前不是调，是找约束边界。边界没找到，调参就是许愿。

别把反馈回路调成洗衣机

震荡是动态调整的常见病。增益太大，系统在“加并发”和“降并发”之间来回横跳，指标像心电图。你以为是算法不行，其实是节奏不对。调整频率高于指标可信频率，等于拿噪声当信号。

我一般加三个土办法。先给护栏：参数有硬上下限，单次调整不超过 10%，连续调整要等冷却。再加滞回：延迟降到阈值以下 20% 才允许加，避免在阈值线上反复摩擦。然后是影子模式：新策略先只记录不执行，拿历史流量回放，看看它会不会把系统带沟里。别嫌土，管用。

还有个误区：以为动态优化调整能解决容量不足。不能。资源不够的时候，动态调整只能决定谁先排队，不能变出机器。另一个误区是只看系统指标，不看业务指标。延迟降了，订单成功率掉了，这算优化吗？不算。目标函数得把业务结果写进去。

横向看，缓存 TTL 动态调整也是同一个回路。命中率低了就延长 TTL，写入压力大了就缩短 TTL。但 TTL 抖得太频繁，缓存命中率会跟着抖，数据库更难受。所以还是那三样：护栏、滞回、回滚开关。

缓存TTL动态调整命中率监控曲线图

落地时我盯的三个土办法

落地时我盯的三个土办法

先画约束链。别一上来就写控制器。把请求路径上的资源挨个列出来，找到当前瓶颈。瓶颈会漂移，所以约束链要定期复看。再就是给调整加护栏。参数上下限、步长、冷却、回滚，一个都不能少。还有留观测窗口。调整前后至少各看一个完整业务周期，别拿五分钟的数据下结论。

说实话，我当时也想过上强化学习。忍住了。不是它不行，是团队还没能力维护一个黑盒控制器。动态优化调整的复杂度不在算法，在可解释性和可运维性。出了事，你得能说清楚为什么调、调了多少、怎么退。

凌晨那场故障，后来没用什么高级算法。连接池加到 120，并发度上限锁 180，先稳住，再慢慢放开。系统不是被“智能”救回来的，是被边界和护栏救回来的。动态优化调整是个好工具，但它不是许愿池。你得先知道自己在调什么，再谈动态。