Swoole エンジンの原理を共有するための簡単な紹介-Swoole-php.cn

Swoole エンジンの原理を共有するための簡単な紹介

過去 6 か月間で、私は PHP と Java テクノロジースタックを使用したゲームサーバープロジェクトを完了しました。プロジェクトには高頻度のネットワークリクエストがあるため、PHP テクノロジスタックは、Swoole エンジン (高性能イベントベースの非同期並列ネットワーク通信エンジン) を使用して、ゲームビジネスの一部を完了しようとしました。

推奨 (無料): swoole

Swoole のインストール

Swoole のインストールは非常に簡単です。これは中国人によって行われたプロジェクトであるため、多くの問題に対する答えは公式 Web サイトのドキュメントで見つけることができます。インストールには、

コンパイルとインストールの 2 つのタイプがあります。 github または gitee に直接アクセスして正式リリースバージョンをダウンロードし、コンパイルしてインストールした後、php.ini ファイルに so 拡張子を書き込みます。
コンテナのインストール。スウールエンジンは広く使用されているため、ハブには多数のコンテナが用意されており、必要なものを選択してプルするだけです。

具体的な手順については、Baidu をクリックしてください。インターネット上には関連コンテンツがたくさんあります。

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 のスレッドまたはプロセス

##構造図は次のとおりです。

Swoole エンジンは 2 つのモードに分かれています。シングルスレッドモードとプロセスモード。この記事ではプロセスモードについてのみ説明します。 2 つの具体的な違いについては、公式ドキュメントで説明されています。

Swoole エンジンの原理を共有するための簡単な紹介

マスタープロセス

# は、クライアントやローカル通信パイプからの接続などのスウールのコアイベントを処理するために使用されます。マスタープロセスには複数のスレッドがあり、各スレッドは epol 関数のインスタンスを実行します。 (Worker プロセスは Master プロセスによってフォークされていないため、Master プロセスを強制終了しても Worker プロセスが存在する可能性があります)

Reactor スレッド

Swoole のメインプロセスは、次のようなマルチスレッドプログラムです。。 Reactor スレッドと呼ばれる非常に重要なスレッドのグループがあります。実際に TCP 接続を処理し、データを送受信するのはスレッドです。

新しい接続を受け入れた後、Swoole のメインスレッドはその接続を固定 Reactor スレッドに割り当て、このスレッドがソケットの監視を担当します。ソケットが読み取り可能なときにデータを読み取り、プロトコル分析を実行して、リクエストをワーカープロセスに配信します。ソケットが書き込み可能なときに TCP クライアントにデータを送信します。

マネージャープロセス

swoole のワーカー/タスクプロセスはすべてフォークされ、マネージャープロセスによって管理されます。
子プロセスが終了すると、マネージャープロセスは、ゾンビプロセスになるのを避けるために子プロセスをリサイクルする責任があります。そして、新しいサブプロセスを作成します。

サーバーがシャットダウンされると、マネージャープロセスはすべてのサブプロセスにシグナルを送信し、サブプロセスにサービスをシャットダウンするように通知します。

サーバーがリロードされると、マネージャープロセスはサブプロセスを 1 つずつシャットダウン/再起動します

ワーカープロセス

Swoole は完全なプロセス管理メカニズムを提供します。致命的な PHP エラーなど、ワーカープロセスが誤って異常終了した場合、他のプログラムによって強制終了されたか、max_request 数に達した後に正常に終了しました。メインプロセスは新しいワーカープロセスを再起動します。通常のapache phpやphp-fpmと同様にワーカープロセス内でコードを記述することができます。 Node.js のような非同期コールバックコードを記述する必要はありません。

#各プロセスのコールバック関数

マスターのコールバック関数:

onStart

onShutdown

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的業務代碼比較少，所以僅供參考

更多相關學習推薦：swoole教程