swooleの知識ポイントを詳細に整理（要約共有）-Swoole-php.cn

この記事では、子プロセスに配布するために swoole マスタープロセスにリクエストする fastcgi など、swoole に関する関連知識を提供しますが、使用後に終了する php-fpm 子プロセスやその他の関連問題とは異なります。助けなければなりません。

swooleの知識ポイントを詳細に整理（要約共有）

#推奨学習:

swoole ビデオチュートリアル

##swooleチャットルームプロセスの説明

##チャットルームプロセス全体は次のとおりです:

#- ユーザーの http インターフェイスへのログインが承認されています

# -許可されたリクエスト http インターフェース

# # を通じて、友達リスト、さまざまな友達の最後の未読メッセージ、および未読メッセージの数 (ホームページ表示用) を取得します。 ##- 承認リクエストを通じてグループリストを取得します (ストレージスペースを節約するために、グループメッセージは既読または未読になりません)

- ws を作成しますlink

- 切断と再接続のメカニズムを登録します。close イベントがトリガーされると、ws# # が再接続されます。

#- ping タイマーを設定し、30 秒ごとに ping を送信します

## - ws インターフェイスを通じて、すべての未読メッセージが取得され、クライアントによって処理され、通知バーなどにプッシュされます。

##-新しいメッセージのプッシュを受信し、メッセージリストに表示します。

#- グループ/友達のメッセージインターフェイスをクリックすると、自動的に最新の n 個のメッセージを取得すると、ユーザーはプルアップ時に引き続き n 個のメッセージを取得します

## 実行モード操作

#cgi プロトコルモード

cgi モード Common Gateway Interface (共通ゲートウェイインターフェイス)。サーバーに特定のプロトコルを渡すアプリケーションと通信するための呼び出し原則は、大まかに次のとおりです。

ユーザーリクエスト -> Web サーバーがリクエストを受信 -> 子プロセスをフォーク

プログラムを呼び出す/プログラムを実行 -> プログラムがコンテンツを返す/プログラムの呼び出しが終了 -> Web サーバーがコンテンツを受信 -> ユーザーに戻る

ユーザーリクエストごとにフォークしてプロセスを作成する必要があるため、プログラムを一度呼び出してからプロセスを破棄するため、パフォーマンスが低下します

#fast-cgi プロトコルモード

##fast-cgi は、cgi モードのアップグレードバージョンです。 like 常駐 CGI です。オンになっている限り、プロセスを終了することなく常にリクエストを処理できます。呼び出し原理は大まかに次のとおりです。

Web サーバーの高速 CGI プロセスマネージャーの初期化 - > 事前に n 個のプロセスをフォークします

ユーザーリクエスト - > Web サーバーがリクエストを受信 - > fast-cgi プロセスマネージャーに渡す - > fast-cgi プロセス管理領域がリクエストを受信し、いずれかのプロセスに渡すfree fast-cgi プロセスの処理 -> 処理が完了し、fast-cgi プロセスはアイドル状態になり、次のリクエストを待機します -> Web サーバーがコンテンツを受信します -> ユーザーに戻りますモジュールモード

モジュールモード

Apache php が実行されているとき、モジュールモードはデフォルトで使用され、php を Apache として使用します。モジュールは、Apache の開始時に開始されます。ユーザーリクエストが受信されると、mod_php モジュールを呼び出して直接処理されます。詳細は、Baidu で確認できます。

##php-cli モード

##php-cli モードはコマンドラインモードに属します。これは、PHP の学習を開始し、wamp と wnmp を始めたばかりの多くの開発者に最適です。馴染みのない操作モード

このモードでは、他のモードを使用する必要はありません。プログラムの場合、php xx.php と直接入力して php コードを実行できます

コマンドラインモードは、次の場合に通常の Web モードとは明らかに異なります。

#* STDIN および STDOUT の標準入出力/エラーの使用
#* echo var_dump、phpinfo などの出力が直接出力されます。コンソールに移動します。
* 使用できるクラス/関数が異なります
#* php.ini 設定の違い
php-fpm

PHP-FPM (FastCGI プロセスマネージャー) はPHP FastCGI の追加機能のほとんどを置き換えるために使用され、高負荷の Web サイトに非常に役立ちます。その機能は次のとおりです。

スムーズな停止/開始をサポートする高度なプロセス管理機能;

