Redisに基づいてメッセージキューを実装する方法

Message Queue (メッセージ キュー) は、並行システムにおけるリソースの一貫性の問題を解決し、ピーク処理能力を向上させ、メッセージの順序性、回復可能性、配信の必須性を確保するためによく使用されます。アプリケーションを分離したり、非同期通信を実装したりするなど。 (推奨される学習: Redis ビデオ チュートリアル )

市場には多くの MQ アプリケーション (例: Kafka、RabbitMQ、Disque) があり、これらは以下に基づいて実装することもできます。より一般的な Redis ソリューションには以下が含まれます:

List に基づく LPUSH BRPOP の実装

PUB/SUB、サブスクリプション/パブリッシング モード

Sorted に基づく実装-Set

ストリーム タイプに基づく実装

##メッセージ キューの使用には、プロデューサーとコンシューマーが存在します。プロデューサはメッセージの生成を担当し、コンシューマはメッセージの処理を担当します。

プロダクションとは、メッセージをメッセージ キューに入れることを指します。

消費とは、メッセージの読み取りと処理を指します。通常、メッセージが消費された後は、メッセージ キューから削除する必要があります。

List に基づく LPUSH BRPOP の実装

一般的なコマンドは次のとおりです:

は、FIFL キューに基づく一般的なソリューションです。このうち、LPUSH はプロデューサーが行うもの、BRPOP はコンシューマーが行うものです。

このモデルには多くの利点があります:

シンプルな実装

Reids は永続的なメッセージをサポートしています。つまり、メッセージは失われず、繰り返し表示できます。 (LRANGE クラスの命令を消費するのではなく、ただ見て使用するだけであることに注意してください)。

順序を確保でき、LPUSH コマンドを使用してメッセージの順序を確保できます。

RPUSH を使用すると、メッセージをキューの先頭に配置して、メッセージに優先順位を付け、シンプルなメッセージを実現することを目的としたプライオリティキュー。

同時に、いくつかの欠点もあります。

消費確認 ACK を行うのがより面倒です。つまり、消費者が消費確認 ACK を受け取るという保証はありません。読み取り後に未処理のダウンタイムの問題。予期しないメッセージの損失が発生します。通常、メッセージが確実に処理され確認されるように、保留リストを自分で管理する必要があります。

一般的なパブリッシュ/ディスクリプト モードなどのブロードキャスト モードは実行できません。

繰り返し利用できません。一度消費すると削除されます。

グループ利用はサポートされていません。ビジネス ロジック レイヤーで自分で解決する必要があります。

PUB /SUB、サブスクリプション/パブリッシング パターン

プロデューサーとコンシューマーは、同じチャネル (チャネル) を通じて対話します。チャネルは実際にはキューです。通常、複数の消費者が存在します。複数のコンシューマが同じチャネルにサブスクライブしている場合、プロデューサがチャネルにメッセージをパブリッシュすると、チャネルはすぐにメッセージを各コンシューマに 1 つずつパブリッシュします。このチャネルは消費者にとって分岐したチャネルであり、各消費者は同じメッセージを取得できることがわかります。典型的な 1 対多の関係。

一般的な利点は次のとおりです。

一般的なブロードキャスト モード、メッセージを複数の消費者に公開できます

マルチチャネル サブスクリプション、消費者が購読できる複数のタイプのメッセージを同時に受信するための複数のチャネル

メッセージはすぐに送信されます。メッセージはコンシューマが読むのを待つ必要はありません。コンシューマはチャネルによって発行されたメッセージを自動的に受信します

デメリットもいくつかあります:

メッセージが公開されると、受信できなくなります。つまり、公開時にクライアントがオンラインでない場合、メッセージは失われ、取得できなくなります。

各コンシューマが受信した時間が一貫しているという保証はありません

メッセージがコンシューマ クライアントに表示される バックログはある程度まで強制的に切断され、予期しないメッセージの損失が発生します。これは通常、メッセージの生成速度が消費速度よりもはるかに速い場合に発生します。

Pub/Sub モードはメッセージ ストレージやメッセージ バックログ サービスには適していませんが、ブロードキャスト、インスタント メッセージの処理には適していることがわかります。メッセージング、インスタント フィードバック サービス。

SortedSet 順序セットに基づく実装

順序セットのスキームは、セット メンバーのスコアを使用してメッセージ順序 ID を自分で決定する場合によく使用されます。メッセージIDとして順序を保証し、メッセージIDの単調増加も保証できます。通常は、タイムスタンプ シーケンス番号スキームを使用できます。メッセージ ID の単調増加が保証され、スコアに従ってソートする SortedSet の機能を使用して、順序付けされたメッセージ キューを作成できます。

上記のソリューションと比較すると、メッセージ ID をカスタマイズできるという利点があります。これは、メッセージ ID が意味のある場合にさらに重要になります。欠点も明らかで、重複したメッセージは許可されません (メッセージをコレクションとして考えてください) 同時に、メッセージ ID の決定時にエラーが発生すると、メッセージの順序にエラーが発生します。

したがって、メッセージ ID をカスタマイズする必要がない場合、この解決策は少し味気ないように思えます...

ストリーム タイプに基づいた実装

このストリーム型redisはメッセージキューを実装するためのものです。メッセージ ID の自動生成、グループ消費、ACK、メッセージ転送、キュー監視などのコア メッセージ キュー機能をサポートします。

Redis 関連の技術記事の詳細については、

Redis 入門チュートリアルをご覧ください。 学べるコラム！

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