AJAX长任务监听：解决Pending阻塞问题

本文旨在解决使用 AJAX 监听服务器端长耗时任务进度时遇到的“请求挂起”（Pending）问题。通过分析传统并发请求的局限性，文章提出并详细阐述了“链式 AJAX 请求”的解决方案。这种方法将长任务分解为多个小步骤，客户端通过连续发送 AJAX 请求来逐步执行并获取实时进度，从而避免了服务器端阻塞，实现了平滑的用户体验。

在Web开发中，我们经常会遇到需要执行耗时较长的服务器端操作（如数据导入、复杂计算等）的场景。为了提升用户体验，通常会考虑在客户端显示任务进度。然而，直接使用AJAX并发请求来监听进度时，常常会遇到一个棘手的问题：进度查询请求（如checkprogress.php）在网络面板中显示为“Pending”，直到主任务（如script.php）完成后才突然更新到100%。本文将深入探讨这一现象的原因，并提供一种有效的解决方案。

理解“Pending”阻塞现象

当客户端尝试通过两个独立的XMLHttpRequest对象同时向服务器发送请求时，如果其中一个请求（例如，执行长任务的script.php）长时间占用服务器资源或PHP会话锁，那么后续的请求（例如，查询进度的checkprogress.php）可能会被服务器挂起，直到第一个请求完成并释放资源。

原始代码分析：

在提供的代码示例中，index.php尝试通过两个独立的AJAX请求来管理进度：

1. xhr 对象： 发送请求到 script.php，该脚本模拟一个耗时10秒的循环，并每秒将当前进度写入 progress.txt 文件。
2. xhr2 对象： 通过 setInterval 定时器，每100毫秒发送请求到 checkprogress.php，该脚本读取 progress.txt 的内容并返回给客户端更新进度条。

问题在于，当 script.php 正在执行时，它可能会锁定PHP会话或占用服务器的单个进程/线程资源。这意味着 checkprogress.php 的请求无法立即得到处理，而是在服务器端排队等待，直到 script.php 完成。因此，客户端看到的现象就是进度条一直停留在0%，然后瞬间跳到100%。

解决方案：链式 AJAX 请求

要解决这种并发请求阻塞的问题，核心思想是将一个长耗时任务分解成一系列小的、独立的子任务。客户端通过发送一个AJAX请求来执行一个子任务，等待其响应，然后根据响应数据决定是否继续发送下一个AJAX请求来执行下一个子任务。这种模式称为“链式 AJAX 请求”或“分步式处理”。

工作原理：

1. 任务分解： 将长耗时任务拆分为多个原子性的步骤。
2. 状态管理： 服务器端需要一个机制来保存任务的当前状态（例如，已完成的步骤、总步骤数、中间结果等）。这可以通过文件、数据库、缓存或PHP会话来实现。
3. 客户端驱动： 客户端发起第一个请求，服务器执行第一个步骤并返回当前进度和下一个步骤所需的信息。客户端接收到响应后，更新UI，并根据需要再次发起请求执行下一个步骤，直到所有步骤完成。

这种方式确保了在任何给定时间，服务器端只有一个短平快的PHP脚本在处理请求，避免了长时间占用资源和会话锁，从而允许客户端实时获取进度更新。

实现链式 AJAX 进度的步骤

我们将改造原始的 script.php 和 index.php 来实现链式 AJAX。

1. 服务器端改造 (process_step.php)

不再让一个PHP脚本执行所有耗时操作，而是让它只执行一步，并返回当前状态。

process_step.php (示例代码)

 $progress,
    'currentStep' => $currentStep,
    'totalSteps' => $totalSteps,
    'status' => ($currentStep > $totalSteps) ? 'done' : 'continue'
]);

// 确保会话写入并解锁，以便其他请求可以访问
session_write_close();
?>

说明：

• process_step.php 接收 step 参数，表示当前要执行的步骤。
• 每次执行一个 sleep(1) 模拟一个耗时操作。
• 计算当前进度并返回 JSON 格式的响应，包含 progress、currentStep、totalSteps 和 status。
• session_write_close() 非常重要，它会立即保存会话数据并释放会话锁，允许其他PHP脚本（即使是来自同一客户端的请求）立即执行，避免阻塞。

2. 客户端改造 (index.php)

客户端将负责发起第一个请求，并根据服务器的响应递归地发起后续请求。

index.php (客户端脚本部分示例)

0%
Start Process

说明：

• startButton 点击后调用 executeNextStep(0) 启动任务。
• executeNextStep 函数递归调用自身，每次发送 currentStep 参数给服务器。
• 接收到服务器响应后，解析JSON，更新进度条，并根据 response.status 决定是继续调用 executeNextStep 还是标记任务完成。
• 错误处理和按钮禁用/启用逻辑增加了用户体验。

注意事项与最佳实践

1. 状态持久化： 在更复杂的场景中，任务状态可能需要存储在数据库中，以便在用户刷新页面或中断后可以恢复任务。
2. 错误处理： 客户端和服务器端都需要健壮的错误处理机制，以应对网络中断、服务器错误或数据处理失败等情况。
3. 用户反馈： 除了进度条，还可以提供文本提示（如“正在处理第 X 步，共 Y 步”）、动画效果等，增强用户体验。
4. 超时设置： 为AJAX请求设置合理的超时时间，防止因服务器无响应而导致客户端长时间等待。
5. 安全性： 如果任务涉及敏感数据或操作，确保所有AJAX请求都经过适当的身份验证和授权。
6. 并发限制： 虽然链式AJAX解决了单个长请求的阻塞问题，但如果同时有大量用户执行类似的长任务，服务器仍然可能面临压力。考虑使用消息队列、后台任务系统（如Gearman, RabbitMQ）来异步处理真正的长任务。
7. WebSockets/SSE： 对于需要真正实时、双向通信的场景，WebSockets或Server-Sent Events (SSE) 是更优的选择，它们允许服务器主动向客户端推送更新，无需客户端频繁轮询。然而，它们的实现复杂度相对较高。

总结

通过将长耗时任务分解为一系列小的、可独立执行的步骤，并采用链式AJAX请求的模式，我们可以有效解决AJAX进度监听中遇到的“Pending”阻塞问题。这种方法不仅提供了实时的进度反馈，提升了用户体验，也优化了服务器资源的利用。在设计需要进度报告的Web应用时，理解并应用这种分步处理的策略至关重要。