分布式系 AR con 出隊 很多 lower ado 簡單 角色

RabbitMQ
Redis
ZeroMQ
ActiveMQ
Kafka/Jafka
相關概念
RabbitMQ是使用Erlang編寫的一個開源的消息隊列，本身支持很多的協議：AMQP，XMPP, SMTP, STOMP，也正因如此，它非常重量級，更適合於企業級的開發。同時實現了Broker構架，這意味著消息在發送給客戶端時先在中心隊列排隊。對路由，負載均衡或者數據持久化都有很好的支持。

Redis是一個基於Key-Value對的NoSQL數據庫，開發維護很活躍。雖然它是一個Key-Value數據庫存儲系統，但它本身支持MQ功能，所以完全可以當做一個輕量級的隊列服務來使用。對於RabbitMQ和Redis的入隊和出隊操作，各執行100萬次，每10萬次記錄一次執行時間。測試數據分為128Bytes、512Bytes、1K和10K四個不同大小的數據。實驗表明：入隊時，當數據比較小時Redis的性能要高於RabbitMQ，而如果數據大小超過了10K，Redis則慢的無法忍受；出隊時，無論數據大小，Redis都表現出非常好的性能，而RabbitMQ的出隊性能則遠低Redis。

ZeroMQ號稱最快的消息隊列系統，尤其針對大吞吐量的需求場景。ZeroMQ能夠實現RabbitMQ不擅長的高級/復雜的隊列，但是開發人員需要自己組合多種技術框架，技術上的復雜度是對這MQ能夠應用成功的挑戰。ZeroMQ具有一個獨特的非中間件的模式，你不需要安裝和運行一個消息服務器或中間件，因為你的應用程序將扮演這個服務器角色。你只需要簡單的引用ZeroMQ程序庫，可以使用NuGet安裝，然後你就可以愉快的在應用程序之間發送消息了。但是ZeroMQ僅提供非持久性的隊列，也就是說如果宕機，數據將會丟失。其中，Twitter的Storm 0.9.0以前的版本中默認使用ZeroMQ作為數據流的傳輸（Storm從0.9版本開始同時支持ZeroMQ和Netty作為傳輸模塊）。

ActiveMQ是Apache下的一個子項目。 類似於ZeroMQ，它能夠以代理人和點對點的技術實現隊列。同時類似於
RabbitMQ，它少量代碼就可以高效地實現高級應用場景。Kafka是Apache下的一個子項目，是一個高性能跨語言分布式發布/訂閱消息隊列系統，而Jafka是在Kafka之上孵化而來的，即Kafka的一個升級版。具有以下特性：快速持久化，可以在O(1)的系統開銷下進行消息持久化；高吞吐，在一臺普通的服務器上既可以達到10W/s的吞吐速率；完全的分布式系統，Broker、Producer、Consumer都原生自動支持分布式，自動實現負載均衡；支持Hadoop數據並行加載，對於像Hadoop的一樣的日誌數據和離線分析系統，但又要求實時處理的限制，這是一個可行的解決方案。Kafka通過Hadoop的並行加載機制統一了在線和離線的消息處理。Apache Kafka相對於ActiveMQ是一個非常輕量級的消息系統，除了性能非常好之外，還是一個工作良好的分布式系統

producer： 消息生產者，發布消息到 kafka 集群的終端或服務。 broker： kafka 集群中包含的服務器。 topic：每條發布到 kafka 集群的消息屬於的類別，即 kafka 是面向 topic 的。 partition： partition 是物理上的概念，每個topic 包含一個或多個 partition。kafka 分配的單位是 partition。 consumer： 從 kafka 集群中消費消息的終端或服務。 Consumer group： high-level consumer API 中，每個 consumer 都屬於一個 consumer group，每條消息只能被 consumer group 中的一個 Consumer 消費，但可以被多個 consumer group 消費。 replica： partition的副本，保障 partition 的高可用。 leader： replica 中的一個角色， producer 和 consumer 只跟 leader 交互。
follower： replica 中的一個角色，從 leader 中復制數據。 controller： kafka 集群中的其中一個服務器，用來進行leader election 以及 各種 failover。 zookeeper： kafka 通過 zookeeper 來存儲集群的 meta 信息

常用Message Queue對比