3
Redisでメッセージキューを実装する方法は？
キューイングにRedisを使用する理由 私は、Redisがキューイングシステムを実装するための良い候補になることができるという印象を受けています。これまで、MySQLデータベースをポーリングまたはRabbitMQで使用してきました。RabbitMQには多くの問題があります。クライアントライブラリは非常に貧弱でバグが多いため、修正に開発者の時間をかけすぎないように、サーバー管理コンソールにいくつかの問題があります。少なくとも、ミリ秒で把握したり、パフォーマンスを真剣に推進したりすることはないので、システムがキューをインテリジェントにサポートするアーキテクチャを備えている限り、おそらく良好な状態にあります。 さて、それが背景です。基本的に、非常に古典的でシンプルなキューモデルがあります。仕事を生成する複数のプロデューサーと、仕事を消費する複数のコンシューマーがあり、プロデューサーとコンシューマーの両方がインテリジェントにスケーリングできる必要があります。すべてのサブスクライバーに作業を消費さPUBSUBせたくないので、ナイーブが機能しないことがわかります。1人のサブスクライバーに作業を受け取りたいだけです。最初のパスでは、インテリジェントデザインのように見えます。BRPOPLPUSH BRPOPLPUSHを使用できますか？ 基本的な設計でBRPOPLPUSHは、1つの作業キューと進行状況キューがあります。コンシューマーが作業を受け取ると、アイテムをアトミックに進行キューにプッシュし、作業を完了するとそれが完了LREMします。これにより、クライアントが死んだ場合の作業のブラックホール化が防止され、監視が非常に楽になります。たとえば、大量のタスクがあるかどうかを通知するだけでなく、消費者がタスクを実行するのに長時間かかる問題があるかどうかを確認できます。 それは保証します 仕事はちょうど1人の消費者に届けられる 作業は進行キューで終了するため、消費者がブラックホールに陥ることはありません 欠点 私が見つけた最高のデザインはPUBSUB、Redisのキューイングに関するほとんどのブログ投稿が焦点を当てているものであるように思われるため、実際には使用していません。だから、私は明白な何かを見逃しているように感じます。PUBSUBタスクを2回消費せずに使用する唯一の方法は、作業が到着したという通知をプッシュするだけで、消費者はそれをブロックしないようにできRPOPLPUSHます。 一度に複数のワークアイテムを要求することはできません。これはパフォーマンスの問題のようです。私たちの状況にとっては大きなものではありませんが、この操作は高スループットまたはこの状況のために設計されたものではないことを明確に示しています 要するに、私は愚かな何かを見逃していますか？ node.jsタグも追加します。これは、私が主に扱っている言語だからです。Nodeは、シングルスレッドでノンブロッキングな性質を考えると、実装のいくつかの単純化を提供するかもしれませんが、さらに、node-redisライブラリとソリューションを使用しています。