阿里-測(cè)試開發(fā)面經(jīng)（八）

rabbitMQ:

    RabbitMQ是基于Erlang語言編寫的開源消息隊(duì)列，通過Erlang的Actor模型實(shí)現(xiàn)了數(shù)據(jù)的穩(wěn)定可靠傳輸。

    RabbitMQ遵循AMQP協(xié)議，RabbitMQ的broker由Exchange,Binding,queue組成，其中exchange和binding組成了消息的路由  鍵；

    客戶端Producer通過連接channel和server進(jìn)行通信，Consumer從queue獲取消息進(jìn)行消費(fèi)（長連接，queue有消息會(huì)推送到consumer端，consumer循環(huán)從輸入流讀取數(shù)據(jù)）。rabbitMQ以broker為中心；有消息的確認(rèn)機(jī)制。

    因?yàn)槠淇蓴U(kuò)展性，可以通過插件的形式使用STOMP、XMPP、AMQP 1.0，還可以通過插件使用HTTP這種非消息的傳輸協(xié)議。所以，RabbitMQ可以說是適應(yīng)性非常強(qiáng)的一個(gè)消息隊(duì)列中間件了。

    當(dāng)然，不僅是協(xié)議支持的多，還因?yàn)樗鼘?shí)現(xiàn)了代理(Broker)架構(gòu)，意味著消息在發(fā)送到客戶端之前可以在中央節(jié)點(diǎn)上排隊(duì)。此特性使得RabbitMQ易于使用和部署，適宜于很多場(chǎng)景如路由、負(fù)載均衡或消息持久化等，用消息隊(duì)列只需幾行代碼即可搞定。但是，這使得它的可擴(kuò)展性差，速度較慢，因?yàn)橹醒牍?jié)點(diǎn)增加了延遲，消息封裝后也比較大，如需配置RabbitMQ則需要在目標(biāo)機(jī)器上安裝Erlang環(huán)境。

    rabbitMQ支持miror的queue，主queue失效，miror queue接管。

    rabbitMQ的負(fù)載均衡需要單獨(dú)的load balance來實(shí)現(xiàn).

    rabbitMQ在吞吐量方面稍遜于kafka，他們的出發(fā)點(diǎn)不一樣，rabbitMQ支持對(duì)消息的可靠的傳遞，支持事務(wù)，不支持批量的

    操作；基于存儲(chǔ)的可靠性的要求存儲(chǔ)可以采用內(nèi)存或者硬盤。

    總的來說，RabbitMQ在數(shù)據(jù)一致性、穩(wěn)定性和可靠性方面比較優(yōu)秀，而且直接或間接的支持多種協(xié)議，對(duì)多種語言支持良好。但是其性能和吞吐量差強(qiáng)人意，由于Erlang語言本身的限制，二次開發(fā)成本較高。

kafka:

    Kafka是LinkedIn于2010年12月開發(fā)并開源的一個(gè)分布式流平臺(tái)，現(xiàn)在是Apache的頂級(jí)項(xiàng)目，是一個(gè)高性能跨語言分布式

    Publish/Subscribe消息隊(duì)列系統(tǒng)，以Pull的形式消費(fèi)消息。

    具有以下特性：快速持久化，可以在O(1)的系統(tǒng)開銷下進(jìn)行消息持久化；高吞吐，在一臺(tái)普通的服務(wù)器上既可以達(dá)到10W/s的吞吐速率；完全的分布式系統(tǒng)，Broker、Producer、Consumer都原生自動(dòng)支持分布式，自動(dòng)實(shí)現(xiàn)復(fù)雜均衡。因?yàn)樵O(shè)計(jì)之初是作為日志流平臺(tái)和運(yùn)營消息管道平臺(tái)，所以實(shí)現(xiàn)了消息順序和海量堆積。

    kafka遵從一般的MQ結(jié)構(gòu)，producer，broker，consumer，以consumer為中心，消息的消費(fèi)信息保存的客戶端consumer上，consumer根據(jù)消費(fèi)的點(diǎn)，從broker上批量pull數(shù)據(jù)；無消息確認(rèn)機(jī)制。

    kafka具有高的吞吐量，內(nèi)部采用消息的批量處理，zero-copy機(jī)制，數(shù)據(jù)的存儲(chǔ)和獲取是本地磁盤順序批量操作，具有O(1)的復(fù)雜度，消息處理的效率很高。

    kafka的broker支持主備模式。

    kafka采用zookeeper對(duì)集群中的broker、consumer進(jìn)行管理，可以注冊(cè)topic到zookeeper上；通過zookeeper的協(xié)調(diào)機(jī)制，producer保存對(duì)應(yīng)topic的broker信息，可以隨機(jī)或者輪詢發(fā)送到broker上；并且producer可以基于語義指定分片，消息發(fā)送到broker的某分片上。

    支持Hadoop數(shù)據(jù)并行加載，對(duì)于像Hadoop的一樣的日志數(shù)據(jù)和離線分析系統(tǒng)，但又要求實(shí)時(shí)處理的限制，這是一個(gè)可行的解決方案。Kafka通過Hadoop的并行加載機(jī)制來統(tǒng)一了在線和離線的消息處理。

    Apache Kafka相對(duì)于ActiveMQ是一個(gè)非常輕量級(jí)的消息系統(tǒng)，除了性能非常好之外，還是一個(gè)工作良好的分布式系統(tǒng)。

    Kafka自身服務(wù)與消息的生產(chǎn)和消費(fèi)都依賴于Zookeeper，使用Scala語言開發(fā)。因?yàn)槠湎⒌南M(fèi)使用客戶端Pull方式，消息可以被多個(gè)客戶端消費(fèi)，理論上消息會(huì)重復(fù)，但是不會(huì)丟失（除非消息過期）。因此比較常用的場(chǎng)景是作為日志傳輸?shù)南⑵脚_(tái)。

