PHPはメッセージキューを実装します

ご存知のとおり、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. デカップリングのケース: キュー処理「注文システム」と「流通システム」

プログラムのデカップリングについて簡単に説明します: プログラムのデカップリングは、あなたの妻と母親を防ぐことです誰を救うかという問題(ニヤニヤ)

注文プロセスについては、「注文システム」と「配送システム」の 2 つのシステムを設計できます。オンラインで買い物をするときに、注文後に送信すると、背景に商品が配送されているのが見えるのを誰もが見たことがあると思います。このとき、「配信システム」が関与する必要があります。

アーキテクチャを行う際に「注文システム」と「納品システム」を一緒に設計すると、いくつかの問題が発生します まず、注文システムについては、システムへの負担が大きくなりますが、「納品システム」は、これらの圧力に対する何らかの即時対応が必要です。

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

2.1 アーキテクチャ設計

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

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

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

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

2.2 プログラムの流れ

3. トラフィックのピークカットのケース: Redis のリスト型はフラッシュセールを実装します

Redis はメモリに基づいており、その速度は非常に高速です。 Redis は耐久性があるため、定期的にデータをハードディスクに書き込むため、停電を心配する必要がありません。さらに、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. ユーザーがフラッシュセールを開始するとき、フラッシュキルプログラムのリクエストをRedisに書き込みます(uid、time_stamp)。

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

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

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

IV. RabbitMQ

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

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

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

RabbitMQSの使用

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

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

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

ワークキュー

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

これはプロデューサーとコンシューマー間の分離を解決するだけでなく、次のことも行うことができます。コンシューマーとタスクの共有を実現し、サーバーへの負荷を軽減します。

5. まとめ

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

6. 質問

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

Redis はリクエストを 1 つずつ処理します。Redis は同期ブロッキングを使用し、もう 1 つは非同期を使用します。 -ブロッキング。

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

キューメディア:

Mysql: 信頼性が高く、実装が簡単、速度が遅い
Redis: 高速だが、単一の大きなメッセージパッケージでは効率が低い
メッセージシステム: 強力なプロ意識、信頼性、学習高コスト (例: RabbtiMQ)

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

無限ループ読み取り: 実装が簡単、失敗した場合は時間内に回復できません
スケジュールされたタスク: 圧力は均等に分散され、上限があります。処理能力の限界。 (最大の欠点:測位タスクの時間間隔と処理されるデータを正確に把握する必要がある。前のタスクが完了する前に次のタスクが開始されたとはみなせない。)

デーモンプロセス: PHP-FPM に類似および PHP-CGI、シェルの知識が必要です。

関連する推奨事項:

PHP でのメッセージ キューの実装とアプリケーション

PHP と Redis でメッセージ キューを実装する方法

php はメッセージ キュー クラス インスタンスの共有を実装します

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