PHPメッセージキュー

メッセージ キュー MQ は本​​質的にはキューであり、その最も単純な操作は、プログラムに従って、いつ、どのような条件でキューに参加するか、およびいつ、どのような条件でキューを取得するかを決定します。つまり、エンキュー システムとデキュー システムのビジネス要件が一致しないシナリオが発生した場合、それを実装するためにメッセージ キューを使用するかどうかを検討できます。適用可能なシナリオは数多くあります。一般的なシナリオと説明をいくつか示します。

1: 非同期処理、アプリケーションの分離、分散

シナリオ: メインビジネスがサブビジネスの処理結果を気にしない場合。

事例：電子商取引システムにおける受注システム、物流システム、金融システム、操作ログ記録システムの関係。

人気の説明: シャオミンはケーキ屋の店員です。彼はケーキを作った後、それを窓に置き、対応する注文に「完了」とマークし、それから次のケーキを作り続けました。ケーキがいつどのように販売されるかは気にしませんでした。
実装: キューミドルウェアまたはミドルシステムを使用して、複数のビジネスシステムの共通部分を保存し、それらを独立して処理します。各システムの処理進捗は、独自の独立したタグを使用して記録できます。すべてのシステムが操作を完了した後、デキュー操作を実行するか、データ ストレージを永続化します。

注: 障害が発生して回復したときにビジネス プロセスを確実に復元できるように、中間データの災害復旧機能を考慮する必要があります。すべてのデータが正しく処理できることを確認します。

2: ピーク処理

シナリオ: トラフィックはさまざまな時点で不均衡です

ケース: フラッシュセール、ラッシュセール

説明: Xiao Ming はケーキを作るのに長い時間がかかり、ケーキを作った後は注文が来ると、まずリストに登録し、順番に作っていきます。注文数量が多すぎると、一時的に「売り切れ」のマークが表示されます。

実装: シングルスレッドツールを使用してビジネス要件をキューに入れます。ビジネス リクエストがしきい値に達すると、わかりやすいプロンプトが表示され、ユーザーのリクエストは拒否されます。

注: ピーク時の需要については、トラフィックがその後のビジネスに影響を与えるのを防ぐために、ピーク時に「一時的に利用できないためお待ちください」などのプロンプトを投稿できます。フラッシュセールが利用可能になるとすぐに終了するなどのニーズについては、オーバー発行の問題を考慮する必要があります。割り当てカウンターを追加したり、フラッシュセール割り当てがいっぱいになったときにフラッシュセール完了マークを発行したりすることができます。後続の処理プログラムが完了マークを検出すると、後続の処理が実行されます。

3: 配信保証

シナリオ: コンテンツは 1 つずつ厳密に実行される必要があり、実行が失敗したり中断された場合でも、実行は成功することが保証されています

ケース:銀行および金融システムは災害復旧機能を向上させる必要があります システム

説明: シャオ・ミンが作ったケーキは、次のケーキを作り続ける前に顧客によって検査され、署名される必要があります。

実装: キューイング システムはビジネス要件をメッセージ キューに書き込んだ後、次のビジネス処理に進みます。後続の処理プログラムはキューの内容を一つずつ処理し、処理が完了すると「Complete Permit」を発行します。メッセージキューの内容は、「完全権限」を取得した場合のみメッセージキューから削除できます。

注意点: ビジネスリカバリの問題や重複処理の問題など、ディザスタリカバリに関連する問題に焦点を当てます。

4: 並べ替えの保証

シナリオ: メッセージ キュー内のコンテンツには厳密な順序があります。

ケース: 順番待ちシステム

説明: シャオミンはケーキを作る順番に厳密に従う必要があります。

実装: キューイング システムは、内容を 1 つずつメッセージ キューに書き込み、それらを 1 行に配置し、後続の処理のために先入れ先出しの順序でデータを抽出します。

注: 生産ラインが 1 つだけになるようにするには、単一のスレッドを使用する必要があります。

5 複数のコンシューマがメッセージ中間層をサブスクライブし、発行者がその情報を中間層に公開します。 この中間層をサブスクライブするコンシューマは、このメッセージを受信し、後続の処理を実行できます。この構造では。メッセージの後続処理コンポーネントを追加する場合は、このコンポーネントを中間層にサブスクライブするだけです。 注: 拡張中の干渉を防ぐために、ビジネス間に深い結合がないことを確認してください。

上記は、メッセージ キューの一般的に使用されるいくつかのシナリオです。メッセージ キューを使用すると、システム間の差異が解消され、システムの安定性が向上します。

メッセージキューの媒体を選択するとき、最初に条件と目標を最大化する必要はないことをお勧めします。問題を完全に解決するには、どのような条件を使用する必要がありますか? プログラムには依然として長期的なメンテナンスと最適化のプロセスが必要です。 。
トラフィックが多く、大量の永続データが必要な場合、Redis のパフォーマンスの低下は依然として深刻ですが、このコースでは、Redis のアプリケーション シナリオとアイデアのみを理解することをお勧めします。プロセスを変更することで、あらゆるオンライン プロジェクトが常に最適化され、完成します。一連のビデオを通じてすべての問題を完璧に解決したい場合は、残念ながら、各ジョブのニーズとアプリケーション シナリオに対応できません。異なるニーズがある場合は、特定のニーズを改善するだけの指示に従ってください。

---

キューの需要を判断する場合、キューにプッシュされるたびに現在のキューの長さを判断し、その数が制限されたフラッシュセール数を超える場合は、カウンターフィールドを追加する必要があります。キュープログラムには入りません。

実際の使用では、メッセージキューを追加する必要がある場所を意図的に追求する必要はありません。むしろ、事業の分離・デカップリングや一部の特殊な需要を実施する際には、実情に応じて合理的に選択・使用されるべきである。

以上がPHPメッセージキューの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。