さまざまな uid/gid/chroot 環境で動作し、さまざまなポートをリッスンし、さまざまな php.ini 設定ファイルを使用できます (safe_mode 設定を置き換えることができます)。
ファイルアップロードの最適化サポート;
「スローログ」 - スクリプトを記録します (ファイル名を記録するだけでなく、PHP バックトレース情報も記録します。ptrace または同様のツールを使用して、実行中のログを読み取り、分析できます)リモートプロセスのデータ) 実行による異常な遅さ;
fastcgi_finish_request() - 特別な関数: リクエストが完了した後、バックグラウンドで時間のかかる作業 (ビデオ入力変換、統計処理など) を実行し続けるために使用されます。データが更新されます;
動的/静的サブプロセスの生成;
基本的な SAPI 実行ステータス情報 (Apache の mod_status と同様);
php.ini に基づく設定ファイル。
動作原理:

おおよその動作原理開始for:php-fpm->n 個の高速 CGI プロトコル処理プロセスを生成します->ポートをリッスンしてタスクを待機しますユーザーリクエスト->Web サーバーはリクエストを受信します->gt ; リクエストは php-fpm に転送されます->php-fpm は処理のためにアイドルプロセスに渡されます#->プロセスの処理が完了します->php-fpm は Web サーバーに戻ります- >Web サーバーがデータを受信します-> ユーザーに戻る

ネットワークプロトコル

ネットワークプロトコルはルールですコンピュータネットワークでのデータ交換のために確立された標準、または一連の協定。コンピュータ/携帯電話と他のネットワークデバイス間のすべての通信は、ネットワークプロトコルに準拠する必要があります。

ネットワークプロトコルは通信の段階に応じて7つのレベルに分かれており、上から

##アプリケーション層
#プレゼンテーション層
セッション層
トランスポート層
ネットワーク層
データリンク層
物理層

ip プロトコル (ネットワーク層)

IP プロトコルはインターネットの基本プロトコルであり、現在最も人気のあるネットワークプロトコルです

スコープ

IP の責任は、送信元から宛先にデータを送信することです。配信の信頼性、フロー制御、パケットの順序付け、およびホスト間プロトコルに共通するその他のサービスを保証する責任はありません。＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃インターフェース＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃

##このプロトコルはホスト間プロトコルによって呼び出され、ローカルネットワークプロトコルを呼び出してデータパケットを次のゲートウェイまたは宛先ホストに送信する役割を果たします。たとえば、TCP は IP プロトコルを呼び出し、呼び出し時に宛先アドレスと送信元アドレスをパラメーターとして渡します。IP はデータパケットを形成し、ローカルネットワーク (プロトコル) インターフェイスを呼び出してデータパケットを送信します。

#操作

IP は、アドレス指定とセグメンテーションという 2 つの基本機能を実装します。 IPは、データパケットのヘッダに含まれる宛先アドレスに基づいて、その宛先アドレスにデータパケットを送信することができますが、この際の伝送経路の選択をIPが担っており、この経路選択をルーティング機能と呼びます。一部のネットワークが小さなデータパケットしか送信できない場合、IP はデータパケットを再組み立てし、ヘッダーフィールドでこれを示すことができます。これらの基本機能は、ネットワーク内のすべてのホストとゲートウェイに存在する IP モジュールに含まれており、これらのモジュール (特にゲートウェイ上) にはルーティング機能やその他のサービス機能があります。 IP の場合、データパケット間に接続はなく、IP の接続や論理リンクについて何かを言うのは困難です。

IP は、サービスタイプ、存続時間、オプション、ヘッダーチェックコードという 4 つの主要なテクノロジーを使用してサービスを提供します。サービスの種類とは、期待されるサービスの品質を指します。サービスタイプは、インターネットが提供できるサービスを表すパラメータのセットです。このサービスタイプは、特定のネットワーク上、通過する次のネットワーク上、またはこのパケットをルーティングする次のゲートウェイ上の実際の配信パラメータを選択するためにゲートウェイによって使用されます。生存時間は、パケットが存続できる期間の上限です。これは送信者によって設定され、ルートによって処理されます。到着しないときに存続時間がゼロの場合は、パケットを破棄します。このオプションは制御機能にとって重要ですが、通常の通信にはその存在は必要ありません。オプションには、タイムスタンプ、セキュリティ、特別なルーティングが含まれます。ヘッダーチェックコードにより、データの正しい送信が保証されます。チェックが失敗した場合、パケット全体が破棄されます。＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃IPアドレス＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃

