メッセージキューの概念、原則、使用シナリオの詳細な紹介 (ケース付き)

ご存知のとおり、Web サイトをデザインする際には、ユーザーへの「グループ テキスト メッセージ」、「注文システムの大量のログ」、「フラッシュ セールのデザイン」などに遭遇することになります。サーバーはこれらを処理できません。この種の瞬間的な圧力のバーストには、システムを正常かつ効果的に使用するために「メッセージ キュー」の助けが必要です。この記事では主にメッセージ キューの概念について学習します。

主に次の知識を理解します。

1. キューとは何か、キューで何ができるのか?

2. アライメントの適用シナリオは何ですか?

3. キューを使用してサービスを分離するにはどうすればよいですか?

4. Redis キューを使用して高圧を解消するにはどうすればよいですか?

5.プロフェッショナルアライメントシステムRabbitMQの使い方は？

主な内容を要約すると次のとおりです。

@メッセージキューの概念、原理、シナリオ

@デカップリングケース: キュー処理順序システムと配信システム

@トラフィック ピークの削減事例: Redis のリスト型でフラッシュ セールスを実現

@RabbitMQ: よりプロフェッショナルなメッセージ システム実装ソリューション

1.メッセージ キューについて

1.1 メッセージ キューの概念

本質的に、メッセージ キューはキュー構造を持つミドルウェアです。つまり、メッセージはこのミドルウェアに入力された後、直接返されることができます。 . システムはすぐに処理する必要はありませんが、別のプログラムがデータを読み取り、順番に 1 つずつ処理します。

つまり、処理結果をすぐに返す必要がない、同時並行性が高くて時間がかかるような事態が発生した場合、メッセージキューを使用することでそのような問題を解決できます。

1.2 コア構造

ビジネス システムによってメッセージをエンキューし、メッセージを 1 つずつメッセージ キューに挿入し、挿入後に成功結果を直接返します。将来的には、メッセージ システム内のレコードを 1 つずつ取り出して処理し、デキュー処理を完了するメッセージ処理システムが登場する予定です。

1.3 適用シナリオ

データの冗長性: たとえば、注文システムでは、将来的に厳密なデータ変換と記録が必要になりますが、メッセージ キューはこれらのデータをキューに永続的に保存できます。次に注文があり、後続の処理プログラムがそれを取得し、後続の処理が完了した後、各レコードが処理できるようにするためにレコードが削除されます。

システムの分離: メッセージ システムを使用した後は、エンキュー システムとデキュー システムが分離されます。つまり、ある日クラッシュする限り、他のシステムの通常の動作には影響しません。

トラフィックのピークの削減: たとえば、フラッシュ セールやラッシュ セールでは、メッセージ キューをキャッシュと組み合わせて使用​​できます。これにより、瞬間的なアクセス量に効果的に耐え、サーバーが過負荷になってクラッシュが発生するのを防ぐことができます。

非同期通信: メッセージ自体をキューに入れてから直接返すことができます。

スケーラビリティ: たとえば、注文キューは注文を処理するだけでなく、他のビジネスでも使用できます。

ソート保証: データが特定の順序で処理されることを保証するために、シングルインとシングルアウトなど、一部のシナリオは製品の順序で処理する必要があります。メッセージ キューを使用することができます。

上記はメッセージ キューの一般的な使用シナリオですが、もちろんメッセージ キューは単なるミドルウェアであり、他の製品と組み合わせて使用​​することができます。

#1.4 一般的なキュー実装の長所と短所

キュー媒体

1. mysql などのデータベース (高信頼性、実装が簡単、低速)

2、redis などのキャッシュ (単一のメッセージ パッケージが大きすぎると高速、効率が低い)

#3、rabbitMq などのメッセージ システム (高度に専門的で信頼性が高く、学習コストが高い)

メッセージ処理トリガーメカニズム

1. 無限ループ読み取り: 実装は簡単ですが、障害が発生した場合は時間内に回復できません; (フラッシュセール、より集中化された、一元化された運用と保守に適しています)

2. スケジュールされたタスク: 圧力は均等に分散され、処理の上限があり、現在一般的な処理トリガー メカニズムです。 (唯一の欠点は、間隔とデータに注意する必要があることです。前のタスクが完了せずに次のタスクが再開されるまで待たないでください)

3. デーモン プロセス: php- に似ています。 fpm と php-cg、シェルの基礎が必要

2. 分離ケース: キュー処理「

Order System」と「Distribution System」注文プロセスについては、「注文システム」と「配送システム」の 2 つのシステムを設計できます。オンライン ショッピングで誰もが目にしたことがあるはずです。注文を送信した後、背景で私の商品が配送されているのがわかります。このとき、「配信システム」が関与する必要があります。

「注文システム」と「配送システム」を一緒に設計してアーキテクチャを行う場合、いくつかの問題が発生します まず、注文システムの場合、システムへの負荷が比較的高くなります。しかし、「流通システム」は必ずしもこれらの圧力に即座に対応する必要はありません。

第二に、注文システムが故障した後に配送システムが故障することは望ましくありません。これは、両方のシステムの通常の動作に同時に影響を与えることになります。したがって、私たちはこれら 2 つのシステムを分離したいと考えています。 2 つのシステムが分離された後は、中間の「キュー テーブル」を介して 2 つのシステム間で通信できるようになります。

2.1 アーキテクチャ設計

1. まず、注文システムがユーザーの注文を受け取り、注文を処理します。

