更多內容，歡迎關注微信公眾號：全菜工程師小輝~
過去一年使用PHP和Java兩種技術棧完成了一個游戲服務器項目。由於項目中有高頻的網絡請求，所以PHP技術棧嘗試使用Swoole引擎（基於事件的高性能異步並行網絡通信引擎）來完成部分游戲業務。
Swoole的安裝
安裝swoole很簡單，由於是國人做的項目，很多issue可以在官網文檔找到答案。安裝分兩種：
- 編譯安裝。直接去github或者gitee去下載官方的發行版，編譯安裝后，將so拓展寫入php.ini文件。
- 容器安裝。swoole引擎應用廣泛，所以hub上有很多可用的容器，選擇需要的pull一下即可。
具體操作百度一下即可，網上相關內容很多。
Swoole引擎的優勢
- 常駐內存。傳統 PHP框架或者單文件，在處理每個請求之前，都要做一遍加載框架文件、配置的操作，請求完成之后會釋放所有資源和內存，無須擔心內存泄漏。但是如果請求數量上升，並發很高的時候，快速創建資源，又馬上釋放，會導致 PHP 程序運行效率急劇下降。而使用 Swoole 則沒有這個問題：PHP的代碼加載到內存后，擁有更長的生命周期，這樣建立的數據庫連接和其他大的對象，不被釋放。每次請求只需要處理很少的代碼，而這些代碼只在第一次運行時，被 PHP 解析器編譯，駐留內存。以后都是直接載入 OPCODE ，讓 Zend 引擎直接運行。另外，之前PHP不能實現的，如數據庫連接池，緩存連接池都可以在Swoole引擎下實現。系統的運行效率會大大提高。
- 快速開發。Swoole引擎提供了PHP語言的異步多線程服務器，異步TCP/UDP網絡客戶端，異步MySQL，異步Redis，數據庫連接池，AsyncTask，消息隊列，毫秒定時器，異步文件讀寫，異步DNS查詢。 Swoole內置了Http/WebSocket服務器端/客戶端、Http2.0服務器端。
- 協程編程模式。Swoole4可以使用完全同步的代碼實現異步程序。PHP代碼無需額外增加任何關鍵詞，底層自動進行協程調度，實現異步IO。
Swoole引擎的流程解析
Swoole運行的流程圖如下：
Swoole中的線程或進程
結構圖如下：
Swoole引擎分為兩種模式：單線程模式和進程模式。本文只討論進程模式。具體兩者區別官方文檔中有說明。
Master進程
用於處理swoole核心事件，比如來自客戶端的連接，本地通訊的管道。master進程里有多個線程，每個線程運行了一個epol函數的實例。（由於Worker進程並不是由Master進程fork出來的，所以可能會出現強行kill Master進程后，Worker進程依舊存在）
Reactor線程
Swoole的主進程是一個多線程的程序。其中有一組很重要的線程，稱之為Reactor線程。它就是真正處理TCP連接，收發數據的線程。
Swoole的主線程在Accept新的連接后，會將這個連接分配給一個固定的Reactor線程，並由這個線程負責監聽此socket。在socket可讀時讀取數據，並進行協議解析，將請求投遞到Worker進程。在socket可寫時將數據發送給TCP客戶端
Manager進程
swoole中worker/task進程都是由Manager進程Fork並管理的。
子進程結束運行時，manager進程負責回收此子進程，避免成為僵屍進程。並創建新的子進程
服務器關閉時，manager進程將發送信號給所有子進程，通知子進程關閉服務
服務器reload時，manager進程會逐個關閉/重啟子進程
Worker進程
Swoole提供了完善的進程管理機制，當Worker進程異常退出，如發生PHP的致命錯誤、被其他程序誤殺，或達到max_request次數之后正常退出。主進程會重新拉起新的Worker進程。 Worker進程內可以像普通的apache+php或者php-fpm中寫代碼。不需要像Node.js那樣寫異步回調的代碼。
各進程的回調函數
Master內的回調函數：
- onStart
- onShutdown
Worker進程內的回調函數
- onWorkerStart
- onWorkerStop
- onConnect
- onClose
- onReceive
- onFinish
TaskWorker進程內的回調函數
- onTask
- onWorkerStart
Manager進程內的回調函數
- onManagerStart
- onManagerStop
Reactor、Worker、TaskWorker的關系
可以理解為Reactor就是nginx，Worker就是php-fpm。Reactor線程異步並行地處理網絡請求，然后再轉發給Worker進程中去處理。Reactor和Worker間通過UnixSocket進行通信。
在php-fpm的應用中，經常會將一個任務異步投遞到Redis等隊列中，並在后台啟動一些php進程異步地處理這些任務。Swoole提供的TaskWorker是一套更完整的方案，將任務的投遞、隊列、php任務處理進程管理合為一體。通過底層提供的API可以非常簡單地實現異步任務的處理。另外TaskWorker還可以在任務執行完成后，再返回一個結果反饋到Worker。
Swoole的Reactor、Worker、TaskWorker之間可以緊密的結合起來，提供更高級的使用方式。一個更通俗的比喻：假設Swoole應用服務器是一個工廠，那Reactor就是銷售，接受客戶訂單。而Worker就是工人，當銷售接到訂單后，Worker去工作生產出客戶要的東西。而TaskWorker可以理解為行政人員，可以幫助Worker干些雜事，讓Worker專心工作。
底層會為Worker進程、TaskWorker進程分配一個唯一的ID。不同的Worker和TaskWorker進程之間可以通過sendMessage接口進行通信。
實際項目中的各進程線程的分工：
- Manager進程：負責管理worker進程，創建或回收
- Worker進程：游戲邏輯處理
- taskWorker進程：向客戶端發網絡包、關閉長期不活躍的tcp連接
Swoole版本兼容性
該項目開發階段使用的swoole引擎版本1.9.6，后來由於測試環境安裝成了4.3.2版本，所以嘗試業務代碼作調整。不過swoole的向下兼容很值得佩服的是，這過程中竟然只發現了一處代碼不兼容的問題：是有關swoole_server的一項配置參數，在原來版本采用了魔鬼數字進行配置的，但是到新版本，這個數字沒有被宏定義，后來通過查看swoole源碼找到了宏定義組，然后修改了這處配置。（不過版本升級順利也是基於swoole的業務代碼比較少，所以僅供參考）
