1. 项目概述当并行测试撞上数据库死锁最近在重构一个基于 Playwright 的自动化测试平台时我们团队踩了一个大坑当并发执行大量测试用例时数据库频繁出现死锁导致测试任务失败日志里一堆“Deadlock found when trying to get lock; try restarting transaction”的报错。这问题在单Worker运行时一切正常一旦开启多个Worker并行执行就成了定时炸弹。经过一番排查和方案设计我们最终找到了一套相对完善的隔离方案不仅解决了死锁问题还提升了整体测试的稳定性和执行效率。如果你也在用 Playwright 做并行测试并且后端涉及到数据库操作那这篇文章或许能帮你避开我们走过的弯路。简单来说这个问题的核心矛盾在于Playwright 的并行 Worker 旨在充分利用多核CPU加速测试执行而数据库尤其是像 MySQL 这类使用行锁的数据库在高并发写操作下如果事务处理不当极易发生死锁。我们的测试脚本中每个用例执行前后都会记录状态、更新结果、插入日志这些密集的、可能涉及相同数据行的数据库操作在并行环境下就成了死锁的温床。本文将详细拆解死锁成因并分享我们从“治标”到“治本”的几种隔离方案包括代码层面的优化、数据库配置调整以及架构设计上的思考。2. 死锁成因深度剖析并行Worker与数据库的冲突点要解决问题首先得搞清楚死锁是怎么发生的。很多人一看到死锁就想到加锁顺序这没错但在 Playwright 并行测试这个场景下情况更复杂一些。2.1 Playwright 并行执行模型Playwright Test 默认或在配置中指定会启动多个 Worker 进程。每个 Worker 独立运行一个测试文件甚至一个测试文件内的多个测试用例也可能被调度到不同 Worker。这些 Worker 之间是隔离的拥有各自的内存空间和 Playwright 浏览器上下文。然而它们通常共享同一个数据库连接池。当多个 Worker 同时执行测试并几乎同时发起数据库事务时冲突就开始了。例如一个常见的模式是每个测试用例开始前会在test_case_run表中插入一条状态为“running”的记录用例结束后更新该记录状态为“success”或“failed”并在test_log表中插入详细的日志。如果两个 Worker 的测试用例碰巧在操作相关联的数据比如都去更新同一个测试计划的总状态或者操作有外键关联的同一组数据死锁的概率就会大增。2.2 数据库死锁的经典场景再现在我们的案例中通过分析数据库的SHOW ENGINE INNODB STATUS输出定位到了最常见的死锁场景它涉及对同一张表不同数据行的“交叉更新”。假设有两个并行测试用例 A 和 B它们对应的执行记录 ID 分别是 100 和 101。它们的数据库操作时序可能如下Worker 1 (用例A)开启事务更新test_case_run表中id100的记录例如statusrunning。此时数据库在id100这行数据上获得了排他锁X锁。Worker 2 (用例B)几乎同时开启事务更新test_case_run表中id101的记录statusrunning。在id101这行数据上获得了X锁。Worker 1 (用例A)继续执行需要插入一条日志到test_log表。test_log表有一个外键case_run_id引用了test_case_run.id。在插入前数据库会去检查外键约束这需要读取test_case_run表中id101的记录以确认外键存在。由于id101已经被 Worker 2 的事务锁住了X锁不允许读Worker 1 的事务会尝试获取一个共享锁S锁并进入等待。Worker 2 (用例B)同样它也需要插入日志外键检查需要读取test_case_run表中id100的记录。而这行正被 Worker 1 的事务锁着。于是Worker 2 也进入等待。至此循环等待形成Worker 1 等着 Worker 2 释放id101的锁Worker 2 等着 Worker 1 释放id100的锁。数据库引擎检测到这种情况后会选择代价较小的事务进行回滚通常是后发起的事务从而解除死锁。这就是你会在日志中看到“Deadlock found”的原因。注意这里的关键在于“外键约束检查”和“非唯一索引上的间隙锁”。即使更新的是不同的行如果更新语句使用了非唯一索引或者涉及范围更新InnoDB 可能会加间隙锁Gap Lock或临键锁Next-Key Lock这大大增加了不同事务之间锁冲突的范围使得死锁更容易在“看似无关”的操作间发生。3. 方案一事务与连接池的精细化控制我们的第一反应是从数据库访问层入手优化事务的粒度和使用方式。这是成本相对较低、见效较快的方案。3.1 缩短事务生命周期及时提交检查测试代码中是否过早地开启了事务或者忘记了提交/回滚。一个反模式是在测试用例开始前就开启一个大事务涵盖所有准备、执行、断言和清理操作。这会导致锁持有时间过长极大增加死锁风险。优化后遵循“最小事务原则”。只将必须原子化的数据库操作包裹在事务中并且一旦操作完成立即提交。// 反例事务范围过大 async function runTestCase(testCase) { const connection await pool.getConnection(); await connection.beginTransaction(); try { // 1. 更新状态为运行中 await connection.query(UPDATE test_case_run SET status ? WHERE id ?, [running, testCase.runId]); // 2. 执行可能很耗时的Playwright测试 await page.goto(testCase.url); await page.click(button#submit); // ... 更多UI操作 // 3. 更新状态为成功 await connection.query(UPDATE test_case_run SET status ? WHERE id ?, [success, testCase.runId]); // 4. 插入日志 await connection.query(INSERT INTO test_log ...); await connection.commit(); } catch (error) { await connection.rollback(); throw error; } finally { connection.release(); } }// 正例拆分事务及时提交 async function runTestCase(testCase) { const connection await pool.getConnection(); // 仅包裹状态更新和日志插入这两个紧密关联的DB操作 try { await connection.beginTransaction(); await connection.query(UPDATE test_case_run SET status ? WHERE id ?, [running, testCase.runId]); await connection.commit(); // 尽早提交释放锁 } catch (error) { await connection.rollback(); throw error; } finally { connection.release(); } // 执行与数据库无关的、耗时的Playwright操作 try { await page.goto(testCase.url); await page.click(button#submit); // ... } catch (e) { // 处理UI测试失败 testResult failed; errorMsg e.message; } // 测试执行完毕再次开启事务更新最终结果 const connection2 await pool.getConnection(); try { await connection2.beginTransaction(); await connection2.query(UPDATE test_case_run SET status ? WHERE id ?, [testResult, testCase.runId]); await connection2.query(INSERT INTO test_log (case_run_id, level, message) VALUES (?, ?, ?), [testCase.runId, INFO, Test completed with status: ${testResult}]); await connection2.commit(); } catch (error) { await connection2.rollback(); // 此处需要谨慎处理可能记录到文件或另一个更简单的存储中 console.error(Failed to update final test result:, error); } finally { connection2.release(); } }实操心得拆分事务后虽然数据库交互次数可能略微增加但每个锁持有的时间极短像闪电一样“碰一下”就释放大大降低了与其他事务“纠缠”的机会。实测下来死锁频率下降了70%以上。3.2 为每个Worker分配独立的数据库连接池默认情况下所有 Worker 可能共享一个全局的数据库连接池。当并发数高时连接池中的连接被多个Worker的事务竞争使用可能加剧锁冲突。一个进阶方案是为每个 Playwright Worker 初始化一个独立的、小型的数据库连接池。这可以通过 Playwright 的workerData或利用依赖注入框架来实现。每个 Worker 进程拥有自己的连接池实例连接之间互不干扰。这样做的好处是从连接层面进行了一定程度的隔离减少了共享连接池内部可能出现的资源争用。但需要注意数据库服务器的总连接数会成倍增加Worker数 * 每个Worker的连接池大小需要相应调整数据库的max_connections参数。注意这个方案更适合于 Worker 数量相对固定且不多的场景。如果动态弹性伸缩 Worker管理这些连接池的生命周期会变得复杂。4. 方案二数据库层优化与操作序列化如果代码优化后死锁仍有发生或者你希望对系统有更强的掌控力可以从数据库本身和任务调度层面着手。4.1 调整数据库隔离级别与索引策略审慎使用更低的隔离级别默认的REPEATABLE READ隔离级别为了保证可重复读使用了较多的间隙锁。对于测试结果记录这种对“可重复读”要求不高的场景可以尝试将相关会话的事务隔离级别设置为READ COMMITTED。在这个级别下InnoDB 会减少间隙锁的使用从而降低死锁概率。但务必评估这对你业务逻辑的影响例如是否会出现“不可重复读”或“幻读”问题在测试结果记录场景中通常可以接受。-- 在获取数据库连接后执行 SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED;优化索引确保UPDATE和DELETE语句的WHERE条件都使用了唯一索引最好是主键。使用唯一索引时InnoDB 只需要锁住具体的行。如果使用非唯一索引它可能锁住一个范围间隙锁极易引发死锁。检查你的test_case_run表id作为主键没问题但要确保外键字段如plan_id上的查询也有合适索引。4.2 引入任务队列进行串行化处理这是最彻底的“隔离”方案之一。既然并行写数据库是根源那么就让这些写操作排队执行。我们引入了一个轻量级消息队列如 Redis Bull或直接使用数据库作为队列。架构调整如下Playwright Worker 只负责执行“纯测试”逻辑操作浏览器、定位元素、执行交互、收集界面结果。这个过程不涉及任何数据库写操作。测试执行完成后Worker 将需要持久化的结果状态、日志、截图路径等作为一个消息体发送到任务队列。单独启动一个或多个建议开始时为单个结果写入器Worker。这个写入器从队列中顺序消费消息负责将所有结果写入数据库。这样一来所有对核心数据表test_case_run,test_log的写操作都由单个进程串行执行从根本上杜绝了并行写导致的死锁。Playwright Worker 从此“轻装上阵”专注于其擅长的浏览器自动化吞吐量反而可能因为解除了数据库枷锁而提升。避坑技巧使用此方案时要确保消息队列的可靠性持久化、确认机制避免结果丢失。同时写入器需要做好错误重试和死信处理。此外测试执行的“实时状态”更新会稍有延迟因为状态从“运行中”到“完成”需要经过队列中转。如果前端需要实时显示状态可以考虑通过 WebSocket 推送来自 Playwright Worker 的中间状态而最终结果仍由队列写入器保证一致性。5. 方案三应用层设计——资源分区与悲观锁除了上述后端方案在测试用例和应用设计层面也可以做一些文章从源头上减少冲突。5.1 测试数据隔离与分区确保每个并行执行的测试用例操作完全独立的数据集。例如通过动态生成测试数据让每个用例使用唯一的用户名、订单号、产品ID等。这样即使它们同时更新数据库操作的也是不同的数据行自然没有锁冲突。如果无法做到完全独立可以考虑“分区”执行。例如将测试套件按功能模块划分确保不同模块的测试用例不会操作相同的核心业务数据表。然后通过配置让 Playwright 的 Worker 按模块分组执行同一组内的用例串行或控制并发组间并行。5.2 针对共享资源的悲观锁控制对于少数必须更新的共享资源比如一个记录测试套件总体进度的计数器可以主动使用悲观锁在应用层控制访问顺序。使用数据库悲观锁在事务开始时使用SELECT ... FOR UPDATE语句锁定共享资源。这相当于明确告诉数据库“我要改这个帮我占住别人都排队。” 这强制了对该资源的串行访问。BEGIN; SELECT current_count FROM test_suite_progress WHERE suite_id 123 FOR UPDATE; -- ... 计算新的进度 UPDATE test_suite_progress SET current_count ? WHERE suite_id 123; COMMIT;使用此方法务必谨慎因为它会严重影响并发性能只适用于更新频率极低的场景。使用分布式锁在更新共享资源前先从 Redis 或 ZooKeeper 等中间件获取一个分布式锁。获取到锁的 Worker 才能执行更新操作其他 Worker 等待。这比数据库行锁更轻量且超时机制更灵活。6. 诊断、监控与回退方案无论采用哪种方案完善的诊断和监控都是必不可少的。6.1 死锁诊断工具链数据库日志开启 InnoDB 的死锁日志innodb_print_all_deadlocks ON所有死锁信息都会写入错误日志。这是分析的第一手资料。SHOW ENGINE INNODB STATUS在死锁发生时立即在数据库执行此命令。输出的LATEST DETECTED DEADLOCK部分会详细展示两个事务各自持有的锁和等待的锁是定位问题SQL的利器。应用日志关联在你的测试框架中确保每个数据库操作都打上唯一的追踪ID如测试用例ID、Worker ID。当死锁发生时将数据库死锁日志中的SQL语句与你应用日志中的追踪ID关联起来就能迅速定位是哪个测试用例、哪段代码引发的。6.2 监控与告警监控数据库的Innodb_row_lock_time_avg平均行锁等待时间和Innodb_deadlocks死锁次数等指标。当这些指标出现异常飙升时触发告警。同时监控你的结果写入队列如果采用了方案二的长度防止消费者进程挂掉导致队列堆积。6.3 优雅降级与重试机制在代码中对数据库操作特别是更新和插入进行包装捕获死锁异常在MySQL中通常是ER_LOCK_DEADLOCK错误码。async function safeDbUpdate(query, params, maxRetries 3) { let lastError; for (let i 0; i maxRetries; i) { try { const result await db.query(query, params); return result; } catch (error) { if (error.code ER_LOCK_DEADLOCK i maxRetries - 1) { // 遇到死锁等待一段随机时间后重试 const delay Math.random() * 100 50; // 50-150ms 随机延迟 await new Promise(resolve setTimeout(resolve, delay)); lastError error; continue; } throw error; // 非死锁错误或重试次数用尽直接抛出 } } throw lastError; }重要提示重试是应对死锁的“最后一道防线”而不是首选方案。它治标不治本且会增加请求延迟。我们的目标是通过前面的隔离方案将死锁发生率降到极低重试机制只是用来处理那些极端偶发的情况。7. 方案选型与组合策略没有银弹你需要根据你的测试规模、基础设施和团队能力来选择或组合方案。中小型项目/快速修复优先实施方案一缩短事务生命周期和方案三.1测试数据隔离。这两项投入小效果显著。中大型项目/追求稳定性在实施方案一的基础上强烈考虑方案二.2引入任务队列。它将计算密集型Playwright执行和I/O密集型数据库写入解耦系统扩展性和鲁棒性最好。可以配合方案三.2分布式锁处理极少数共享资源。遗留系统/限制较多如果架构大改困难可以重点进行方案二.1数据库调优并结合完善的诊断与重试机制方案四。我们团队最终采用了“方案一精细化事务控制 方案二.2任务队列异步写库”的组合。Playwright Worker 变得非常轻快只通过消息队列发送结果事件。我们编写了一个独立的结果处理服务来消费队列负责所有数据库持久化工作。这套系统上线后数据库死锁错误彻底归零并且因为解耦我们可以独立扩展 Playwright Worker 的数量和结果处理服务的能力整体测试任务的吞吐量提升了近3倍。踩过这个坑之后我的体会是在引入像 Playwright 并行测试这样强大的效率工具时一定要对其可能带来的后端压力有充分的预估。并发编程的复杂性往往会从应用层转移到数据层。提前设计好数据访问模式和隔离边界远比出了问题再救火要轻松得多。如果你的测试框架还在早期不妨在设计之初就考虑采用“事件驱动异步持久化”的架构为未来的规模化并行打好基础。