Agent Platform线上超时故障复盘：数据库连接池与MDL锁实战解析

开发 Agent Platform踩了一次真实的线上超时故障1. 项目背景Agent Platform 要解决什么问题先说清楚我做的这个东西是什么。Agent Platform 是一个面向多智能体场景的任务编排与运行平台核心是把大模型调用、工具调用、外部 API 对接、人工审批这些环节统一编排成可配置、可监控、可重试的自动化流程。它服务的对象主要是内部业务团队比如客服自动应答、报表生成、工单分类这些场景都有对应的 Agent 定义在平台上运行。平台的整体架构并不算复杂上层是一套管理控制台负责 Agent 的定义、流程配置、权限管理和运行日志查看中间是调度核心负责接收任务、拆解步骤、分发执行底层接了大模型服务、内部业务系统的 API、消息队列和一个关系型数据库。每个 Agent 任务在执行过程中会按照编排好的 DAG有向无环图逐步推进每个节点对应一次具体的操作。比如一个“客服自动回复”的 Agent流程大概是接收用户消息 → 调用大模型理解意图 → 查内部订单系统 → 大模型生成回复 → 发送消息。当初设计这个平台的时候我其实对并发预估是比较保守的因为内部系统嘛量级不会特别大峰值也就每秒几十个任务。但正是因为抱着这种“内部系统不会出事”的心态后续才踩了一个让我印象极其深刻的线上故障——超时风暴。这个故障本身的根因并不复杂但排查过程和背后的原理梳理让我觉得非常值得记录下来。先说结论这次故障不是大模型接口变慢也不是代码里有死循环而是数据库里的一次 DDL表结构变更引发了元数据锁累积最终拖垮了整个平台的连接池所有 Agent 任务全部卡在等待数据库连接上表现为大范围超时。这个故障排查链路比较长涉及数据库原理、连接池行为、线程模型和超时配置等多个环节我觉得是很典型的一线实战案例。适合看这篇文章的人正在做 Agent 平台或类似任务编排系统的后端开发遇到过线上超时但不知道从哪里下手排查的同学以及想把数据库连接池、锁机制这些底层原理真正串起来理解的工程师。2. 平台的运行链路与核心依赖2.1 一次 Agent 任务的完整执行链路要理解超时故障的影响范围得先搞清楚一次 Agent 任务在平台内部到底走了哪些环节。我简化一下整个链路方便下文说明问题定位的位置。一次任务从入口到结束大致经历以下步骤外部系统通过 HTTP 接口提交任务接口层接收请求后先向数据库写入一条任务记录。任务记录写入成功后调度器从数据库捞取待执行任务按照 Agent 定义好的 DAG 展开成多个执行步骤。每个步骤由执行器负责运行。执行器可能是调用大模型、请求内部业务 API也可能是执行一段脚本或者触发人工审批。每个步骤的执行状态和结果持续写回数据库前端控制台通过查询数据库实时展示进度。整个任务完成后平台会触发回调通知把最终结果返回给调用方。所以可以看到数据库在这个平台里的地位极其重要。任务元数据、执行状态、日志存储、调度任务表全都依赖数据库。一旦数据库变得不可用或者连接获取超时整个平台就会立刻陷入瘫痪。这次的故障就是一个典型的数据库侧问题引发的全局性超时。2.2 连接池系统的“血管”也是“瓶颈”平台后端使用的是 Java 技术栈数据库连接池用的是 HikariCP。连接池的作用类似于一个共享的“数据库连接仓库”多个线程不需要各自创建连接而是从池子里借、用完归还避免频繁建连的开销。HikariCP 的默认配置里有一个参数叫maximumPoolSize它决定了池子里最多可以有多少个连接。我当时的配置是 50也就是说整个应用实例最多只能同时占用 50 个数据库连接。这个数字对于一个内部平台来说理论上绰绰有余因为平时的数据库操作都是毫秒级完成的50 个连接足够支撑几百的 QPS。但问题恰恰出在这个“理论上”三个字上。一旦数据库侧出现任何异常导致连接的获取或者执行变慢50 个连接很快就会被全部占满后续所有需要数据库操作的请求都要排队等待获取连接。而 HikariCP 默认的连接获取超时时间是 30 秒也就是说排在后面的请求如果 30 秒内拿不到连接就会直接抛出异常。这次的故障过程就是某个凌晨执行了一次大表的 DDL 操作导致数据库出现锁等待所有涉及这张表的查询都开始变慢连接被一个接一个地占住不释放。不到两分钟50 个连接全部被占满整个平台的所有任务全部超时。这就是典型的“单点阻塞演变为全局故障”。注意连接池的 maximumPoolSize 不是越大越好。连接数过大反而会增加数据库的负载也不一定能提升吞吐。合理的做法是根据数据库的 max_connections 和应用的实际并发需求来综合设定这个后面细讲。2.3 超时配置每一层都可能有坑Agent Platform 里涉及超时的地方非常多而且每一层的超时配置如果不合理都会成为故障的放大器。我梳理了一下整个平台的超时链路大概有这几层HTTP 接口层接入层接收外部请求的超时时间我设置了 5 秒。任务调度层调度器从数据库捞取任务的轮询间隔和单次查询超时默认是 3 秒。执行器层每个节点执行大模型调用或外部 API 请求的超时时间设置的是 30 秒。数据库连接池连接获取超时 30 秒连接空闲超时 10 分钟。数据库驱动层Socket 读超时 5 秒连接超时 3 秒。正常情况下的链路响应应该是HTTP 请求接入后调度器快速从数据库拿到任务并分配执行执行器调用外部服务完成后回写状态。整个过程因为每个环节都有独立的超时控制互不影响。但故障发生时问题就变得很棘手数据库连接池满了之后新来的任务在获取连接时开始等待。由于连接获取超时是 30 秒这就导致大量线程被阻塞在连接获取阶段而这些被阻塞的线程又占用了后端 Tomcat 的线程池。Tomcat 线程池一旦耗尽新的 HTTP 请求直接进入等待队列最终接口层报超时。超时又引发了调用方的重试重试带来了更多的请求进一步加剧了连接池的争抢。这是一个典型的超时级联放大的过程。现在回头复盘这个故障的本质原因是 DDL 操作引起的数据库锁等待但让故障影响面扩大到整个平台的其实是超时配置和连接池行为之间缺少有效的“降级”和“熔断”机制。这让我后来在设计平台时养成了一个习惯宁可让单次请求快速失败也不要让请求全部阻塞在队列里。3. 故障发生与定位排查实录3.1 故障初现告警风暴与第一反应那天上午我正打算把 Agent Platform 的一个新版本发布到测试环境准备验证几个新加的 Agent 模板。结果消息群里接连弹出告警先是一波“接口响应时间超过 5 秒”的告警紧接着是“任务执行失败率超过 30%”的告警最后连“数据库连接池活跃连接数超过 80%”的告警都出来了。我当时的第一反应是某个 Agent 调用的大模型服务出了问题毕竟那是最常见的外部依赖。于是我先去看了大模型服务的调用日志和响应时间指标。结果发现大模型服务这段时间的响应时间完全正常P99 也就两秒多一点不像是有问题的样子。随后我去看平台自身的日志发现异常集中在数据库访问层面大量报错信息指向同一个方向连接获取超时Connection is not available, request timed out after 30000ms。到这一步基本确认问题不在外部而在数据库侧。最直接的下一步就是登录数据库查看当前活跃会话和锁状态。3.2 数据库侧排查锁等待浮出水面登录数据库后我执行了下面这条查询看看当前有哪些会话在长时间运行SELECT id, user, host, db, command, time, state, info FROM information_schema.processlist WHERE command ! Sleep ORDER BY time DESC;结果非常直观大量会话的 state 显示为Waiting for table metadata lock而且等待时间从几十秒到几百秒不等。这些会话的执行语句大多是对某一张核心任务表的 SELECT 或 UPDATE 操作。而其中最老的一个会话time 已经超过 600 秒执行的是一条ALTER TABLE语句——也就是说有人或某个定时脚本在这张表上执行了大表的 DDL 操作但一直没提交或没执行完。这就能解释整个链路了一条 DDL 语句持有了表的元数据锁后面的所有读写请求都必须等待这个锁释放。由于锁迟迟不释放等待的请求越来越多数据库连接被这些“卡住”的查询越占越多最终连接池被打满应用层无法获取连接于是所有 Agent 任务开始超时。我还确认了这张发生 DDL 的表正是平台里最核心的一张agent_task表记录着所有任务的状态和进度。任何任务的创建、状态更新、列表查询都涉及这张表它一被锁整个平台基本上就瘫痪了。3.3 快速止血优先恢复业务而非深究根因在确认了数据库侧存在锁等待之后我的第一优先级不是去找是谁执行了 DDL而是先让服务恢复。对于一个内部平台来说每多宕一分钟业务方的损失就多一分。所以当时我做了三步止血操作第一步查清楚当前执行 DDL 的会话 ID把它 kill 掉。既然 DDL 长时间不结束它大概率是“卡住”了或者执行效率极低。与其等它自行完成不如先终止它释放锁恢复业务。-- 查看当前所有非 Sleep 状态的会话 SHOW PROCESSLIST; -- 找到长时间执行的 DDL 会话后终止该会话 KILL thread_id;第二步检查连接池是否恢复。等锁释放后之前排队等待的查询会快速执行完毕连接池的活跃连接数会逐步下降应用日志里的连接获取超时开始消失。第三步通知相关业务方确认任务状态排查是否有任务数据出现异常尤其是那些在故障期间“卡在中间态”的任务。Agent Platform 的任务状态机设计得比较严格正常情况下任务只会从一个状态流转到另一个状态但连接池耗尽期间很多任务可能处于“已创建但未执行”或“执行中但未更新状态”的中间态。需要额外的补偿逻辑把这些任务重新拉起来。止血操作完成后平台的响应时间很快就恢复了正常。但这件事给我留下的思考远不止“kill 一个会话”这么简单——之后我用了整整一周的时间来梳理和优化整个平台的数据库使用方式从表结构设计到连接池配置再到监控告警都做了一次系统性的整改。3.4 事后复盘那个 DDL 到底是如何发生的解除了线上故障之后接下来最重要的事情是搞清楚为什么会在核心表上执行 DDL谁触发的经过查证发现这个 DDL 是由平台的一个“自动建表/加索引”的运维辅助功能触发的。这个功能的本意是方便非工程团队在界面上自助添加索引或者调整表结构省去提工单的流程。这个功能在开发的时候只考虑了“能用”没有考虑“什么时候不能用”。操作的同学在界面上选择了一张大表添加了一个索引然后就提交了。由于这张表的数据量有上亿条添加索引的 DDL 实际上是极其耗时的而且在执行期间数据库会对该表持有元数据锁导致所有访问这张表的查询全部阻塞。这里需要补充一个数据库原理MySQL 的元数据锁Metadata LockMDL。在 MySQL 5.5 版本之后引入了 MDL它的作用是保护表结构定义防止在执行 DDL 的过程中其他会话读到不一致的表结构。MDL 的获取规则是在事务中执行任何操作包括 SELECT都会获取表的 MDL 共享锁DDL 需要获取 MDL 排他锁。如果当前有其他事务持有了表的 MDL 共享锁DDL 就会被阻塞如果 DDL 已经持有排他锁之后的所有查询都会被阻塞。所以 MDL 是一个非常容易引发“连锁阻塞”的机制尤其是当 DDL 是大表的在线 DDL 时虽然 InnoDB 支持 Online DDL但 MDL 的获取和等待依然需要格外小心。这个案例的特殊性在于DDL 语句是直接提交执行的而不是放在事务里。理论上一条单独的ALTER TABLE语句执行结束后会自动释放 MDL。但因为加索引的操作迟迟不能完成且该表上的并发读写非常频繁所以 MDL 的排他锁被长时间持有后续请求全部排队等待。等到连接池被打满新请求连数据库连接都拿不到整个平台就僵住了。关键教训不要在业务高峰期对核心大表执行 DDL。如果确有需要必须使用支持 Online DDL 的方式并配合限流或低峰期窗口执行。更安全的做法是用专门的数据库变更平台支持审批、备份、分段执行和自动回滚。4. 系统性优化从根上避免超时故障复发4.1 数据库侧改造DDL 治理与流量控制这次故障给我的最大教训是核心生产环境里的 DDL 不能被随意执行。哪怕是一个看起来很小的加索引操作也可能因为表数据量太大而拖垮整个系统。所以我做的第一件事就是从流程上堵住这个口子。我把平台的“自动加索引/改表结构”功能直接下线了改成只读模式。任何 DDL 操作必须通过 DBA 团队的变更工单流程由 DBA 审核后在低峰期窗口执行。同时对于大表的 DDL强制要求使用专门的工具分批执行不能直接ALTER TABLE一把梭。这里补充一个实操细节MySQL 的在线 DDL 也分很多种ALGORITHMINPLACE和ALGORITHMCOPY的行为差别非常大。对大表加索引时InnoDB 实际上要重建索引这个过程虽然允许并发读写但会占用大量 I/O 和 CPU。如果表数据量极大即使不阻塞读写也可能因为资源消耗导致数据库整体变慢。所以更稳妥的方案是用pt-online-schema-change这类工具通过触发器的方式在线变更表结构把对业务的影响降到最低。另外数据库侧我还做了一层“会话治理”。具体来说是设置了一个定时的巡检脚本每隔一段时间扫描一次processlist如果发现存在执行时间超过阈值的 DDL 或非预期的大查询就自动 kill 并告警。这相当于给数据库加了一个“熔断机制”防止类似问题再次演变成全局故障。这个功能我用一个独立的脚本实现跑在一台单独的机器上不占用应用资源。4.2 连接池参数调整把“排队等连接”变成“快速失败”连接池侧的优化是我这次踩坑之后花时间最多的地方。我重新审视了 HikariCP 的每一个关键参数尤其是下面几个maximum-pool-size之前是 50我结合数据库 max_connections默认 151和应用实际并发调整到了 80。但更大的变化是我不再把这个参数当作“性能配置”而是当作“容灾配置”来理解。连接池的大小决定了系统允许的“并发数据库操作上限”超过了就是排队排队就是超时。所以宁可连接池稍微偏小也不要让它无限膨胀到数据库承受不住。connection-timeout这是获取连接的超时时间默认 30 秒。我把这个值改成了 5 秒。理由是如果 5 秒内拿不到连接说明系统的数据库访问已经严重积压与其让所有线程继续在这里排队不如让大部分请求快速失败给调用方一个明确的超时错误让上层的重试策略在更短的周期内重启整个流程。这比线程全部阻塞着等 30 秒要健康得多。max-lifetime连接的最大存活时间。之前是 30 分钟我改成了 15 分钟同时把数据库的 wait_timeout 调低到 60 秒。这样即使数据库侧清理了空闲连接应用侧也能在更短的时间内重新建立连接避免拿到“已失效连接”导致的额外错误。idle-timeout空闲连接回收时间。和 max-lifetime 配合着设避免池子里长期留存大量空闲连接。提示连接池参数没有“标准答案”一定要结合自己的数据库规格、业务量级、单次查询耗时来设置。我的调整思路是“缩短超时、快速失败、避免线程堆积”这比单纯调大连接数更有效。4.3 应用层改进超时分层与熔断降级除了连接池的参数我在应用层也做了一层改造——把超时分为“必须快速失败”和“允许等待”两类。外部系统提交任务的接口属于“必须快速失败”的请求因为调用方在同步等待结果不能让它长时间阻塞而任务执行器内部对大模型或外部 API 的调用属于“允许等待”的请求我给它们保留了 30 秒的超时时间因为这类调用本身就需要支持长耗时。具体实现上我在连接池的获取连接逻辑外面包了一层带超时控制的保护逻辑。如果应用在极短时间内比如 1 秒内连续出现连接获取失败就触发一个熔断开关。熔断开启后后续请求不再尝试获取数据库连接而是直接返回“系统繁忙”的降级响应。熔断开关在 30 秒后自动尝试半开放少量流量探活成功则关闭熔断恢复正常。这套熔断机制的实际效果在后续的一次低峰期 DDL 操作中得到了验证虽然有部分请求因为熔断而快速失败了但整个平台的数据库连接池没有被拖垮其他正常的查询依然能够稳定执行。这比“大家一起死磕数据库”要明智得多。4.4 监控与告警完善让异常在发生前就被看到故障复盘还有一个重要环节就是监控。之前平台的监控集中在“接口响应时间”和“任务失败率”这种外围指标这些指标反应太慢了——等它们异常时故障往往已经发生了好几分钟。这次之后我把监控重点往前移增加了下面这些更底层的监控项数据库活跃连接数占连接池比例超过 60% 就开始预警超过 80% 触发告警。数据库连接获取耗时P99 如果超过 1 秒就要注意超过 3 秒必须处理。数据库锁等待数量通过performance_schema的metadata_locks表定时采集这个非常关键MDL 锁是最容易被忽略的“隐形杀手”。数据库慢查询数量尤其是针对 agent_task 等核心表的慢查询一旦出现就要马上排查。这些监控项我用 Prometheus 自定义 exporter 实现配合告警规则推送到即时通讯工具里。监控的价值在于把“靠经验排查”变成“靠数据发现”有些隐患在故障发生前就会有征兆比如连接获取耗时缓慢上升、锁等待次数增加这些都是提前介入的信号。5. 常见问题与排查技巧实录5.1 线上超时排查的通用思路这次故障之后我把线上超时问题的排查思路整理成了一套通用方法论。遇到超时问题不要急着猜原因而是按照下面这个顺序去确认第一明确超时发生在哪一层。如果一个接口超时了先看日志里报的是连接获取超时、数据库查询超时、还是外部 API 调用的超时。这一步能帮你快速缩小范围而不是在错误的方向上浪费时间。第二检查数据库的状态。绝大多数超时问题最终都会指向数据库尤其是类似 Agent 平台这种数据库依赖极重的系统。用SHOW PROCESSLIST看一下当前有没有异常会话用SHOW ENGINE INNODB STATUS看一下事务状态和锁信息这些都是排查超时问题的第一手资料。第三检查连接池状态。应用日志里如果出现大量 “Connection is not available” 或者超时异常基本可以断定连接池被打满了。此时看两个指标活跃连接数和等待获取连接的线程数。活跃连接数打满而等待线程很多说明数据库执行变慢了活跃连接数不高但等待线程很多说明连接池配置太小或者连接泄漏。第四检查上游依赖。数据库没问题、连接池也没问题那就要关注外部服务了。对大模型调用、第三方 API 调用单独埋点通过耗时分布判断是否有慢请求拖垮了工作线程。5.2 Agent 平台超时故障速查表我把这次故障中涉及的各类问题和对应的处理方式整理成了下面的速查表方便后续直接对照参考。故障现象可能原因快速排查位置处理建议任务全部卡在“等待执行”数据库表被 MDL 锁阻塞processlist里看 state 是否为 Waiting for table metadata lockkill 锁源会话排查是否有 DDL 操作应用日志大量连接获取超时连接池被打满HikariCP 活跃连接数指标缩短 connection-timeout触发熔断降级单个步骤执行时间远超设置值外部 API / 大模型调用慢执行器日志与外部依赖埋点单独调大该步骤超时时间增加重试接口偶尔超时但数据库正常连接池配置过小活跃连接数是否接近 max 值适当调大连接数或优化查询效率数据库 CPU 不高但响应慢有长事务占用锁资源查看 InnoDB 事务列表与锁等待定位长事务评估是否终止优化事务边界凌晨自动任务导致系统卡顿批量任务集中执行定时任务日志与监控分批执行、错峰调度、限制并发上面这些场景中前两条是这次故障的核心后面几条是 Agent 平台日常运行中更常见的情况。每一个问题的排查思路都是顺着“请求链路 → 线程 → 连接 → 数据库锁”这条主线走下来的。只要把链路的关键点都想清楚大部分超时问题都能在半小时内定位到大致方向。5.3 两个容易忽略但极其重要的细节第一个细节是事务不要包裹不必要的操作。Agent Platform 早期版本里某些任务的状态更新逻辑会把外部 API 调用和数据库更新放在同一个事务里。这带来的后果是如果外部 API 响应很慢比如大模型生成回复花了 20 秒事务就会一直持有数据库连接的写锁把一个宝贵的连接白白占住 20 秒。这是一个非常隐蔽的连接池“隐形杀手”。正确的做法是事务只包裹数据库操作外部调用必须在事务之外完成。第二个细节是数据库连接池的监控要绑定到指标而不是日志。故障发生时应用日志里的异常是“果”池子里的连接占用情况才是“因”。如果只依赖日志告警最多只能做到故障发生后快速响应做不到提前预防。所以我强烈建议凡是用连接池的中间件一定把池子的活跃连接数、等待获取连接数、创建连接数、关闭连接数这些指标全部暴露给监控系统设置合理的基线任何异常趋势都能提前发现。6. 把故障教训沉淀为平台能力这次线上超时故障过去之后我最大的体会是故障本身就是最好的技术复盘教材。如果你的系统一辈子没出过问题你永远不会知道连接池耗尽时那种“所有请求一起卡死”的无助感也不会理解为什么 MDL 锁能在一个内部平台里造成这么大的影响。基于这次故障的经验我给 Agent Platform 做了一套常态化的混沌测试方案。每隔一段时间我会在测试环境里主动制造一些异常场景比如把核心表的查询加一个sleep模拟慢查询或者直接模拟连接池占满观察平台的降级行为和告警是否正常触发。这套方案的价值在于它能把这次故障沉淀下来的教训固化成系统的“肌肉记忆”而不是只停留在文档和复盘里。另外我也呼吁了一下团队建立一个“数据库变更双人复核”机制。任何涉及生产环境表结构的 DDL都需要至少两个人同时确认一个人执行一个人监督。DDL 的执行时间窗口、影响的行数、预估的耗时都要在执行前做评估。这条流程在后续的几次表结构变更中确实帮了不少忙——虽然流程多了一步但换来的稳定性是值得的。最后说一个我自己养成的习惯每次发布完 Agent Platform 的版本我都会在日志系统里手动跑一次全链路模拟任务从提交任务、调度执行、调用大模型、写回结果完整走一遍。这个模拟任务就像系统的“健康自检”如果它能在几秒内正常跑完说明核心链路没问题一旦模拟任务超时或者出错那就说明哪里有问题需要立刻排查。这个小动作花不了多少时间但能在用户发现问题之前帮我提前发现很多潜在隐患。这个项目后续还会继续扩展比如引入更细粒度的工作流引擎、支持更多的 Agent 类型、增加更完善的人工审批环节。但只要数据库和连接池这个核心底座打得够稳超时故障就会越来越远离我们的线上环境。