信頼できるメッセージングのパブリッシュ/サブスクライブ：Redis VS RabbitMQ
バックグラウンド
出版社が消費者にメッセージを送信するパブリッシュ/サブスクライブの典型的なアプリケーションを作成しています。
パブリッシャーとコンシューマーは異なるマシン上にあり、それらの間の接続は時々切断される可能性があります。
目的
ここでの目標は、接続またはマシン自体に何が起こっても、パブリッシャーによって送信されたメッセージがalwaysによって受信されることを確認することです消費者.
メッセージの順序は必須ではありません。
問題
私の研究によると、RabbitMQはこのシナリオに最適です。
ただし、RabbitMQには publish and subscriber に関するチュートリアルがありますが、このチュートリアルでは永続キューを紹介していませんし、 confirms についても言及していません。配信されました。
一方、Redisはこれも実行できます。
redisは主にRabbitMQのようなメッセージブローカーではなくメモリ内のデータストアであるため、公式のチュートリアルや例を見つけることができず、現在の控えめな表現で永続キューとメッセージ確認を行う必要があると考えています。
ご質問
- このユースケースでは、どのソリューションが最も簡単に実装できますか？ （RedisソリューションまたはRabbitMQソリューション？）
- あなたが最良だと思うものへの例へのリンクを提供してください！
バックグラウンド
私はもともと、メッセージとキューの永続性でパブリッシュとサブスクライブを望んでいました。
これは理論的には、パブリッシュおよびサブスクライブに完全には適合しません。
- このパターンは、メッセージが受信されるかどうかを気にしません。パブリッシャーは単にメッセージをファンアウトし、リスニングしているサブスクライバーがいる場合、それ以外は気にしません。
実際、自分のニーズを見ると、ワークキューパターン、またはRPCパターンがさらに必要になります。
分析
人々は両方とも簡単であるべきだと言いますが、それは本当に主観的です。
RabbitMQには、ほとんどの言語で明確な例があり、全体的に優れた公式ドキュメントがありますが、Redisの情報は主にサードパーティのブログとまばらなgithubリポジトリにあります。
例については、RabbitMQには私の質問に明確に答える2つの例があります。
2つを混ぜることで、パブリッシャーが信頼できるメッセージを複数の消費者に送信することができました-たとえ1つが失敗しても。メッセージは失われたり、忘れられたりすることはありません。
RabbitMQの没落：
- このアプローチの最大の問題は、消費者/労働者がクラッシュした場合、自分でロジックを定義して、タスクが失われないようにする必要があることです。これは、タスクが完了すると、Work Queuesの永続キューを使用したRPCパターンに従って、サーバーが再び復帰するまでワーカーにメッセージを送信し続けるためです。ただし、ワーカーはサーバーからの応答を既に読み取ったかどうかを知らないため、サーバーからいくつかのACKを受け取ります。これを修正するには、各ワーカーメッセージにIDが必要です。IDはディスクに保存する（失敗した場合）か、要求がべき等である必要があります。
- もう1つの問題は、接続が失われると、クライアントが接続できないためにエラーが発生することです。これも事前に準備する必要があるものです。
Redisに関しては、このブログに永続キューの良い例があります。
公式の 推奨 に従います。詳細については、 github repo を確認してください。
Redisの没落：
- Rabbitmqと同様、ワーカーのクラッシュも自分で処理する必要があります。そうしないと、進行中のタスクが失われます。
- ポーリングを行う必要があります。各消費者は、X秒ごとにニュースがあるかどうかを生産者に尋ねる必要があります。
私の意見では、これは最悪のrabbitmqです。
結論
次の理由により、rabbitmqを使用することになります。
- 例を含む、より堅牢な公式オンラインドキュメント。
- 消費者が生産者に投票する必要はありません。
- エラー処理はredisと同じくらい簡単です。
このことを念頭に置いて、この特定のケースでは、このシナリオではredisが最悪のrabbitmqであると確信しています。
それが役に立てば幸い。
実装に関しては、どちらも簡単である必要があります。両方ともさまざまな言語のライブラリを持っています。 redis と rabbitmq をチェックしてください。ここで正直に言うと、私はjavascriptを使用していないので、尊敬されているライブラリがどのように実装またはサポートされているのかわかりません。
チュートリアルで見つけられなかったこと（または見逃している可能性がある 2番目の例 永続キューと永続メッセージとメッセージの確認に関するいくつかの単語がある場合）については、いくつかの説明があります。
パブリッシャーは確かにチュートリアルにないことを確認していますが、 amqp.nodeのリポジトリのgithubの例 があります。
ウサギmqメッセージを使用すると（ほとんどの場合）このように移動しますpublisher -> exchange -> queue -> consumer
そしてこれらの停止のそれぞれで、達成されるべきある種の永続性があります。また、クラスターとキューミラーリングを利用すると、さらに高い信頼性（およびもちろん可用性）を実現できます。
それらの両方のために開発された多くのライブラリがあるので、私は両方とも使いやすいと思います。
Disque、bull、kue、amqplibなど、名前を付けるものがいくつかあります...
それらのドキュメントはかなり良いです。簡単なコピーアンドペーストで、数分で実行できます。
私はsenecaを使用し、seneca amqpはかなり良い例です