2. これらの注文情報はキュー テーブルに書き込まれます。このキュー テーブルは 2 つのシステム間の通信の鍵となります。

3. 分散システムによって定期的に実行されるプログラムは、処理のためにキュー テーブルを読み取ります。

4. 配信システムによる処理後、処理されたレコードにマークが付けられます。

2.2 プログラムの流れ

3. トラフィックピーククリッピングの事例: Redis のリスト型でフラッシュセールを実現

redis メモリに基づいているため、速度が非常に速くなります。Redis は耐久性があるため、データベースを補完するのに非常に適しています。Redis は定期的にデータをハードディスクに書き込むため、停電を心配する必要はありません。この点において、 , それは別のキャッシュ memcache よりも多くの利点があります. さらに、redis は 5 つのデータ型 (文字列、二重リンク リスト、ハッシュ、セット、順序付きセット) を提供します

一般的に、フラッシュ セールを行う場合、Redis は良い選択です。ケース、急ぎの購入、行列が必要なケースがすぐにあなたのケースよりも高くなる場合。

3.1 redisのデータ型のリスト型

redisのリストは二重リンクリストであり、先頭または末尾からデータを追加することができます。

* LPUSH/LPUSHX: (/existing) リストの先頭に値を挿入します。

* RPUSH/RPUSHX: (/existing) リストの末尾に値を挿入します

* LPOP: リストの最初の要素を削除して取得します。

* RPOP: リストの最後の要素を削除して取得します。

* LTRIM: 要素を指定された範囲に保持します。

* LLEN: リストの長さを取得します

* LSET: リスト要素の値をインデックスで設定します

* LINDEX: リスト内の要素をインデックスで取得します

* LRANGE: リストの指定範囲内の要素を取得します

3.2 アーキテクチャ設計

シンプルな構造のフラッシュキルプログラム設計です。

#1. まず、フラッシュ セールに参加したユーザーを記録し、その時間を記録します。

2. ユーザーの ID を Redis リストに保存し、キューに入れます。最初の 10 ユーザーのみが正常に参加できると規定されている場合、リストの数が十分な場合は、データを追加し続けることはできません。この方法では、redis リストの長さは 10

3 のみになります。最後に、データへの負荷を軽減するために、redis 内のデータをデータベースにゆっくりと書き込みます。

3.3 コード レベルデザイン

1. ユーザーがフラッシュ セールを開始するとき、フラッシュ セール プログラムのリクエスト (uid、time_stamp) を Redis に書き込みます。

2. フラッシュセールで10人までしか成功できないと規定されている場合、Redisに保存されているデータの長さを確認し、上限を超えている場合は直接破棄してください。完成しました。

3. 最後に、Redis に保存されている 10 個のデータが無限ループで処理され、その後データがゆっくりフェッチされて mysql データベースに保存されます。

フラッシュセール領域ではデータベースへの負荷が特に高く、そのような設計をしないとMySQLの書き込みボトルネックが発生します。 Redis でキュー リストを使用し、フラッシュ セール リクエストを Redis に入力します。最後に、ウェアハウス プログラムを通じてデータをデータベースにゆっくりと書き込みます。このようにして、トラフィックのバランスが取れ、mysql には影響しません。 。 プレッシャーが強すぎる。

4. RabbitMQ

ここでは、RabbitMQ のいくつかの使用法について説明します まず、以前フラッシュ セールのケースについて話したときに、ロックの仕組みについて説明しました。他のプログラムが同じレコードを処理するのを防ぎます。システム アーキテクチャが非常に複雑な場合、複数のプログラムがリアルタイムでキューを読み取っているか、1 つ以上のキューを同時に操作する複数の送信プログラムがあり、これらのプログラムが必要になることさえあります。プログラムを別のマシンに配布する場合、redis キューの使用はやや不十分です。この時点で何をすべきでしょうか? 問題をより適切に解決できる、より専門的なメッセージ キュー システムを導入する必要があります。

4.1 RabbitMQ のアーキテクチャと原則

機能: AMQP の完全な実装、クラスターの簡素化、永続性、クロスプラットフォーム

RabbitMQS の使用

1. RabbitMQ のインストール (rabbitmq-server、php-amqplib)

2. プロデューサーはメッセージ チャネルにメッセージを送信します

3. コンシューマーはメッセージを処理します

ワーク キュー

アイデア: プロデューサーはタスクをメッセージ システムに送信します。メッセージ システムはタスクをメッセージ キューにカプセル化し、複数のコンシューマーに対して同じキューを使用します。 # ##

これにより、プロデューサーとコンシューマー間の分離が解決されるだけでなく、コンシューマーとタスクの共有が可能になり、サーバーへの負荷が軽減されます。

5. 概要

上記は主に、メッセージ キューの概念、原則、シナリオを学習することに焦点を当てています。ケースを分離し、RabbitMQ の簡単な使用法を理解します。

6. 質問

redis とメッセージ サーバーの選択の最大の違いは何ですか。

私の理解では、Redis はリクエストを 1 つずつ処理します。Redis はシングル スレッドです。メッセージ サーバーの IO 実装とは異なります。1 つは同期で、もう 1 つは非同期ですが、Redis は同期ブロッキングを使用します。メッセージ サーバー 非同期ノンブロッキングを使用します。

Redis 関連の知識の詳細については、Redis 使用法チュートリアル 列をご覧ください。

以上がメッセージキューの概念、原則、使用シナリオの詳細な紹介 (ケース付き)の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。