學習swoole的方式建議

看到不少人捨本逐末去學習一堆的基於swoole的框架，真的是沒有必要。

這些框架本質上都是swoole的api caller+composer第三方庫整合商。不是說這些框架沒有學習的價值，只是最核心的東西是swoole自己，而不是基於swoole的框架。弄明白了swoole爲啥高效的緣由，這些框架信手拈來就能夠用，本身開發一個並不是難事。

傳統的phpfpm的工做方式，nginx+phpfpm，nginx轉發給phpfpm，phpfpm通常監聽9000端口，master+N個worker進程，收到nginx轉發過來的request，由master調度worker進程進行處理。咱們的請求通常是跟mysql、redis、elasticsearch、rabitmq等服務器進行交互，一堆的鏈接要創建，並且每次worker進程處理完請求都會釋放這些鏈接資源。下個請求來時，又如此周而復始。

上面的工做流程，你們很容易看出來問題，每次請求都要創建鏈接，釋放鏈接，這自己就是耗時的操做且沒有必要。再者，若是請求一個web service，好比說你去調用一個查天氣的接口，響應時間比較長時，整個worker進程是阻塞的，當N個worker進程都被阻塞時，下一個請求就沒法響應。整個系統的響應時間就會很是長。

爲了解決這兩個問題，那相應的辦法也就出來了，資源常駐內存+協程。server啓動時，創建一堆的鏈接資源，處理完請求時不釋放資源，下一次繼續複用。在訪問web service時，使用swoole提供的協程http客戶端，不阻塞進程。下一個請求進來時，swoole調度器調度下一個協程佔用CPU資源進行工做。因此說你用協程，客戶端並不會感受到訪問速度加快了，什麼意思呢？打個比方，你去銀行櫃檯辦事，傳統的方式是，櫃員一個一個來處理，上我的的事沒辦完，你就得等着。協程的方式就是，事情不禁櫃員來辦，櫃員交給其它人去辦，完了讓你一邊呆着，櫃員繼續服務下一我的，當你的事情辦完了時，辦事人通知櫃員，櫃員再叫你過來給你反饋結果。很明顯第二種方式，對辦事人而言，服務效率看起來更高一點，但實際上你等的時間是同樣的。

協程解決的IO密集型的問題，不是CPU密集型的問題。而互聯網應用95%以上的場景都是IO密集型。

因此swoole如此高效的緣由，就是由於它基本上等於nginx+go，用epoll技術hold住大量併發，鏈接資源常駐內存，再加上使用協程避免調用web service致使進程阻塞。這裏我只提web service，是由於redis、mysql服務器和應用服務器一般是同一個局域網，傳統方式其實也很是高效，不能突出協程的優點。而當你調用外網的web service時，通常響應時間會很是長，協程的優點才得以體現。

固然，這只是我的見解，並不能表明全部人，但願能帶來一些啓發。

韓大多年前寫的《PHP併發IO編程之路》

關於PHP程序員技術職業生涯規劃

學習其它語言優秀的地方，重視基礎，捨本逐末花大量時間去學習新框架，我的以爲意義不大。