Jafka/Kafka
kafka（能將消息分散到不同的節(jié)點上）是LinkedIn于2010年12月開發(fā)并開源的一個分布式MQ系統(tǒng)，現在是Apache的一個孵化項目，是一個高性能跨語言分布式Publish/Subscribe消息隊列系統(tǒng)，而Jafka是在Kafka之上孵化而來的，即Kafka的一個升級版。具有以下特性：快速持久化，可以在O(1)的系統(tǒng)開銷下進行消息持久化；高吞吐，在一臺普通的服務器上既可以達到10W/s的吞吐速率；完全的分布式系統(tǒng)，Broker、Producer、Consumer都原生自動支持分布式，自動實現復雜均衡；支持Hadoop數據并行加載，對于像Hadoop的一樣的日志數據和離線分析系統(tǒng)，但又要求實時處理的限制，這是一個可行的解決方案。Kafka通過Hadoop的并行加載機制來統(tǒng)一了在線和離線的消息處理，這一點也是本課題所研究系統(tǒng)所看重的。Apache Kafka相對于ActiveMQ是一個非常輕量級的消息系統(tǒng)，除了性能非常好之外，還是一個工作良好的分布式系統(tǒng)。
Apache ActiveMQ
ActiveMQ居于兩者(RabbitMQ & ZeroMQ)之間，類似于ZemoMQ，它可以部署于代理模式和P2P模式。類似于RabbitMQ，它易于實現高級場景，而且只需付出低消耗。
ActiveMQ被譽為Java世界的中堅力量。它有很長的歷史，而且被廣泛的使用。它還是跨平臺的，給那些非微軟平臺的產品提供了一個天然的集成接入點。然而，它只有跑過了MSMQ才有可能被考慮。如需配置ActiveMQ則需要在目標機器上安裝Java環(huán)境。
需要注意一點的是ActiveMQ的下一代產品為Apollo，Apollo以ActiveMQ原型為基礎，是一個更快、更可靠、更易于維護的消息代理工具。Apache稱Apollo為最快、最強健的STOMP（Streaming Text Orientated Message Protocol，流文本定向消息協議）服務器。
Apollo的特性如下：
支持Stomp 1.0和Stomp 1.1協議
主題和隊列
隊列瀏覽器
主題持久訂閱
鏡像隊列
可靠的消息傳遞
消息過期和交換
消息選擇器
JAAS驗證
基于ACL的授權
支持SSL/TLS，證書驗證
REST Management API
Redis
是一個Key-Value的NoSQL數據庫，開發(fā)維護很活躍，雖然它是一個Key-Value數據庫存儲系統(tǒng)，但它本身支持MQ功能，所以完全可以當做一個輕量級的隊列服務來使用。對于RabbitMQ和Redis的入隊和出隊操作，各執(zhí)行100萬次，每10萬次記錄一次執(zhí)行時間。測試數據分為128Bytes、512Bytes、1K和10K四個不同大小的數據。實驗表明：入隊時，當數據比較小時Redis的性能要高于RabbitMQ，而如果數據大小超過了10K，Redis則慢的無法忍受；出隊時，無論數據大小，Redis都表現出非常好的性能，而RabbitMQ的出隊性能則遠低于Redis。
MemcacheQ
持久化消息隊列memcacheq(簡稱mcq)是一個輕量級的消息隊列，MemcacheQ的特性：
1 簡單易用
2 處理速度快
3 多條隊列
4 并發(fā)性能好
5 與memcache的協議兼容。這就意味著只要裝了memcache的extension就可以了，不需要額外的插件。
6 在zend framework中使用也很方便。
就像你看到的，ZeroMQ和其它的不是一個級別。它的性能驚人的高。盡管這樣，但這個產品不提供消息持久化、無法方便存儲及監(jiān)控中間過程，需要自己實現審計和數據恢復，因此在易用性和HA上不是令人滿意。結論很清楚：如果你希望一個應用程序發(fā)送消息越快越好，你選擇ZeroMQ。當你不太在意偶然會丟失某些消息的情況下更有價值。
本文博主未來往事更希望(也不是很希望很希望)選擇使用的是Rabbit，Rabbitmq內置了ha，如果組建cluster，負載均衡之類的問題就無需擔憂了同時可以設置隊列鏡像。但這種事情是應該做更多的測試，你最終會有一個最愛，我所聽到的、讀到的各種關于Rabbit的事情讓我覺得它應該是最佳選擇。
其他一些隊列列表，這里就不再一一分析，如果需要了解更多可自行google。
聯系客服
