メッセージキューを使用する必要がありますか?なぜそれを使用する必要があるのか​​について話しましょう

この記事では、メッセージ キューに関する関連知識を紹介します。主に、メッセージ キューを使用する理由と、メッセージ キューを使用する必要がある理由を紹介します。興味のある方は、見てみましょう。皆さんもぜひご協力ください。

メッセージ キューを使用する理由、6 つの単語の要約: デカップリング、非同期、ピーク除去

1)デカップリング

従来モードのシステム それらの間の結合強すぎます。たとえば、システム A はインターフェイス呼び出しを通じて 3 つのシステム B、C、D にデータを送信します。将来システム E が接続される場合、またはシステム B が接続する必要がない場合でも、システム A は変更する必要があります。コード、とても面倒です。

システム A が比較的重要なデータを生成する場合、4 つのシステム B、C、D、E がダウンしていないかどうかを常に考慮する必要があります。するの？全員がこのデータを受け取りましたか?明らかに、システム A は他のシステムと強く結合しています。

そして、データ (メッセージ) をメッセージ キューに書き込むと、メッセージを必要とするシステムはメッセージ キュー自体からそのメッセージを直接消費します。このようにして、システム A はデータの送信先を考慮する必要がなく、このコードを保守する必要もありません。また、他のシステムが正常に呼び出されたかどうか、失敗のタイムアウトなどを考慮する必要もありません。とにかく、私は責任を負うだけです。プロダクションのためであり、それ以外のことは気にしません。

2) 非同期

まず、従来の同期の状況を見てみましょう。例: システム A がユーザーを受信します。このリクエストはライブラリの書き込み操作を必要とし、B、C、Dの3系統で同じライブラリの書き込み操作を行う必要があります。 A がライブラリをローカルに書き込む場合、所要時間はわずか 1 ミリ秒ですが、3 つのシステム B、C、D ではそれぞれ 100 ミリ秒、200 ミリ秒、300 ミリ秒かかります。最終的な合計リクエスト遅延は 1 100 200 300 = 601 ミリ秒となり、ユーザー エクスペリエンスが大幅に低下します。

メッセージ キューを使用する場合、システム A は 3 つのメッセージをメッセージ キューに送信するだけで済みます。5 ミリ秒かかる場合、システム A は次から 1 つのメッセージを受信します。リクエストからユーザーにレスポンスが返されるまでの合計時間は 1 5 = 6ms となり、ユーザーにとってエクスペリエンスの満足度は直接的に最大化されます。

#3) ピーク除去

キャッシュまたはメッセージ キューが使用されない場合、システムは直接ベースになります。データベース MySQL では、このようなピーク期間があり、大量のリクエストが MySQL に殺到した場合、システムが直接クラッシュすることは間違いありません。

メッセージ キューを使用する場合、MySQL は 1 秒あたり最大 1,000 個のデータを処理でき、ピーク時には 5,000 個のデータが流入すると仮定します。ただし、これらの 5,000 個のデータはメッセージに流れ込みます。列。このようにして、システムはデータベースの機能に応じてメッセージ キューからリクエストをゆっくりとプルすることができ、1 秒あたりに処理できるリクエストの最大数を超えることはありません。

つまり、メッセージ キューには毎秒 5,000 のリクエストが受信され、1,000 のリクエストがメッセージ キューから出力されます。ピーク期間が 1 時間であると仮定すると、数十万、さらには数百万のリクエストがメッセージ キューにバックログされる可能性があります。この期間中のメッセージキューはキューにあります。ただし、この短いピーク バックログは完全に許容できます。ピーク期間の後、1 秒あたりにメッセージ キューに入るリクエストはそれほど多くなくなりますが、データベースは引き続き 1 秒あたり 1,000 リクエストの速度で処理するからです。したがって、ピーク期間が終わるとすぐに、システムはメッセージのバックログを迅速に処理します。

推奨される調査: 「Redis ビデオ チュートリアル 」

以上がメッセージキューを使用する必要がありますか?なぜそれを使用する必要があるのか​​について話しましょうの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。