Windows下nginx+fastcgi+php的并发阻塞问题

接到一个需求，两个项目之间需要以接口形式通讯。我心想curl轻松解决，Easy！

啪嗒啪嗒啪嗒……代码撸完了，本地测试一下

浏览器一直转圈圈直到超时……

Why!?

没有任何错误提示信息，日志也没有任何新记录

用POSTMAN调试了一下刚写出的接口，没问题啊？

再试一次结果依旧，重启环境后再试也依旧

经过一番测试，我怀疑是不是我本地环境无法并发？

我访问项目A是一个请求，项目A访问项目B的接口则是第二个请求。在无法并发只能排队请求的情况下，第一个请求依赖于第二个请求的结果；第二个请求却排在后面一直等待第一个请求执行完毕。这就导致互相依赖产生死循环，也就说得通了

怎么解决？

nginx以高并发闻名，怎么偏偏默认不支持并发？

谷歌找了很多关于nginx并发的文章，挨个儿尝试设置，全都以失败告终

WTF！？这是闹哪样？该加该改的都弄了，理论上并发能力爆棚了啊

又是一番呕心沥血的谷歌，终于让我找到了答案——

Windows下PHP_FCGI_CHILDREN无效

（具体参见PHP BUG#49859）

一般情况下Windows下Nginx的配置都是fastcgi_pass 127.0.0.1:9000;

也就是说cgi根本不会自动产生新进程去处理并发请求，只能排队

那要怎么办？既然不能自动生成，那就只好手动咯

动手解决

我准备额外启动3个php-cgi去处理并发请求

首先在nginx.conf中进行如下配置：

upstream phpfastcgi_proxy {
    server 127.0.0.1:9000;
    server 127.0.0.1:9001;
    server 127.0.0.1:9002;
    server 127.0.0.1:9003;
		# 或更多……
}

再把所有

fastcgi_pass 127.0.0.1:9000;

改为

fastcgi_pass phpfastcgi_proxy;

保存，重启Nginx。

现在，Nginx会自动将请求转发给9000-9003其中一个空闲端口中
接下来我们还需要启动对应数量的php-cgi去监听端口

快捷键Win+R打开运行，输入cmd进入命令行，录入以下代码：

E:/php/php-cgi.exe -b 127.0.0.1:9001 -c E:/php/php.ini

（其中路径部分需要换为你本机实际路径）

回车后看似没反应，任务管理器中会发现多了一个php-cgi进程，netstat -a也能够看到9001端口被监听了

注意不要把命令行关掉了，而是要继续打开一个新的命令行

此时你已成功了一次，你还需要继续成功两次才能监听到9002和9003……

额外的3个php-cgi进程启动成功后，你就拥有了一个并发数为4的本地环境

诶呀妈，不就想整个并发，真累人……

（后来还写了个小程序专门用来自动启动3个php-cgi进程，省事儿多了）

后记

并发问题看似是终于解决了

为啥说“看似”呢？因为在后来的实际测试中，自己启动的php-cgi似乎不稳定啊，将近有50%的几率会挂掉，导致接口返回内容依然为空，很奇怪啊不明觉厉，是不是我哪里配置错了呢？

至此我已经在这个问题上折腾了好几个小时了，再折腾下去我老大估计要打我了。算了，辣鸡Windows！我只好启动了尘封已久的Ubuntu虚拟机……如果广大读者有明白这个问题的，还望不吝赐教，谢谢