kafka與傳統的消息中間件對比

RabbitMQ和kafka從幾個角度簡單的對比

業界對於消息的傳遞有多種方案和產品，本文就比較有表明性的兩個MQ(rabbitMQ,kafka)進行闡述和作簡單的對比，

在應用場景方面，

RabbitMQ,遵循AMQP協議，由內在高併發的erlanng語言開發，用在實時的對可靠性要求比較高的消息傳遞上。

kafka是Linkedin於2010年12月份開源的消息發佈訂閱系統,它主要用於處理活躍的流式數據,大數據量的數據處理上。

1)在架構模型方面，

RabbitMQ遵循AMQP協議，RabbitMQ的broker由Exchange,Binding,queue組成，其中exchange和binding組成了消息的路由鍵；客戶端Producer經過鏈接channel和server進行通訊，Consumer從queue獲取消息進行消費（長鏈接，queue有消息會推送到consumer端，consumer循環從輸入流讀取數據）。rabbitMQ以broker爲中心；有消息的確認機制。

kafka聽從通常的MQ結構，producer，broker，consumer，以consumer爲中心，消息的消費信息保存的客戶端consumer上，consumer根據消費的點，從broker上批量pull數據；無消息確認機制。

2)在吞吐量，

kafka具備高的吞吐量，內部採用消息的批量處理，zero-copy機制，數據的存儲和獲取是本地磁盤順序批量操做，具備O(1)的複雜度，消息處理的效率很高。

rabbitMQ在吞吐量方面稍遜於kafka，他們的出發點不同，rabbitMQ支持對消息的可靠的傳遞，支持事務，不支持批量的操做；基於存儲的可靠性的要求存儲能夠採用內存或者硬盤。

3)在可用性方面，

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

kafka的broker支持主備模式。

4)在集羣負載均衡方面，

kafka採用zookeeper對集羣中的broker、consumer進行管理，能夠註冊topic到zookeeper上；經過zookeeper的協調機制，producer保存對應topic的broker信息，能夠隨機或者輪詢發送到broker上；而且producer能夠基於語義指定分片，消息發送到broker的某分片上。

rabbitMQ的負載均衡須要單獨的loadbalancer進行支持。

原文：http://wbj0110.iteye.com/blog/1974988

收集的rabbitmq資料以下：

http://jzhihui.iteye.com/category/195005

http://lynnkong.iteye.com/blog/1699684

http://blog.csdn.net/anzhsoft/article/details/19607841

http://ybbct.iteye.com/blog/1562326

 

Kafka 對比 ActiveMQ

 

Kafka 是LinkedIn 開發的一個高性能、分佈式的消息系統，普遍用於日誌收集、流式數據處理、在線和離線消息分發等場景。雖然不是做爲傳統的MQ來設計，在大部分狀況，Kafaka 也能夠代替原先ActiveMQ 等傳統的消息系統。

Kafka 將消息流按Topic 組織，保存消息的服務器稱爲Broker，消費者能夠訂閱一個或者多個Topic。爲了均衡負載，一個Topic 的消息又能夠劃分到多個分區(Partition)，分區越多，Kafka並行能力和吞吐量越高。

Kafka 集羣須要zookeeper 支持來實現集羣，最新的kafka 發行包中已經包含了zookeeper，部署的時候能夠在一臺服務器上同時啓動一個zookeeper Server 和 一個Kafka Server，也可使用已有的其餘zookeeper集羣。

和傳統的MQ不一樣，消費者須要本身保留一個offset，從kafka 獲取消息時，只拉去當前offset 之後的消息。Kafka 的scala/java 版的client 已經實現了這部分的邏輯，將offset 保存到zookeeper 上。每一個消費者能夠選擇一個id，一樣id 的消費者對於同一條消息只會收到一次。一個Topic 的消費者若是都使用相同的id，就是傳統的 Queue；若是每一個消費者都使用不一樣的id, 就是傳統的pub-sub.

　　ActiveMQ和Kafka，前者徹底實現了JMS的規範，後者看上去有一些「野路子」，並無糾結於JMS規範，劍走偏鋒的設計了另外一套吞吐很是高的分佈式發佈-訂閱消息系統，目前很是流行。接下來咱們結合三個點（消息安全性，服務器的穩定性容錯性以及吞吐量）來分別談談這兩個消息中間件。今天咱們談Kafka，ActiveMQ的文章在此。

