PHP常驻Worker中MySQL连接超时断连问题分析，2006错误导致任务持续失败

在构建高并发异步任务系统时，PHP 常驻 Worker（CLI 模式下长期运行的后台进程）因其轻量、易部署特性被广泛采用。然而，当任务涉及长时间外部 I/O（如调用大模型 API 耗时 1~5 分钟），其与数据库的连接稳定性问题便凸显出来——近期某项目上线后频繁出现 PDOException: SQLSTATE[HY000]: General error: 2006 MySQL server has gone away 异常，导致任务结果无法持久化，且故障具有“一次性断连、全局失效”的连锁效应。

该系统架构为：Web 接口将任务投递至 Kafka 消息队列，由 PHP CLI Worker 持续消费并执行；任务流程分为两阶段：先同步调用外部 AI HTTP 接口（最长等待 300 秒），再将处理结果通过 ClerkService::update() 写入 MySQL。整个 Worker 进程采用单例模式管理数据库连接，即 Db::$instance 保存一个全局 PDO 实例，贯穿整个 while 循环生命周期。

问题核心在于连接空闲超时机制的冲突。MySQL 服务端默认 wait_timeout 为 28800 秒（8 小时），但云数据库网关（如阿里云 RDS、腾讯云 CDB）通常会主动回收空闲连接，阈值常设为 300~600 秒。而 Worker 在以下两种场景下极易触发此阈值：

一旦连接被服务端关闭，底层 TCP socket 实际已失效。当 Worker 最终拿到 AI 结果尝试执行 UPDATE 时，PDO 仍复用原连接句柄，导致 2006 错误抛出。更严重的是，该错误发生后，该 PDO 实例进入不可恢复状态——即使后续重试，只要未重建连接，所有写操作均失败，必须人工重启 Worker 进程才能恢复。

进一步排查发现，该问题与 PHP 版本强相关。在 PHP 7 环境下，PDO::exec() 遇到连接中断时返回 false，可配合 robustExecute() 和 shouldReconnect() 逻辑实现自动重连；但在 PHP 8+ 中，PDO::exec() 直接抛出 PDOException，异常若未被捕获或未在 robustExecute() 中显式捕获，将直接中断当前任务流程，且不会触发重连逻辑。

为解决此问题，团队设计了一套防御性重试机制：

• 在业务层 ClerkService::update() 调用前，增加连接健康检查 Db::checkConnection()；
• 若检测到 2006 错误，则主动调用 reConnect() 重建 PDO 实例；
• 重连成功后，再次执行原 SQL 操作；
• 若二次写库仍失败，则记录日志并标记任务失败，避免无限重试。

该流程通过状态标志 dbSaved 控制重试边界，确保单次任务最多尝试两次写库，既保障数据一致性，又防止资源浪费。

值得注意的是，此类问题并非 PHP 独有，而是长周期常驻进程与有状态数据库连接共存时的典型陷阱。在 Java 中，HikariCP 等连接池默认启用 connection-test-query 和 idle-timeout 自动驱逐机制；Go 的 database/sql 包推荐使用连接池而非单例连接；Node.js 的 mysql2 库也提供 enableKeepAlive 和 connectTimeout 配置以维持长连接活性。相比之下，PHP 生态中缺乏开箱即用的连接保活方案，开发者往往依赖手动轮询或定时 reConnect，增加了运维复杂度。

从工程实践角度，该案例揭示了三个关键教训：

第一，常驻进程 ≠ 无状态进程。即使逻辑上是“无状态”的任务处理器，只要持有外部资源（如数据库连接、HTTP 客户端），就必须考虑资源生命周期管理。

第二，超时配置需对齐。外部接口超时（如 curl_setopt($ch, CURLOPT_TIMEOUT, 300)）与数据库空闲超时（wait_timeout）、网络层 Keepalive（TCP keepalive interval）应形成协同策略，避免“前端等得久、后端早已断”的错位。

第三，版本迁移需重审异常处理。PHP 8 对 PDO 异常行为的变更虽提升了错误可见性，但也打破了旧版隐式容错逻辑，升级时必须同步审查所有数据库操作路径。

目前，该问题已在生产环境通过引入连接健康检查与有限重试机制缓解。后续计划将数据库访问层改造为连接池模式（如基于 Swoole 的协程 MySQL 客户端），从根本上规避单连接长时占用风险。对于仍在使用传统 PHP CLI Worker 的团队，建议将 Db::checkConnection() 作为标准防护步骤纳入所有写操作前置校验中。

此类问题虽不涉及前沿技术，却真实影响系统可靠性与运维成本。在微服务与异步任务日益普及的今天，如何让“简单”的 PHP Worker 稳定跑满 7×24 小时，仍是值得深入探讨的工程细节。