データを送信元から宛先に送信する場合、送信には IP アドレスが必要です。現在、IP アドレスは IPv4 と IPv6 の 2 種類に分類されています。現在最も一般的なのは、127.0.0.1 ( など) の IPv4 アドレスです。このマシンのアドレス) 119.75.217.109 (Baidu ip)ip 送信には、データを送信する前に明確な IP アドレスが必要です

tcp (伝送層)

TCP (伝送制御プロトコル) 接続ですIETF の RFC 793 によって定義された、信頼性の高いバイトストリームベースのトランスポート層通信プロトコル。簡略化されたコンピュータネットワーク OSI モデルでは、第 4 層のトランスポート層で指定された機能を実現します。ユーザーデータグラムプロトコル (UDP) は、同じ層内のもう 1 つの重要なトランスポートプロトコルです。インターネットプロトコルスイートにおいて、TCP 層は、IP 層の上、アプリケーション層の下に位置する中間層です。多くの場合、異なるホストのアプリケーション層間には信頼性の高いパイプのような接続が必要ですが、IP 層はそのようなフローメカニズムを提供せず、信頼性の低いパケットスイッチングを提供します。

#アプリケーション層は、ネットワーク間送信用の 8 ビットバイトで表されるデータストリームを TCP 層に送信し、次に TCP 層に送信します。データストリームは、適切な長さのセグメントに分割されます (通常、コンピュータが接続されているネットワークのデータリンク層の最大伝送単位 (MTU) によって制限されます)。次に、TCP は結果のパケットを IP 層に渡し、IP 層はそのパケットをネットワーク経由で受信エンティティの TCP 層に配信します。 TCP では、パケット損失が発生しないように各パケットにシーケンス番号を付与すると同時に、受信側エンティティに送信されたパケットが順番に受信されることを保証します。次に、受信側エンティティは、正常に受信されたパケットに対する対応する確認応答 (ACK) を送り返します。送信側エンティティが妥当な往復遅延 (RTT) 以内に確認応答を受信しない場合は、対応するデータパケットが受信されたものとみなされます。再送信されます。 TCP では、チェックサム機能を使用してデータにエラーがないかどうかをチェックし、送信時と受信時にチェックサムを計算します。

#スリーウェイハンドシェイク

##TCP は、インターネットのトランスポート層プロトコルであり、3 ウェイハンドシェイクプロトコルを使用して接続を確立します。アクティブなパーティが SYN 接続要求を送信すると、相手が SYN ACK で応答するのを待ち、最後に相手の SYN に対して ACK 確認を実行します。この接続方法により誤接続を防ぐことができ、TCP で使用されるフロー制御プロトコルは可変サイズのスライディングウィンドウプロトコルです。 TCP 3 ウェイハンドシェイクのプロセスは次のとおりです。

クライアントは SYN (SEQ=x) メッセージをサーバーに送信します。そしてSYN_SEND状態に入ります。
#サーバーは SYN メッセージを受信し、SYN (SEQ=y) ACK (ACK=x 1) メッセージで応答し、SYN_RECV 状態に入ります。
クライアントはサーバーから SYN メッセージを受信し、ACK (ACK=y 1) メッセージで応答し、確立状態に入ります。

#接続に成功しました

接続が成功すると、双方が相互にバイトストリームを送信できるようになり、いつでも接続を閉じることができます。送信されるデータには次の特性があります。

#4 回手を振ります

接続の確立には 3 回のハンドシェイクが必要で、接続の終了には 4 回のウェーブが必要ですが、これは TCP のハーフクローズが原因です。具体的なプロセスは以下の通りです。

# アプリケーションプロセスは最初に close を呼び出します。これは、「アクティブクローズ」を実行すると言われます。次に、その側の TCP は、データが送信されたことを示す FIN セグメントを送信します。
この FIN を受信したピアは「パッシブクローズ」(パッシブクローズ) を実行し、この FIN は TCP によって確認されます。
注: FIN の受信は、ファイルの終わりとして受信アプリケーションプロセスにも渡され、アプリケーションプロセスが受信するのを待つキューに置かれます。 FIN の受信は、受信アプリケーションプロセスに対応する接続で受信する追加データがないことを意味するため、他のデータの後。
#しばらくすると、このファイルの終わり文字を受け取ったアプリケーションプロセスは close を呼び出してソケットを閉じます。これにより、TCP も FIN を送信します。
この最終 FIN を受信する元の送信側 TCP (つまり、アクティブシャットダウンを実行する側) は、この FIN を確認します。各方向に FIN と ACK が必要なため、通常は 4 つのセグメントが必要です。

