php - Nginx + PHP : stop process at canceled request

Question

我有 Nginx 1.4.4 和 PHP 5.5.6。我正在发出长轮询请求。问题是，如果我取消通过 Ajax 发送的 HTTP 请求，请求仍在处理中(它们不会停止)。我在文件末尾使用 PHP mail() 函数对其进行了测试，邮件仍在发送，文件并未停止)。

我很担心，因为我认为它可能会因为未关闭请求的高负载而导致服务器崩溃。是的，我尝试了 ignore_user_abort(false); 但没有任何变化。有可能我应该在 Nginx 中改变一些东西吗？

  location ~ \.php$ {    
    try_files $uri =404;
    include fastcgi_params;
    fastcgi_pass 127.0.0.1:9000;
    fastcgi_index index.php;
    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;  
  }

Answer 1

坏消息是您几乎肯定无法按照您想要的方式解决问题。当客户端在收到请求之前关闭连接时发送的 FastCGI 信号是 FCGI_ABORT_REQUEST

A Web server aborts a FastCGI request when an HTTP client closes its transport connection while the FastCGI request is running on behalf of that client. The situation may seem unlikely; most FastCGI requests will have short response times, with the Web server providing output buffering if the client is slow. But the FastCGI application may be delayed communicating with another system, or performing a server push.

不幸的是，它看起来既不像原来的 fast-cgi implementation也不PHP-FPM支持FCGI_ABORT_REQUEST信号，不能中断。

好消息是有更好的方法可以解决这个问题。基本上你不应该有需要很长时间来处理的请求。相反，如果请求需要很长时间来处理，您应该:

• 将其推送到需要处理的任务队列中。
• 将“任务 ID”返回给客户。
• 让客户端定期轮询以查看该“任务”是否已完成，并在完成时显示结果。

除了这 3 项基本内容之外 - 如果您担心当客户端不再对请求的结果感兴趣时会浪费系统资源，您应该添加:

• 将任务分解成小块工作，如果客户仍然要求结果，则只将任务从一个工作“状态”转移到下一个工作“状态”。

您没有说明长期运行的任务是什么 - 让我们假设它是从另一台服务器下载一个大图像文件，处理该图像，然后将其存储在 S3 中。所以这个任务的状态是这样的:

TASK_STATE_QUEUED
TASK_STATE_DOWNLOADING //Moves to next state when finished download
TASK_STATE_DOWNLOADED
TASK_STATE_PROCESSING  //Moves to next state when processing finished
TASK_STATE_PROCESSED
TASK_STATE_UPLOADING_TO_S3 //Moves to next state when uploaded
TASK_STATE_FINISHED

因此，当客户端发送初始请求时，它会返回一个 taskID，然后当它查询该任务的状态时，可以:

• 服务器报告任务仍在处理中

或

• 如果它处于以下状态之一，客户端请求会将其跳转到下一个状态。

即

TASK_STATE_QUEUED => TASK_STATE_DOWNLOADING
TASK_STATE_DOWNLOADED => TASK_STATE_PROCESSING
TASK_STATE_PROCESSED => TASK_STATE_UPLOADING_TO_S3

所以只有客户感兴趣的请求才会继续处理。

顺便说一句，我强烈建议使用旨在高效工作的东西作为队列来保存任务队列(例如 Rabbitmq 、 Redis 或 Gearman )，而不是仅仅使用 MySQL 或任何数据库。基本上，SQL 在充当队列方面并不是那么出色，您最好从一开始就使用适当的技术，而不是使用错误的技术开始，然后在数据库变得紧急时不得不将其换掉当它试图每秒执行数百次插入、更新以管理任务时重载。

作为一个附带的好处，通过将长时间运行的流程分解为任务，它变得非常容易:

1. 查看处理时间花在了哪些地方。
2. 查看并检测处理时间的波动(例如，如果 CPUS 达到 100% 的利用率，那么调整图像大小会突然花费更长的时间)。
3. 在缓慢的步骤上投入更多资源。
4. 您可以向客户提供状态更新消息，这样他们就可以看到任务的进展情况，这样可以提供更好的用户体验，而不是坐在那里“什么都不做”。