Windows下nginx+fastcgi+php的併發阻塞問題

接到一個需求，兩個項目之間須要以接口形式通信。我心想curl輕鬆解決，Easy！
啪嗒啪嗒啪嗒……代碼擼完了，本地測試一下
瀏覽器一直轉圈圈直到超時……

Why!?

---

沒有任何錯誤提示信息，日誌也沒有任何新記錄
用POSTMAN調試了一下剛寫出的接口，沒問題啊？
再試一次結果依舊，重啓環境後再試也依舊
通過一番測試，我懷疑是否是我本地環境沒法併發？

我訪問項目是一個請求，項目訪問另外一項目的接口則是第二個請求。在沒法併發只能排隊請求的狀況下，第一個請求依賴於第二個請求的結果；第二個請求卻排在後面一直等待第一個請求執行完畢。這就致使互相依賴產生死循環，也就說得通了

怎麼解決？

---

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虛擬機……若是廣大讀者有明白這個問題的，還望不吝賜教，謝謝

本文同時刊登於個人博客 超能小紫，若是喜歡請常來玩哦