スウールはどこで使われていますか？

アプリケーション シナリオの紹介

ハードウェア デバイス (測位デバイス) との接続と通信

IM システム (ライブに使用)ブロードキャスト ページ チャット コミュニケーション) (推奨される学習:swoole ビデオ チュートリアル)

シナリオ 1 - 位置データのリアルタイム収集とリアルタイム出力 (例: Didi ドライバーの運転)軌跡)

手順:

すべての測位デバイスをリアルタイムで受信し、リアルタイムのトラックレコードを地図上に表示する必要があります

注:

最初のポイント:

ユーザー 1、2、3 は web1 サーバーに接続しており、web1 はユーザー 1、2、3 のみをブロードキャストできます。 3、情報をブロードキャストするときに web2 をブロードキャストすることはできません。接続されているユーザー 4、5、6、シーンがチャット中であると仮定すると、ユーザー 1 がメッセージを送信しますが、web1 サーバーのユーザーのみがそれを見ることができ、web2 のすべてのユーザーはそれを受信できません

2 番目のポイント: メッセージの頻度制御。例: 100 台のデバイス、100 人のユーザー、100 台のデバイスが 1 秒あたり 1 つのデータをアップロードし、実際には各ユーザーにブロードキャストする必要があります。時間、つまり 100*100 = 1W 回/秒なので、1 秒あたりのデータを要約してすべてのユーザーにブロードキャストするなどの方法

シナリオ 2 - 測位デバイスをデータベースに収集するだけ

手順: すべての測位デバイス ライブラリ、7 つのデバイス、1 秒あたり 1 つのデータによってアップロードされたデータを入力する必要があります。私は個人的に swoole のタスク関数を使用します (非同期タスクを task_worker プールに配信します。これは、関数はノンブロッキングであり、ワーカー プロセスの数も構成できます)、インターフェイスを呼び出してライブラリに入ります

サーバー メモリ アラームの問題

理由: swoole_server->task 関数にあります。

公式には、タスクの最下位層がフルメモリで IO 消費のない Unix ソケット パイプ通信を使用することが導入されています。単一プロセスの読み取りおよび書き込みパフォーマンスは 100 万/秒に達する可能性があり、異なるプロセスは異なるパイプラインを使用して通信するため、複数のコアを最大限に活用できます。

しかし、タスクがプログラム インターフェイスを呼び出す場合、ネットワーク遅延により、追加されたタスクが消費されたタスクよりも大きい場合、メモリ使用量は増加し続け、サーバーのメモリがいっぱいになります。

解決策: タスクに入るメッセージの頻度を制御します。この時間を定義し、独自のビジネス シナリオに従って遅延できるかどうかを定義し、すべてのデータを 1 秒以内に要約してから、プログラム インターフェイス (I) を呼び出します。個人的に要約するときは redis を使用します)、インターフェイスを呼び出さずにデータベースに直接保存するのが最善です

Scenario-IM system

公式 github: webim を参照してください。 system.

公式 wiki: swoole フレームワーク wiki

利点

データベースのモデル クラス、データベースの ORM インターフェイスをカプセル化します

redis カプセル化により、マルチインスタンス アクセスを実現できます

フレームワークには、ログなどの一般的に使用されるメソッドがいくつかあります (私はログのみを使用しました)

webim には公式のデーモンがあります。

を参照してください

以上がスウールはどこで使われていますか？の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。