Redis はどのようにメッセージ キューを実行しますか?

アイデアとしては、2 つのサーバーを使用し、ノードがリクエストを処理し、すべてのデータを Redis キャッシュ キューにプッシュし、もう 1 つの PHP サーバーがこのキューにデータを継続的にポップし、永続化のために mysql と対話するというものです。 。 。これについてどう思いますか?

返信内容:

他の回答と同様に、基本的に 2 つの解決策があります
1. Redis 独自の PUB/SUB メカニズム、これはパブリッシュ/サブスクライブ モデルです。このモデルでは、プロデューサーとコンシューマーは 1 対 M の関係にあります。つまり、コンシューマーが 1 つしかない場合、メッセージは 1 対 1 のメッセージ キューと見なされます。被写体のシナリオには適していません。まず、データの信頼性は保証できません。メッセージが失われたり、Redis がクラッシュしたり、一部のデータが保持されなかったり、突然のネットワークのジッターによってデータが失われる可能性がある場合、最終的にはデータベースに保存する必要があります。耐えられない。第 2 に、拡張には柔軟性がなく、コンシューマーを追加して消費を高速化することはできません。フロントエンドに書き込まれるデータが多すぎると、データが同期していない時間が長くなるほど、リスクが大きくなります。もちろん、この解決策は柔軟性に欠けますが、チャネル分割によって回避できます。このソリューションは、統計ログ管理など、高い信頼性を必要としないデータに適しています。

2. Redis の PUSH/POP メカニズムは、Redis リスト (リスト) データ構造を利用します。より良い使用パターンは、lpush メッセージをプロデューサーとして使用し、brpop メッセージをコンシューマーとして使用し、タイムアウトを設定して Redis への負荷を軽減することです。最初のソリューションと比較して、このソリューションは、Redis がダウンし、データが永続化されない場合にのみデータの信頼性を向上させることができ、ビジネスに応じて永続化間隔を短縮することもできます。複数のクライアントを使用して消費速度を向上させます。ただし、プロフェッショナルなメッセージ キューと比較すると、このソリューションのメッセージのステータスは単純すぎる (ステータスなし) ため、メッセージが取り出された後にメッセージを消費できないかどうかは、クライアントがログを記録するかプッシュするかに依存します。再び列に並びます。

最後に、質問者のニーズを見てみましょう。彼は、データの究極の一貫性を期待して、最初に Redis を作成してから、それを mysql に非同期で同期したいと考えています。この利点は、フロントエンドによって書き込まれるリクエストが非常に高速であることです (ディスク上にリクエストを配置する必要はありません。もちろん高速です)。ただし、問題は非常に複雑で不合理です。この仮定が妥当な場合は、Redis 作成者によるオープン ソースの Disque や Alibaba のオープン ソース RocketMQ など、より信頼性の高いメッセージ ミドルウェアを選択する必要があり、データの保存には Golang ベースの Redis の方が適しています。

質問者の要求はなぜ不当だと思いますか?
最初にキャッシュを書き込んでから DB に同期するこの方法と同様に、目的は DB の負荷を軽減し、フロントエンド API のパフォーマンスを向上させることです。このトピックのソリューションはこれら 2 つの点を達成できますが、データがどこに保存されているかに関係なく、アクセス (使用) するためのものであるという基本的な点を無視しています。ただし、このトピックのソリューションでは、Redis に書き込まれたデータは、アクセスを受信せずに DB に同期する以外には役に立ちません。最終的に、DB 読み取りの負荷が増大し、データを Redis に再ロードする必要があります。利益は損失を上回ります。

どのような構造がより合理的ですか?
簡単に言ってください。
非同期書き込みは、Baidu と 58.com で広く使用されており、基本的なアーキテクチャは、まずオブジェクト アクセス層 (またはキャッシュ層) を抽象化し、データ ソース (Redis、mysql、その他) を外部から保護します。オブジェクト アクセス レイヤーには、特定の種類のデータに対して明確に定義された形式があり、書き込みリクエストが来ると、そのデータはキャッシュ (Redis) に直接書き込まれます。そのため、フロントエンドの読み取りリクエストはキャッシュを直接読み取り、保存されたデータがデータには意味があります (もちろん、大量の読み取りが必要です)。次に、データの実装 (結果整合性の問題) があります。単純なものでは RDB ファイルを読み取ることができます (リアルタイム パフォーマンスは高くありません)。より複雑なものでは、Redis マスター/スレーブ同期プロトコルを実装できます (リアルタイム パフォーマンスが高くなります)。前者より）。 1 つ目は単純で効率が低く、2 つ目は複雑で効率が高いです。
Redis から始める (3) - Redis とメッセージミドルウェア この記事では Redis とメッセージミドルウェアについて詳しく説明します

皆さんのお役に立てれば幸いです役立つ。

=========================================== == ===================

皆様、私が運営するwx公式アカウント「ミドルウェアアーキテクチャ」、WeChat ID:middlewarearch、および最近 Redis を更新しました 関連記事については、今後も mysql プロキシ、Redis、nginx、メッセージ ミドルウェア、RPC フレームワークに関する記事を更新していきますので、よろしくお願いします。

Redis リストを使用し、最初に lpush を使用し、次にスレッドを使用して rpop データ処理を実行します。 システムボリュームが大きくない場合は、Redis のリストプッシュとポップで十分です。システムボリュームが大きい場合は、より成熟した MQ を使用してみてください。ただし、シナリオによっては重くなります。 Redis 自体は pub/sub モードをサポートしており、メッセージ キューとして処理できます。「コマンド リファレンス」を参照してください。

トピックのシナリオに従って、redis の永続性を構成する必要があります。それ以外の場合はデータを構成します。 mysql に保存できない場合があります。 Pubsub はブロードキャストの問題を解決し、poppush はキューの問題を解決します。 lpush rpop lpush と lpop はポスターに適しています 参考 [2.3]
データの種類は何ですか?
要件がそれほど高くない場合は、logstash を使用できます。
現在、mysql 用の公式出力プラグインはありません。
入力ソースの Redis は、lpush、lpop、pub/sub モードをサポートしています。構成ファイルを変更するだけです。 Redis は必要ありません。nsq や kafka などにも対応するプラグインがあります。
mongodb と elasticsearch をサポートする出力プラグインについては、公式ドキュメントを参照してください。 lpush/rpop はスタック アクセスをシミュレートします。 卒業プロジェクト用に構築したクローラーと同じように、1 つのプロセスがデータを Redis にプッシュし続け、別のプロセスが lpop します。