redis は pub-sub をサポートします
zmq は、メッセージブローカーを介して pub-subもサポートします
それらの間で選択するための建築の長所と短所は何でしょうか?
実行すべき明らかなユースケース固有のパフォーマンスベンチマークを超えたポイントを目指しています(ここに いい例 があります)。
Pythonなどの高水準言語の使用を想定しています。
私はPythonでZeroMQとRedisの両方を扱ってきました。 ZeroMQはより堅牢で、本当にシンプルなロードバランシングを提供します。また、リクエストリプライなどのpub-subよりも優れています。ただし、pub-subの後にしかない場合は、redisの方がはるかに簡単です。
Redisサーバーがクラッシュまたは動作を停止した場合、すべてのクライアントも動作を停止します。ZeroMQでは、サーバーがなくてもクライアントは動作します。
どちらのサービスも、Ruby、Python、C、C++などのプログラミング言語で利用できます。
要するに、redisははるかに単純で、非常に信頼できます。 ZeroMQは非常に信頼できますが、より複雑です。
私がpub subだけを行っている場合は、redisを選択し、それ以外の場合はZeroMQを選択します。大量のトラフィックを予測する場合は、ZeroMQを選択します
ZeroMqの長所/短所
NEWS
サブスクリプションはNEWS*
メッセージと一致しますRedisの長所/短所
news.*
などの選択的なトピックサブスクリプションのワイルドカードマッチングをサポート分散システムの通信レイヤーにRedis pubsubとZMQ pubsubのどちらを使用するかを決定する必要があるため、私はこれを自分で調査しました。 RedisとZMQは、アプリケーションのセットアップ方法が異なると思います。
ZMQ pubsubは本質的に直接接続します。つまり、仲介者はありません。
フォワーダーデバイスなどの中間者のようなインスタンスを作成できます
Redis pubsubの場合、サブスクライバーとパブリッシャーの両方がRedisに接続する必要があります。
ZMQには仲介者がいないため、サブスクライバーは何らかの方法でパブリッシャーに接続してメッセージを取得する必要があります。アプリケーションがサブスクライバーに情報を送信する必要があるパブリッシャーを生成する私のシステムでは、アプリケーションが開始する前にサブスクライバーが接続するフォワーダーデバイスがなければ、これを行う方法はありません。
リモートボックスで可能な限り高速に処理を実行したいので、システムでは遅延が問題になります。
Zmq (direct pubsub)
avg: 0.000235867897669
max: 0.0337719917297
min: 0.000141143798828
Zmq (w/ forwarder)
Avg: 0.00237249334653
max: 0.00536799430847
min: 0.000249862670898
Redis (8gb ram)
avg: 0.000687216520309
max: 0.0483138561249
min: 0.000313997268677
Redis (32gb ram)
avg: 0.000272458394368
max: 0.00277805328369
min: 0.000216960906982
これが私が決める方法です。各製品を使用して最小限のテストケースを作成します。どちらがより簡単に構築され、うまく機能するかを確認してください。各テストケースをもう少し押して、1行を過度の作業として破棄します。