「通常」とは、ステップ 1 の FIN がデータと一緒に送信される場合があることを意味します。また、ステップ 2 と 3 で送信されるセグメントも送信されます。パッシブシャットダウンを行う側からは両方をセクションにマージすることが可能です。手順 2 と 3 の間では、パッシブシャットダウンを実行する側からアクティブシャットダウンを実行する側にデータを流すことができます (これを「ハーフクローズ」と呼びます)。 Unix プロセスが自発的 (exit の呼び出しまたはメイン関数からの戻り) または非自発的 (プロセスを終了するシグナルの受信) で終了すると、開いている記述子はすべて閉じられ、その結果 TCP が開いたままになります。FIN も発行されます。接続。クライアントまたはサーバーのいずれかがアクティブシャットダウンを実行できます。通常、クライアントはアクティブシャットダウンを実行しますが、HTTP/1.0 などの一部のプロトコルでは、サーバーがアクティブシャットダウンを実行します。 tcp の

#phpphp には、次の方法でアクセスできます。ソケット関数、swoole 拡張機能、ストリームフロー関数は、tcp プロトコルのソケットを作成し、ネットワークカードポートをバインドし、tcp サーバー/クライアントの操作を実行します。php では、tcp ハンドシェイク/ウェービングを知る必要はありません。 ip:port を知っている TCP サーバー/クライアントに接続/作成できることだけです

PHP のソケットを使用すると、文字列を直接送信したり、文字列を受信したりできます。その他はすべて言語とオペレーティングシステムが行う必要があることです。

文字列の整合性を処理するだけで済みます。たとえば、tcp サーバーとして php を使用します

# #プロセス分析

##http リクエストのプロセスは大まかに次のとおりです。

ユーザーがブラウザにを入力します www.easyswoole.com

DNS サーバー分析/またはローカルホスト、ルーターホストの比較による IP
ブラウザがデフォルトのポート 80 にアクセスする場合、アクセスされる TCP アドレスは ip:80 です。
tcp プロトコル 3 ウェイハンドシェイクによる接続確立
http リクエストリクエストヘッダーを送信する
サーバーは、アクセスが http アクセスであることを示す http リクエストリクエストヘッダーを取得し、http リクエストヘッダーを解析して、リクエストタイプ、リクエストフォーマット、およびリクエストデータを取得します。 (Cookie、データの取得、投稿)
サーバーは応答応答データを送信し、積極的に切断します
ブラウザは応答データを受信し、応答テキストタイプを解析し、データを解析して切断します。

https プロトコルでは、リクエストと応答に tls および ssl の暗号化および復号化プロトコルの追加レイヤーがあり、デフォルトのポートが 80 から 443 に変更されました。 phper の

#http

によるほとんどの場合、PHP は Web サーバーに使用されるため、PHP 開発者が最もよく使用するプロトコルは、TCP/IP プロトコルに基づく HTTP プロトコルです。 HTTP プロトコルについては理解している必要がありますが、ブラウザの f12->ネットワークを使用して、http プロトコルの特定の要求ヘッダーとサーバーによって送信された応答ヘッダーを表示できます

WebSocket プロトコル＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃背景＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃

##WebSocket プロトコルが存在する前は、Web ページにチャットルームを実装する唯一の方法は、ajax を使用して、サーバーにデータが生成されているかどうかを継続的にポーリングおよびリクエストすることでした。

ポーリング間隔が短すぎる場合、クライアントとサーバーは http を実行し続けます。一定期間内の TCP ハンドシェイク。/手を振る動き、http リクエストヘッダーとレスポンスヘッダーの送信は、多くのサーバーリソースを消費します。ユーザーの数が多い場合、サーバーはビジー状態になり、場合によってはダウンします。 #クライアントは、毎回 http リクエストを送信することでサーバーに返すデータがあるかどうかを取得することしかできず、データの適時性は保証できません

この状況のため、WebSocket が登場しました。維持するために必要なのは 1 回の http ハンドシェイクだけです。長い接続により、サーバーは次のことを行うことができます。メッセージをクライアントに積極的に送信し、ポーリングメカニズムの消費を大幅に削減します

#実装原則

。 WebSocket API では、ブラウザとサーバーはハンドシェイクアクションを実行するだけで、ブラウザとサーバーの間に高速チャネルが形成されます。両者は相互にデータを直接送信できます。この WebSocket プロトコルでは、リアルタイムサービスを実現するために 2 つの大きな利点がもたらされます:

