1. 程式人生 > >訊息佇列種類及特點

訊息佇列種類及特點

站在很多巨人肩膀上對常見的MQ做了總結,目前對訊息佇列還不是很明白,希望能與大家一起進步.

rabbitMQ:
    RabbitMQ是基於Erlang語言編寫的開源訊息佇列,通過Erlang的Actor模型實現了資料的穩定可靠傳輸。
    RabbitMQ遵循AMQP協議,RabbitMQ的broker由Exchange,Binding,queue組成,其中exchange和binding組成了訊息的路由         鍵;
    客戶端Producer通過連線channel和server進行通訊,Consumer從queue獲取訊息進行消費(長連線,queue有訊息會推送到
    consumer端,consumer迴圈從輸入流讀取資料)。rabbitMQ以broker為中心;有訊息的確認機制。
    因為其可擴充套件性,可以通過外掛的形式使用STOMP、XMPP、AMQP 1.0,還可以通過外掛使用HTTP這種非訊息的傳輸協          議。所以,RabbitMQ可以說是適應性非常強的一個訊息佇列中介軟體了。
    當然,不僅是協議支援的多,還因為它實現了代理(Broker)架構,意味著訊息在傳送到客戶端之前可以在中央節點上排隊。此
    特性使得RabbitMQ易於使用和部署,適宜於很多場景如路由、負載均衡或訊息持久化等,用訊息佇列只需幾行程式碼即可搞          定。但是,這使得它的可擴充套件性差,速度較慢,因為中央節點增加了延遲,訊息封裝後也比較大,如需配置RabbitMQ則需要        在目標機器上安裝Erlang環境。
    rabbitMQ支援miror的queue,主queue失效,miror queue接管。
    rabbitMQ的負載均衡需要單獨的load balance來實現.
    rabbitMQ在吞吐量方面稍遜於kafka,他們的出發點不一樣,rabbitMQ支援對訊息的可靠的傳遞,支援事務,不支援批量的
    操作;基於儲存的可靠性的要求儲存可以採用記憶體或者硬碟。
    總的來說,RabbitMQ在資料一致性、穩定性和可靠性方面比較優秀,而且直接或間接的支援多種協議,對多種語言支援良          好。但是其效能和吞吐量差強人意,由於Erlang語言本身的限制,二次開發成本較高。


kafka:
    Kafka是LinkedIn於2010年12月開發並開源的一個分散式流平臺,現在是Apache的頂級專案,是一個高效能跨語言分散式
    Publish/Subscribe訊息佇列系統,以Pull的形式消費訊息。
    具有以下特性:快速持久化,可以在O(1)的系統開銷下進行訊息持久化;高吞吐,在一臺普通的伺服器上既可以達到10W/s
    的吞吐速率;完全的分散式系統,Broker、Producer、Consumer都原生自動支援分散式,自動實現複雜均衡。因為設計之初
    是作為日誌流平臺和運營訊息管道平臺,所以實現了訊息順序和海量堆積。
    kafka遵從一般的MQ結構,producer,broker,consumer,以consumer為中心,訊息的消費資訊儲存的客戶端consumer上,
    consumer根據消費的點,從broker上批量pull資料;無訊息確認機制。
    kafka具有高的吞吐量,內部採用訊息的批量處理,zero-copy機制,資料的儲存和獲取是本地磁碟順序批量操作,具有O(1)
    的複雜度,訊息處理的效率很高。
    kafka的broker支援主備模式。
    kafka採用zookeeper對叢集中的broker、consumer進行管理,可以註冊topic到zookeeper上;通過zookeeper的協調機制,
    producer儲存對應topic的broker資訊,可以隨機或者輪詢傳送到broker上;並且producer可以基於語義指定分片,訊息發
    送到broker的某分片上。
    支援Hadoop資料並行載入,對於像Hadoop的一樣的日誌資料和離線分析系統,但又要求實時處理的限制,這是一個可行的解
    決方案。Kafka通過Hadoop的並行載入機制來統一了線上和離線的訊息處理。
    Apache Kafka相對於ActiveMQ是一個非常輕量級的訊息系統,除了效能非常好之外,還是一個工作良好的分散式系統。
    
    Kafka自身服務與訊息的生產和消費都依賴於Zookeeper,使用Scala語言開發。因為其訊息的消費使用客戶端Pull方式,訊息
    可以被多個客戶端消費,理論上訊息會重複,但是不會丟失(除非訊息過期)。因此比較常用的場景是作為日誌傳輸的訊息平       臺。


