Redis Cluster vs Pub/SubのZeroMQと水平方向の分散システム

Question

システムの加入者数とチャネル数に応じてスループットを直線的に調整する必要がある巨大な分散システムを設計した方が良いでしょうか？

1）Redis Cluster（Redis 3.0 alphaの場合、クラスタモードの場合は1つのノードで公開し、別の全く別のノードで購読でき、メッセージは伝播して相手に届きます）。 Publishの複雑さは、O（N + M）です（Nはサブスクライブされたクライアントの数、Mはシステム内のサブスクライブされたパターンの数ですが、Redis Clusterの場合はどのように拡張されますか？私はこれについて教育的な推測を受け入れる。

2）ZeroMQ 3.x以降、サーバー側のフィルタリングが行われるため、時間的な複雑さもありますが、ドキュメントでは何も見ていません。規模を拡大したい場合は、どのチャネルにでも多数のサーバーを公開し、各サブスクライバはすべてのサーバーに接続し、目的のチャネルにサブスクライブします。それはいいようです。

だから、どれが巨大な出版社システムの水平スケーリングに適していますか？私が調べなければならない他の解決策は何ですか？レイテンシとスループットは最小限に抑えたいが、水平方向に拡大することができます。

Answer 1

待ち時間を最小限に抑えたいと思います。チャネルの数は無関係です。主な要因は、パブリッシャ数とサブスクライバ数、メッセージサイズ、パブリッシャあたりの1秒あたりのメッセージ数、各サブスクライバが受信するメッセージ数です。 ZeroMQは、1つのノードから別のノードへ、毎秒数百万の小さなメッセージを送信できます。あなたのボトルネックは、それがソフトウェアであるよりずっと前にネットワークになります。したがって、大量の大容量pubsubアーキテクチャは、ZeroMQがサポートするPGMマルチキャストのようなものを使用します。

Answer 2

ZeroMQと同様に、Redisでは、ボトルネックがネットワークになります。レディスは、毎秒何百万ものメッセージに到達することができます。

Redis Clusterの現在の実装では、ノード間バスを使用して、すべてのクラスタノードにPUBLISHメッセージを配信することに注意してください。このアプローチでは、PUBLISHがRedis（このissue on Githubで説明されているように）で非常に安価であることを前提としています。

ただし、ノード間通信である小さなオーバーヘッドがあります。スケールすると、このオーバーヘッドはより重要になります。もう1つはRedis Cluster implementationですが、私は気づいています - 商用のものであることに注意してください - チャネルやパターンがRedisキーの配布方法と同様の方法でクラスタノードに分散されています。少なくともベンダーによれば、これはノード間通信のオーバーヘッドを削減し、パフォーマンスを向上させるはずですが、私はそれをベンチマークしませんでした。