ヘッダー: 相互に通信するヘッダーは非常に小さい -約 2 バイト

サーバープッシュ: サーバープッシュ。サーバーは、データを返す前にブラウザーのリクエストを受動的に受信するのではなく、新しいデータがあるときにブラウザーにアクティブにプッシュします。

udp(トランスポート層)

UDP は User Datagram Protocol の略称です。中国語名は User Datagram Protocol です。OSI (Open System Interconnection) 参照モデルのコネクションレス型トランスポート層プロトコルであり、シンプルで信頼性の低いトランザクション指向のメッセージ転送サービスを提供します。 IETF RFC 768 は UDP の正式な仕様です。 IP パケットの UDP のプロトコル番号は 17 です。
UDP プロトコルの正式名は User Datagram Protocol で、ネットワーク内で TCP プロトコルと同様にデータパケットを処理するために使用されます。 . コネクションレス型プロトコルです。 OSI モデルでは、4 番目の層であるトランスポート層が IP プロトコルの上位層になります。 UDP には、データパケットのグループ化、アセンブリが提供されておらず、データパケットの並べ替えができないという欠点があります。つまり、メッセージが送信された後、メッセージが安全かつ完全に到着したかどうかを知ることが不可能です。 UDP は、コンピュータ間でデータを送信する必要があるネットワークアプリケーションをサポートするために使用されます。ネットワークビデオ会議システムを含む多くのクライアント/サーバーネットワークアプリケーションでは、UDP プロトコルの使用が必要です。 UDP プロトコルは、その誕生以来長年にわたって使用されており、その初期の栄光はいくつかの同様のプロトコルによって影が薄くなりましたが、今日でも非常に実用的で実現可能なネットワークトランスポート層プロトコルです。

よく知られている TCP (伝送制御プロトコル) プロトコルと同様、UDP プロトコルは IP (インターネットプロトコル) プロトコルのすぐ上にあります。 OSI (Open Systems Interconnection) 参照モデルによれば、UDP と TCP は両方ともトランスポート層プロトコルです。 UDP プロトコルの主な機能は、ネットワークデータトラフィックをデータパケットに圧縮することです。一般的なデータパケットは、バイナリデータの送信単位です。各データパケットの最初の 8 バイトはヘッダー情報を含めるために使用され、残りのバイトは特定の送信データを含めるために使用されます。

udp と tcp

udp と tcp は両方ともトランスポート層プロトコルに属し、ip プロトコルの最上位層に位置します。それらの違いは次のとおりです:

#udp はコネクションレス型プロトコルであり、TCP ハンドシェイクを必要としません
udp が一度に送信する最大長は 65535 ですが、tcp はハンドシェイク後に継続的に送信できます
#udp プロトコルは、ヘッダー内のチェック値を使用してデータのセキュリティを確保します。チェック値は、データ送信側で特別なアルゴリズムによって最初に計算され、受信側に渡された後に再計算する必要があります。データグラムが送信中に第三者によって改ざんされたり、回線ノイズなどによりデータグラムが破損した場合、送信側と受信側のチェックサム計算が一致しないため、UDP プロトコルはエラーがあるかどうかを検出できます。これは、チェック値を必要とする TCP プロトコルとは異なります。
Udp メッセージには信頼性保証、順序保証、フロー制御フィールドなどが無く、信頼性が低いです。しかし、UDPプロトコルは制御オプションが少ないからこそ、データ伝送時の遅延が少なく、データ伝送効率が高く、高い信頼性を必要としないアプリケーションや、DNSなどの信頼性を保証できるアプリケーションに適しています。、TFTP、およびSNMP。お待ちください。
#ネットワーク品質が非常に悪い環境では、UDP プロトコルのパケット損失がより深刻になります。 TCP は、相手が正常に受信したことを確認するために確認検証を実行します。
udp はゲートウェイ内のすべてのホストにブロードキャストできます

PHP マルチ-プロセス

マルチプロセスの概念前にも述べたように、マルチプロセスは主にビジネスロジックレベルの開発を行い、複数のタスクを並行して処理するために使用されますビジネスロジックレベルの開発とは何ですか?

上で述べたphp-fpmです。 fast-cgi のプロセスマネージャー。起動後、複数の fast-cgi プロセスが起動され、タスクの処理を待ちます。

php-fpm ソフトウェアレベルでは、fast-cgi の複数のプロセスこれはマルチプロセス処理に属しますが、ユーザーがリクエストを開始し、

