Reactor 設計パターンは、サービスを処理するためのイベント処理パターンです。リクエストは 1 つ以上の入力によってサービス ハンドラーに同時に配信されます。その後、サービス ハンドラーは受信したリクエストを逆多重化し、関連するリクエスト ハンドラーに同期的にディスパッチします。
Reactor パターンは、リアクター設計パターンとも呼ばれます。 1 つ以上のサービス ハンドラーに同時に送信されたサービス リクエストを処理するためのイベント設計パターンです。リクエストが到着すると、これらのリクエストは逆多重化され、サービスプロセッサを介して対応するリクエストプロセッサに分配されます。 Reactor パターンは、下図に示すように、主に 2 つのコア部分で構成されています: Reactor と Handler は次の役割を担います:
#Reactor: 監視と配布を担当します。イベント、イベント タイプ 接続イベント、読み取りおよび書き込みイベントが含まれます;
ハンドラー: 読み取り -> ビジネス ロジック (デコード コンピューティング エンコード) -> 送信などのイベントの処理を担当します。
ほとんどのシナリオでは、ネットワーク リクエストの処理には次の手順があります。
① 読み取り: ソケットからデータを読み取ります。
② decode: デコード、ネットワーク上のデータはバイト形式で送信されますが、実際のリクエストを取得するには、
③ compute: 計算、つまり業務処理をデコードする必要があります。
④ encode: エンコード。ネットワーク上のデータはバイト形式で送信されます。つまり、ソケットはバイトのみを受信するため、エンコードが必要です。
⑤ send: 応答データの送信
Reactor モードの場合、イベントがサーバーに入力されるたびに、サービス ハンドラーはそれを転送 (ディスパッチ) します。対応するハンドラーは次のとおりです。加工された。 Reactor モデルで定義されている 3 つの役割:
Reactor は、イベントの監視と配布、およびイベントの対応するハンドラーへのディスパッチを担当します。新しいイベントには、接続確立準備完了、読み取り準備完了、書き込み準備完了などが含まれます。
Acceptor: コネクタに新しいクライアント接続を処理するよう要求します。 Reactor はクライアントから接続イベントを受信すると、それを Acceptor に転送します。Acceptor はクライアントの接続を受け取り、対応するハンドラーを作成し、このハンドラーを Reactor に登録します。
ハンドラー: リクエスト プロセッサ。イベント処理を担当し、自身をイベントにバインドし、ノンブロッキング読み取り/書き込みタスクを実行し、チャネル読み取りを完了し、ビジネス ロジックの処理完了後にチャネルから結果を書き込みます。 . .利用可能なリソースプールを管理できます。
モデルはおおよそ次の図に示されているとおりです。
読み取り/書き込みリクエストの場合、Reactor モデルは次のように処理されます。プロセス:
(1) アプリケーションは読み取り/書き込み準備完了イベントと関連するイベント ハンドラーを登録します
(2) イベント デマルチプレクサーは待機します
に焦点を当てます。 # (1) Reactor スレッドは select Event でリッスンし、イベントを受信後、Dispatch を通じて配信します。
(2) 接続確立イベントの場合、イベントは Acceptor に配信されます。アクセプターは、accept() メソッドを通じて接続を取得し、後続の応答イベントを処理するための Handler オブジェクトを作成します。
(3) それが IO 読み取りおよび書き込みイベントの場合、Reactor はイベントを次のユーザーに渡します。処理のために現在接続されているハンドラー
(4) ハンドラーは、読み取り -> ビジネス処理 -> 送信のビジネス プロセス完了を完了します
1.2. 利点と欠点:
① パフォーマンス: コード内ではコンポーネントのみが区別されます。全体的な動作は依然としてシングルスレッドであり、CPU リソースを十分に活用できません。また、Handler のビジネス処理部分は非同期ではありません。Reactor は、接続要求の処理を担当します。読み取りおよび書き込み要求の処理も担当します。一般に、接続要求の処理は非常に高速ですが、読み取りおよび書き込み要求の処理にはビジネス ロジック処理が含まれるため、比較的低速です。 Reactor は読み取りおよび書き込みリクエストを処理するため、他のリクエストはブロックされ、システム パフォーマンスのボトルネックに簡単につながる可能性があります。
② 信頼性: Reactor スレッドが予期せず中断されたり、無限ループに入ったりすると、その結果、システム通信モジュール全体が利用できなくなり、外部メッセージを受信して処理できなくなり、ノード障害が発生します。コンピューティング集約型のシナリオに適しており、ビジネスで非常に高速なシナリオを処理する場合にのみ適しています。 Redisのスレッドモデルは、シングルReactorのシングルスレッドモデルに基づいて実装されており、Redisの業務処理は主にメモリ上で完結するため動作速度が非常に速く、性能のボトルネックがCPUに依存しないため、Redisはコマンドを高速に処理します。単一プロセス。
シングル Reactor シングルスレッド モデルのパフォーマンス上の問題を解決するために、シングル Reactor マルチスレッド モデルが進化しました。イベントプロセッサ部分で使用 マルチスレッド (スレッドプール)
(2) 接続確立イベントの場合、イベントはアクセプターに配布され、アクセプターは accept() メソッドを通じて接続を取得し、後続の応答イベントを処理するハンドラー オブジェクト
# (3) IO 読み取りおよび書き込みイベントの場合、Reactor は処理のために現在の接続に対応するハンドラーにイベントを渡します
( 4) 単一の Reactor シングル スレッドとは異なり、Handler は特定の業務処理を行わず、イベントの受信と応答のみを担当し、read によってデータを受信した後、そのデータは後続の Worker スレッド プールに送信されて業務処理が行われます。
(5) Worker スレッド プールは業務処理用のスレッドを割り当て、完了後に応答結果を Handler に送信して処理します。
(6) 応答結果を受信したハンドラは、send によりクライアントに応答結果を返します。
2.2. 長所と短所:
最初のモデルと比較すると、ビジネス ロジックの処理後、つまり IO 読み取りおよび書き込みイベントを取得した後、スレッド プールに引き渡されます。応答を受信した後、応答結果は送信を通じてクライアントに返されます。これにより、Reactor のパフォーマンスのオーバーヘッドが削減され、イベントの配信に集中できるようになり、アプリケーション全体のスループットが向上します。さらに、ハンドラーはマルチスレッド モードを使用して CPU のパフォーマンスを最大限に活用します。ただし、このモデルには問題があります:
(2) 単一の Reactor がすべてのイベントの監視、配布、および応答を担当します。これにより、同時実行性の高いシナリオではパフォーマンスのボトルネックが簡単に発生する可能性があります。
3. マスター/スレーブ Reactor マルチスレッド モデル:
単一 Reactor マルチスレッド モデルは、Handler のシングルスレッド パフォーマンスの問題を解決しますが、Reactor は依然としてシングルスレッドであり、高同時実行シナリオのパフォーマンスがまだボトルネックであるため、Reactor をマルチスレッド モード (次に紹介するマスター/スレーブ Reactor マルチスレッド モデル) に調整する必要があります。マスター/スレーブ Reactor マルチスレッド モデルでは、Reactor は 2 つの部分に分割されます
(2) SubReactor: イベントの読み取りおよび書き込みを担当し、独自のセレクターを維持し、MainReactor によって登録された SocketChannel に基づいて IO 読み取りおよび書き込みイベントのマルチチャネル分離を実行します。 、ネットワーク データの読み書き、およびビジネス処理の引き継ぎは、ワーカー スレッド プールによって行われます。 SubReactor の数は通常 CPU の数と同じです
3.1. 処理の流れ:
(1) メインスレッドの MainReactor オブジェクトがリッスンしますselect を通じてイベントに配信されます。イベントを受信後、Dispatch を通じて配信されます。イベント タイプが接続確立イベントの場合は、接続確立のためにアクセプターに配信されます。接続確立:① メイン スレッド プールから Reactor スレッドをアクセプター スレッドとしてランダムに選択し、リスニング ポートをバインドし、クライアント接続を受信します。
② アクセプター スレッドは、クライアント接続要求を受信した後、新しい SocketChannel を作成し、メイン スレッド プールに登録します。他の Reactor スレッドでは、アクセス認証、IP ブラック/ホワイト リスト フィルタリング、ハンドシェイク、その他の操作を担当します。
③ ②が完了すると、正式にビジネス層のリンクが確立されますので、メインスレッドプールのReactorスレッドのマルチプレクサからSocketChannelを削除し、SubReactorスレッドプールのスレッドに再登録し、 Handler を作成します。各種接続イベントの処理に使用します。##(2) 受信したイベントが接続確立イベントでない場合は、SubReactor に配信され、SubReactor は現在の接続に対応する Handler を呼び出して処理します
(3) Handler が read を渡す データの読み込み後、業務処理用の Worker スレッドプールにデータを配布し、Worker スレッドプールが業務処理用のスレッドを割り当て、完了後、応答結果を Handler## に送信します
# (4) Handler は応答結果を受信後渡し、send は応答結果を Client に返す3.2、メリットとデメリット: マスタースレーブ Reactor マルチのメリット-スレッド モデルでは、メイン スレッドとサブスレッドが明確に分業されており、メイン スレッドは新しい接続の受信のみを担当し、サブスレッドは後続のビジネス処理を完了する責任を負います。メインスレッドとサブスレッドのやり取りも非常にシンプルで、サブスレッドはメインスレッドから接続を受け取った後は業務の処理を行うだけで、メインスレッドを意識する必要はありません。結果はサブスレッドでクライアントに直接送信できます。 この Reactor モデルは、同時実行性の高いシナリオに適しており、Netty ネットワーク通信フレームワークもこの実装を採用しています。 4. Reactor の長所と短所: (1) 高速Reactor 自体はまだ同期されていますが、単一の同期時間によってブロックされる必要はありません。(2) は、複雑なマルチスレッドと同期の問題を最大限に回避し、マルチスレッド/プロセスの切り替えを回避できます。オーバーヘッド(3) スケーラビリティ、Reactor インスタンスの数を増やすことで簡単に CPU リソースを最大限に活用できます; (4) 再利用性、Reactor モデル自体は特定の機能とは関係ありませんイベント処理ロジックを備えており、再利用性が非常に高いです。
以上がJava IO における Reactor ネットワーク モデルの概念とは何ですかの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。