如果我要設計一個巨大的分佈式系統，其吞吐量應該與系統中用戶數和通道數成線性關係，那會更好嗎？Redis Cluster與ZeroMQ在Pub/Sub中，用於橫向擴展的分佈式系統
1）Redis羣集（僅適用於Redis 3.0 alpha，如果它處於羣集模式，您可以在一個節點中發佈並在另一個完全不同的節點中訂閱，並且這些消息將傳播併到達您）。發佈的複雜度爲O（N + M），其中N是訂閱客戶端的數量，M是系統中訂閱模式的數量，但在Redis集羣中它如何擴展？我接受有關這方面的教育猜測。
2）ZeroMQ自3.x以來，它進行服務器端過濾，所以它也有一些時間複雜性，但在文檔中我沒有看到它。如果我想擴展它，我可以將很多服務器發佈到任何頻道，並且每個訂閱者將連接到所有服務器，並訂閱所需的頻道。這似乎很好。
那麼哪個更適合大型發佈者系統的水平縮放呢？我應該考慮哪些其他解決方案？請記住，我想盡量減少延遲和吞吐量，但能夠水平擴展。
我想你想盡量減少延遲。頻道數量無關緊要。關鍵因素是發佈者數量和用戶數量，郵件大小，每個發佈者每秒的郵件數量，每個訂閱者收到的郵件數量，大致。 ZeroMQ每秒可以從一個節點到另一個節點執行數百萬條小信息;在軟件出現之前，你的瓶頸將是網絡。因此，大多數高容量的pubsub體系結構都使用諸如ZeroMQ支持的PGM多播之類的東西。
在Redis中，就像ZeroMQ一樣，瓶頸將成爲網絡。 Redis每秒可以達到數百萬條消息，至少與ZeroMQ一樣多。
您應該知道，Redis Cluster的當前實現使用節點間總線在所有羣集節點上分發PUBLISH消息。這種方法假定在Redis上PUBLISH是非常便宜的（如在issue on Github中所解釋的）。
然而，涉及的是小節點間的通信。隨着你擴大規模，這個開銷會更加顯着。我還注意到另一個Redis Cluster implementation - 請注意它是一個商業版本 - 其中渠道或模式以類似於Redis密鑰分發方式的方式跨羣集節點分佈。至少根據廠商的說法，這應該可以節省節點間通信的開銷並提高性能，但我自己並沒有進行基準測試。
是否有數據支持您的索賠？你可以閱讀我的問題嗎？ http://stackoverflow.com/questions/26319304/redis-of-channels-degrading-latency-how-to-prevent-degradation – ealeon