ZeroMQ:

    ZeroMQ號(hào)稱是“史上最快的消息隊(duì)列”，尤其針對(duì)大吞吐量的需求場(chǎng)景,基于c語言開發(fā)的，可以在任何平臺(tái)通過任何代碼連接，通過inproc、IPC、TCP、TIPC、多播傳送消息，支持發(fā)布-訂閱、推-拉、共享隊(duì)列等模式，高速異步I/O引擎。

    ZMQ能夠?qū)崿F(xiàn)RabbitMQ不擅長的高級(jí)/復(fù)雜的隊(duì)列，但是開發(fā)人員需要自己組合多種技術(shù)框架，技術(shù)上的復(fù)雜度是對(duì)這MQ能夠應(yīng)用成功的挑戰(zhàn)。ZeroMQ具有一個(gè)獨(dú)特的非中間件的模式，你不需要安裝和運(yùn)行一個(gè)消息服務(wù)器或中間件，因?yàn)槟愕膽?yīng)用程序?qū)缪萘诉@個(gè)服務(wù)角色。你只需要簡單的引用ZeroMQ程序庫，可以使用NuGet安裝，然后你就可以愉快的在應(yīng)用程序之間發(fā)送消息了。

    但是ZeroMQ僅提供非持久性的隊(duì)列，也就是說如果down機(jī)，數(shù)據(jù)將會(huì)丟失。

    根據(jù)官方的說法，ZeroMQ是一個(gè)簡單好用的傳輸層，像框架一樣的可嵌入的socket類庫，使Socket編程更加簡單、簡潔、性      能更高，是專門為高吞吐量/低延遲的場(chǎng)景開發(fā)的。ZeroMQ與其他MQ有著本質(zhì)的區(qū)別，它根本不是消息隊(duì)列服務(wù)器，更類似      與一個(gè)底層網(wǎng)絡(luò)通訊庫，對(duì)原有Socket API進(jìn)行封裝，在使用的使用引入對(duì)應(yīng)的jar包即可，可謂是相當(dāng)靈活。

    同時(shí)，因?yàn)樗暮唵戊`活，如果我們想作為消息隊(duì)列使用的話，需要開發(fā)大量代碼。而且，ZeroMQ不支持消息持久化，其定位并不是安全可靠的消息傳輸，所以還需要自己編碼保證可靠性。簡而言之一句話，ZeroMQ很強(qiáng)大，但是想用好需要自己實(shí)現(xiàn)。

ActiveMQ:

    是Apache下的一個(gè)子項(xiàng)目,介于ZeroMQ和RabbitMQ之間。類似于ZeroMQ，它能夠以代理人和點(diǎn)對(duì)點(diǎn)的技術(shù)實(shí)現(xiàn)隊(duì)列,可以部      署于代理模式和P2P模式。同時(shí)類似于RabbitMQ，它少量代碼就可以高效地實(shí)現(xiàn)高級(jí)應(yīng)用場(chǎng)景而且只需付出低消耗。被譽(yù)為消息中間件的“瑞士軍刀”。

    支持OpenWire、Stomp、AMQP v1.0、MQTT v3.1、REST、Ajax、Webservice等多種協(xié)議；完全支持JMS1.1和J2EE 1.4規(guī)      范（事務(wù)、持久化、XA消息）；支持持久化到數(shù)據(jù)庫。但是ActiveMQ不夠輕巧，而且對(duì)于隊(duì)列較多的情況支持不好，據(jù)說還有丟消息的情況。

    目前已經(jīng)有了其下一代消息產(chǎn)品Apollo。

    RabbitMQ、ZeroMQ、ActiveMQ均支持常用的多種語言客戶端 C++、Java、.Net,、Python、Php、 Ruby等。  

rocketMQ:

    RocketMQ是阿里開源的消息中間件，目前在Apache孵化，使用純Java開發(fā)，具有高吞吐量、高可用性、適合大規(guī)模分布式系統(tǒng)應(yīng)用的特點(diǎn)。RocketMQ思路起源于Kafka，但并不是簡單的復(fù)制，它對(duì)消息的可靠傳輸及事務(wù)性做了優(yōu)化，目前在阿里集團(tuán)被廣泛應(yīng)用于交易、充值、流計(jì)算、消息推送、日志流式處理、binglog分發(fā)等場(chǎng)景，支撐了阿里多次雙十一活動(dòng)。

    因?yàn)槭前⒗飪?nèi)部從實(shí)踐到產(chǎn)品的產(chǎn)物，因此里面很多接口、api并不是很普遍適用。其可靠性毋庸置疑，而且與Kafka一脈相承（甚至更優(yōu)），性能強(qiáng)勁，支持海量堆積。不過據(jù)說，沒有在mq核心上實(shí)現(xiàn)JMS，但是也無傷大雅。  

總結(jié):

    rabbitMQ穩(wěn)定,可靠,數(shù)據(jù)一致,支持多協(xié)議,有消息確認(rèn),性能一般,基于erlang語言,二次開發(fā)困難.

    kafka高吞吐,高性能,快速持久化,無消息確認(rèn),無消息遺漏,可能會(huì)有有重復(fù)消息,依賴于zookeeper,成本高.

    ZeroMQ靈活快速,不支持持久化,需要大量編碼來實(shí)現(xiàn)穩(wěn)定可靠.

    ActiveMQ不夠靈活輕巧,對(duì)隊(duì)列較多情況支持不好.

    rocketMQ性能好,高吞吐,高可用性,支持大規(guī)模分布式.