# が処理のために nginx によって php-fpm に渡されると、この時点で各リクエストは、実際にはロジック処理用の php fast-cgi プロセスのみを占有します。ビジネスロジックを実行する php プロセスは、実際には単一のプロセスです。

同様に、php ファイルを直接実行する場合、デフォルトでは、php コードを実行するために 1 つの php プロセスのみが開かれます

詳細プロセス開発シナリオ

従来の Web モードでは、PHP は常に単一プロセスでビジネスロジックを処理していました。 PHP - cli モードでは、非同期タスクを処理するために使用されます。ネットワークサーバーとして機能する場合、マルチプロセス処理が可能です。そのため、ほとんどの PHP 使用者は、php マルチプロセスの概念に慣れていません

##pcntl 拡張機能を使用する

##プロセス通信

パイプ通信は名前付きパイプ、名前なしパイプなどに分かれています。詳細は自分で検索できます

#Linux メッセージキューを使用したメッセージキュー通信は、sysvmsg 拡張機能を介して表示できます。
プロセス信号通信を表示できます:
共有メモリ通信は、他のプロセスがアクセスできるメモリのセクションをマップします。この共有メモリは 1 つのプロセスによって作成されますが、複数のプロセスによってアクセスできます。
#共有メモリは最速の IPC 方式であり、他のプロセス間通信方式の動作効率の低さを考慮して特別に設計されています。
#プロセス間の同期と通信を実現するために、シグナルなどの他の通信メカニズムと組み合わせて使用されることがよくあります。
ソケット通信
サードパーティ通信は、ファイル操作、mysql、redis、その他の方法を使用して実現することもできます

Coroutine

#コルーチンはプロセスやスレッドではなく、その実行プロセスはサブルーチン、つまり戻り値のない関数呼び出しに似ています。

プログラムには複数のコルーチンを含めることができ、複数のスレッドを含むプロセスと比較できるため、以下でコルーチンとスレッドを比較してみましょう。

複数のスレッドは比較的独立しており、独自のコンテキストを持ち、切り替えはシステムによって制御され、コルーチンも比較的独立していることがわかっています。

独自のコンテキストがありますが、その切り替えはそれ自体で制御され、現在のコルーチンから他のコルーチンへの切り替えは現在のコルーチンによって制御されます。

#コルーチンとプロセス

上記のコード 2

コルーチン実行シーケンスから、簡単に次のようになります。コルーチンは実際にはプロセス内で実行されている単なる関数であることがわかりましたが、この関数はいわば次の実行に切り替わります: コルーチンはプロセス内で実行される単なる一連のタスクコードですが、これらのタスクコードはクロスワイズで実行できます。コルーチンは並列マルチタスクではなく、直列マルチタスクであることに注意してください。各プロセスは一度に 1 つのタスクのみを実行します

コルーチンのスコープ

コルーチンプロセス内にあるタスクコードの文字列なので、そのグローバル変数、静的変数、およびその他の変数は、php のグローバルバッファーを含めてすべて共有されます。コルーチン内のグローバル変数、静的変数、1 つのコルーチンが変更される限り、すべてのコルーチンに影響します。ob バッファー関数を使用してインターセプトする場合は、他のコルーチンの出力によって汚染されるかどうかも考慮する必要があります。使用コルーチン実行シーケンスコード 2 は、task1 が $_GET['name'] に値 1 を割り当てると、task2 が $_GET['name'] を読み取って、それも 1 になることを説明しています。 task2 $_GET['name'] に値 2 が割り当てられると、task3 は $_GET['name'] を読み取り、これも 2

I になります。コルーチン /O 接続内

##コルーチンでは、I/O 接続を共有しないように特別な注意を払う必要があります。コルーチン実行シーケンス

のコード 2 を使用して、task1 関数と task2 関数が mysql を共有する場合を説明します。このとき、コルーチンは交差して実行されるため、タスク 1 とタスク 2 がクエリしたデータをタスク 1 が取得したり、データの一部が失われタスク 2 が取得したりする可能性があります。 ##コルーチンのクロス実行メカニズムにより、各コルーチンの I/O 接続は独立している必要があるため、各コルーチンで接続を作成する必要がありますが、 mysql と redis の接続数は限られており、接続の開閉には多くのリソースが消費されるため、接続プールソリューションを使用して共有接続を実現できます (各接続で一度に 1 つのコルーチンのみが使用される場合に限ります)。推奨学習: swoole チュートリアル

以上がswooleの知識ポイントを詳細に整理（要約共有）の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。