ZeroMQ:
    ZeroMQ號稱是“史上最快的訊息佇列”,尤其針對大吞吐量的需求場景,基於c語言開發的,可以在任何平臺通過任何程式碼連            接,  通過inproc、IPC、TCP、TIPC、多播傳送訊息,支援釋出-訂閱、推-拉、共享佇列等模式,高速非同步I/O引擎。
    ZMQ能夠實現RabbitMQ不擅長的高階/複雜的佇列,但是開發人員需要自己組合多種技術框架,技術上的複雜度是對這MQ能      夠應用成功的挑戰。ZeroMQ具有一個獨特的非中介軟體的模式,你不需要安裝和執行一個訊息伺服器或中介軟體,因為你的應用      程式將扮演了這個服務角色。你只需要簡單的引用ZeroMQ程式庫,可以使用NuGet安裝,然後你就可以愉快的在應用程式之      間傳送訊息了。
    但是ZeroMQ僅提供非永續性的佇列,也就是說如果down機,資料將會丟失。
    根據官方的說法,ZeroMQ是一個簡單好用的傳輸層,像框架一樣的可嵌入的socket類庫,使Socket程式設計更加簡單、簡潔、性      能更高,是專門為高吞吐量/低延遲的場景開發的。ZeroMQ與其他MQ有著本質的區別,它根本不是訊息佇列伺服器,更類似      與一個底層網路通訊庫,對原有Socket API進行封裝,在使用的使用引入對應的jar包即可,可謂是相當靈活。
    同時,因為它的簡單靈活,如果我們想作為訊息佇列使用的話,需要開發大量程式碼。而且,ZeroMQ不支援訊息持久化,其定      位並不是安全可靠的訊息傳輸,所以還需要自己編碼保證可靠性。簡而言之一句話,ZeroMQ很強大,但是想用好需要自己實      現。

ActiveMQ:
    是Apache下的一個子專案,介於ZeroMQ和RabbitMQ之間。類似於ZeroMQ,它能夠以代理人和點對點的技術實現佇列,可以部      署於代理模式和P2P模式。同時類似於RabbitMQ,它少量程式碼就可以高效地實現高階應用場景而且只需付出低消耗。被譽為        訊息中介軟體的“瑞士軍刀”。
    支援OpenWire、Stomp、AMQP v1.0、MQTT v3.1、REST、Ajax、Webservice等多種協議;完全支援JMS1.1和J2EE 1.4規      範(事務、持久化、XA訊息);支援持久化到資料庫。但是ActiveMQ不夠輕巧,而且對於佇列較多的情況支援不好,據說還      有丟訊息的情況。
    目前已經有了其下一代訊息產品Apollo。
    RabbitMQ、ZeroMQ、ActiveMQ均支援常用的多種語言客戶端 C++、Java、.Net,、Python、Php、 Ruby等。  

rocketMQ:
    RocketMQ是阿里開源的訊息中介軟體,目前在Apache孵化,使用純Java開發,具有高吞吐量、高可用性、適合大規模分散式
    系統應用的特點。RocketMQ思路起源於Kafka,但並不是簡單的複製,它對訊息的可靠傳輸及事務性做了優化,目前在阿里
    集團被廣泛應用於交易、充值、流計算、訊息推送、日誌流式處理、binglog分發等場景,支撐了阿里多次雙十一活動。
    因為是阿里內部從實踐到產品的產物,因此裡面很多介面、api並不是很普遍適用。其可靠性毋庸置疑,而且與Kafka一脈相
    承(甚至更優),效能強勁,支援海量堆積。不過據說,沒有在mq核心上實現JMS,但是也無傷大雅。  

總結:
    rabbitMQ穩定,可靠,資料一致,支援多協議,有訊息確認,效能一般,基於erlang語言,二次開發困難.
    kafka高吞吐,高效能,快速持久化,無訊息確認,無訊息遺漏,可能會有有重複訊息,依賴於zookeeper,成本高.
    ZeroMQ靈活快速,不支援持久化,需要大量編碼來實現穩定可靠.
    ActiveMQ不夠靈活輕巧,對佇列較多情況支援不好.
    rocketMQ效能好,高吞吐,高可用性,支援大規模分散式.

    ZeroMQ小而美,RabbitMQ大而穩,Kakfa和RocketMQ快而強勁。