private function fsock_asy_do($get){
$fp = fsockopen("ssl://www.xxx.com", 443, $errno, $errstr, 30);
if (!$fp) {
echo "$errstr ($errno)<br />\n";
} else {
stream_set_blocking($fp,0);//开启非阻塞模式
$out = "GET /".$get." HTTP/1.1\r\n";
$out .= "Host: www.xxxx.com\r\n";
$out .= "Connection: Close\r\n\r\n"; fwrite($fp, $out);
/*忽略执行结果
while (!feof($fp)) {
echo fgets($fp, 128);
}*/
usleep(1000);
fclose($fp);
}
}

在这段代码里面,调用后忽略执行结果直接返回,可用于php异步执行。

在nginx服务器上有一个比较诡异的情况就是有时候无法调用异步的脚本。

查阅相关资料后,是nginx 499 的问题。

其中解决方案有以下,经过对每一个方案的验证最终得出结果:

1、NGINX 499

查看 NGINX access log,发现这样的请求会以 499(Client Closed Request)记录。确定问题是因为:客户端主动端口请求连接时,NGINX 不会将该请求代理给上游服务(FastCGI PHP 进程),这个时候 access log 中会以 499 记录这个请求。

要解决这个问题需要将 NGINX FastCGI 忽略客户端中断配置打开:

fastcgi_ignore_client_abort on;

这样无论客户端是否断开,都会将这个请求代理给上游,并且会记录上游服务处理后的返回状态。

2、NGINX 线程原因

将nginx的worker_processes 由之前的auto修改为2(我的是单核服务器)

3、NGINX 499

nginx对499的定义是”client has closed connection”,并且在这些情况下会返回这个状态码:

  1. upstream 在收到读写事件处理之前时发现连接不可用。
  2. server处理请求未结束,而client提前关闭了连接。
  3. upstream出错,执行next_upstream时发现连接不可用。

一个不安全的做法是在fclose之前,让当前的进程先睡眠一段时间;我这里设置为10毫秒,这10毫秒的延迟对我完成整个请求的影响不大,同时我也认为nginx一定能在10毫米内把请求转到fastcgi去执行。这个时间间隔很难把握,不能保证php一定有执行到。

这种方式并不是真正的异步,只是很取巧的强制关闭连接而不等待服务器端响应。所以在Laruence的那2篇文章中,有2个问题:

  • PHP使用fsock不能叫做异步,只是伪异步。
  • fwrite之后马上执行fclose,nginx会直接返回499

由于我的代码上面usleep为1000,初步估计是时间不够导致没发出去就close了,所以调整为20000。并进行最后测试。

结果晚点更新。

更新结果:测试2天结果显示正常,的确是usleep数值过小的问题。

05-04 04:49