　　01 性能怪獸Kafka
　　Kafka是LinkedIn開源的分佈式發佈-訂閱消息系統，目前歸屬於Apache定級項目。」Apache Kafka is publish-subscribe messaging rethought as a distributed commit log.」，官網首頁的一句話高度歸納其職責。Kafka並無遵照JMS規範，他只用文件系統來管理消息的生命週期。Kafka的設計目標是：
（1）以時間複雜度爲O(1)的方式提供消息持久化能力，即便對TB級以上數據也能保證常數時間複雜度的訪問性能。
（2）高吞吐率。即便在很是廉價的商用機器上也能作到單機支持每秒100K條以上消息的傳輸。
（3）支持Kafka Server間的消息分區，及分佈式消費，同時保證每一個Partition內的消息順序傳輸。
（4）同時支持離線數據處理和實時數據處理。
（5）Scale out：支持在線水平擴展。
　　因此，不像AMQ，Kafka從設計開始極爲高可用爲目的，自然HA。broker支持集羣，消息亦支持負載均衡，還有副本機制。一樣，Kafka也是使用Zookeeper管理集羣節點信息，包括consumer的消費信息也是保存在zk中，下面咱們分話題來談：
1）消息的安全性
Kafka集羣中的Leader負責某一topic的某一partition的消息的讀寫，理論上consumer和producer只與該Leader 節點打交道，一個集羣裏的某一broker便是Leader的同時也能夠擔當某一partition的follower，即Replica。Kafka分配Replica的算法以下：
（1）將全部Broker（假設共n個Broker）和待分配的Partition排序
（2）將第i個Partition分配到第（i mod n）個Broker上
（3）將第i個Partition的第j個Replica分配到第（(i + j) mode n）個Broker上
同時，Kafka與Replica既非同步也不是嚴格意義上的異步。一個典型的Kafka發送-消費消息的過程以下：首先首先Producer消息發送給某Topic的某Partition的Leader，Leader先是將消息寫入本地Log，同時follower（若是落後過多將會被踢出出 Replica列表）從Leader上pull消息，而且在未寫入log的同時即向Leader發送ACK的反饋，因此對於某一條已經算做commit的消息來說，在某一時刻，其存在於Leader的log中，以及Replica的內存中。這能夠算做一個危險的狀況（聽起來嚇人），由於若是此時集羣掛了這條消息就算丟失了，但結合producer的屬性（request.required.acks=2 當全部follower都收到消息後返回ack）能夠保證在絕大多數狀況下消息的安全性。當消息算做commit的時候纔會暴露給consumer，並保證at-least-once的投遞原則。
2）服務的穩定容錯性
前面提到過，Kafka自然支持HA，整個leader/follower機制經過zookeeper調度，它在全部broker中選出一個 controller，全部Partition的Leader選舉都由controller決定，同時controller也負責增刪Topic以及 Replica的從新分配。若是Leader掛了，集羣將在ISR（in-sync replicas）中選出新的Leader，選舉基本原則是：新的Leader必須擁有原來的Leader commit過的全部消息。假如全部的follower都掛了，Kafka會選擇第一個「活」過來的Replica（不必定是ISR中的）做爲 Leader，由於若是此時等待ISR中的Replica是有風險的，假如全部的ISR都沒法「活」，那此partition將會變成不可用。
3） 吞吐量
Leader節點負責某一topic（能夠分紅多個partition）的某一partition的消息的讀寫，任何發佈到此partition的消息都會被直接追加到log文件的尾部，由於每條消息都被append到該partition中，是順序寫磁盤，所以效率很是高（經驗證，順序寫磁盤效率比隨機寫內存還要高，這是Kafka高吞吐率的一個很重要的保證），同時經過合理的partition，消息能夠均勻的分佈在不一樣的partition裏面。 Kafka基於時間或者partition的大小來刪除消息，同時broker是無狀態的，consumer的消費狀態(offset)是由 consumer本身控制的（每個consumer實例只會消費某一個或多個特定partition的數據，而某個partition的數據只會被某一個特定的consumer實例所消費），也不須要broker經過鎖機制去控制消息的消費，因此吞吐量驚人，這也是Kafka吸引人的地方。
最後說下因爲zookeeper引發的腦裂（Split Brain）問題：每一個consumer分別單獨經過Zookeeper判斷哪些partition down了，那麼不一樣consumer從Zookeeper「看」到的view就可能不同，這就會形成錯誤的reblance嘗試。並且有可能全部的 consumer都認爲rebalance已經完成了，但實際上可能並不是如此。

 

若是在MQ的場景下，將Kafka 和 ActiveMQ 相比:

Kafka 的優勢

分佈式可高可擴展。Kafka 集羣能夠透明的擴展，增長新的服務器進集羣。

高性能。Kafka 的性能大大超過傳統的ActiveMQ、RabbitMQ等MQ 實現，尤爲是Kafka 還支持batch 操做。下圖是linkedin 的消費者性能壓測結果:

 

容錯。Kafka每一個Partition的數據都會複製到幾臺服務器上。當某個Broker故障失效時，ZooKeeper服務將通知生產者和消費者，生產者和消費者轉而使用其它Broker。

Kafka 的不利

重複消息。Kafka 只保證每一個消息至少會送達一次，雖然概率很小，但一條消息有可能會被送達屢次。 消息亂序。雖然一個Partition 內部的消息是保證有序的，可是若是一個Topic 有多個Partition，Partition 之間的消息送達不保證有序。 複雜性。Kafka須要zookeeper 集羣的支持，Topic一般須要人工來建立，部署和維護較通常消息隊列成本更高