Kafka 是LinkedIn 開(kāi)發(fā)的一個(gè)高性能、分布式的消息系統(tǒng)，廣泛用于日志收集、流式數(shù)據(jù)處理、在線和離線消息分發(fā)等場(chǎng)景。雖然不是作為傳統(tǒng)的MQ來(lái)設(shè)計(jì)，在大部分情況，Kafaka 也可以代替原先ActiveMQ 等傳統(tǒng)的消息系統(tǒng)。

Kafka 將消息流按Topic 組織，保存消息的服務(wù)器稱(chēng)為Broker，消費(fèi)者可以訂閱一個(gè)或者多個(gè)Topic。為了均衡負(fù)載，一個(gè)Topic 的消息又可以劃分到多個(gè)分區(qū)(Partition)，分區(qū)越多，Kafka并行能力和吞吐量越高。

Kafka 集群需要zookeeper 支持來(lái)實(shí)現(xiàn)集群，最新的kafka 發(fā)行包中已經(jīng)包含了zookeeper，部署的時(shí)候可以在一臺(tái)服務(wù)器上同時(shí)啟動(dòng)一個(gè)zookeeper Server 和 一個(gè)Kafka Server，也可以使用已有的其他zookeeper集群。

和傳統(tǒng)的MQ不同，消費(fèi)者需要自己保留一個(gè)offset，從kafka 獲取消息時(shí)，只拉去當(dāng)前offset 以后的消息。Kafka 的scala/java 版的client 已經(jīng)實(shí)現(xiàn)了這部分的邏輯，將offset 保存到zookeeper 上。每個(gè)消費(fèi)者可以選擇一個(gè)id，同樣id 的消費(fèi)者對(duì)于同一條消息只會(huì)收到一次。一個(gè)Topic 的消費(fèi)者如果都使用相同的id，就是傳統(tǒng)的 Queue；如果每個(gè)消費(fèi)者都使用不同的id, 就是傳統(tǒng)的pub-sub.

如果在MQ的場(chǎng)景下，將Kafka 和 ActiveMQ 相比:

Kafka 的優(yōu)點(diǎn)

分布式可高可擴(kuò)展。Kafka 集群可以透明的擴(kuò)展，增加新的服務(wù)器進(jìn)集群。 高性能。Kafka 的性能大大超過(guò)傳統(tǒng)的ActiveMQ、RabbitMQ等MQ 實(shí)現(xiàn)，尤其是Kafka 還支持batch 操作。下圖是linkedin 的消費(fèi)者性能壓測(cè)結(jié)果: 容錯(cuò)。Kafka每個(gè)Partition的數(shù)據(jù)都會(huì)復(fù)制到幾臺(tái)服務(wù)器上。當(dāng)某個(gè)Broker故障失效時(shí)，ZooKeeper服務(wù)將通知生產(chǎn)者和消費(fèi)者，生產(chǎn)者和消費(fèi)者轉(zhuǎn)而使用其它Broker。

Kafka 的不利

重復(fù)消息。Kafka 只保證每個(gè)消息至少會(huì)送達(dá)一次，雖然幾率很小，但一條消息有可能會(huì)被送達(dá)多次。?
消息亂序。雖然一個(gè)Partition 內(nèi)部的消息是保證有序的，但是如果一個(gè)Topic 有多個(gè)Partition，Partition 之間的消息送達(dá)不保證有序。?
復(fù)雜性。Kafka需要zookeeper 集群的支持，Topic通常需要人工來(lái)創(chuàng)建，部署和維護(hù)較一般消息隊(duì)列成本更高

=-=======================================================================

00

今天讓我們來(lái)談?wù)勆矸莞哔F，舉止優(yōu)雅的消息中間件，主要還是淺談，消息中間件這塊水太深。大體上我們結(jié)合互聯(lián)網(wǎng)業(yè)務(wù)做一些探討，從互聯(lián)網(wǎng)主要關(guān)心的消息安全性，服務(wù)器的穩(wěn)定性容錯(cuò)性以及吞吐量三方面來(lái)講。

由于這塊產(chǎn)品非常多，我只挑選兩個(gè)我使用過(guò)的產(chǎn)品結(jié)合使用經(jīng)驗(yàn)做一些研究，他們是ActiveMQ和Kafka，前者完全實(shí)現(xiàn)了JMS的規(guī)范，后者看上去有一些“野路子”，并沒(méi)有糾結(jié)于JMS規(guī)范，劍走偏鋒的設(shè)計(jì)了另一套吞吐非常高的分布式發(fā)布-訂閱消息系統(tǒng)，目前非常流行。接下來(lái)我們結(jié)合三個(gè)點(diǎn)（消息安全性，服務(wù)器的穩(wěn)定性容錯(cuò)性以及吞吐量）來(lái)分別談?wù)勥@兩個(gè)消息中間件。今天我們談Kafka，ActiveMQ的文章在此。

01 性能怪獸Kafka

Kafka是LinkedIn開(kāi)源的分布式發(fā)布-訂閱消息系統(tǒng)，目前歸屬于Apache定級(jí)項(xiàng)目。”Apache Kafka is publish-subscribe messaging rethought as a distributed commit log.”，官網(wǎng)首頁(yè)的一句話(huà)高度概括其職責(zé)。Kafka并沒(méi)有遵守JMS規(guī)范，他只用文件系統(tǒng)來(lái)管理消息的生命周期。Kafka的設(shè)計(jì)目標(biāo)是：

（1）以時(shí)間復(fù)雜度為O(1)的方式提供消息持久化能力，即使對(duì)TB級(jí)以上數(shù)據(jù)也能保證常數(shù)時(shí)間復(fù)雜度的訪問(wèn)性能。

（2）高吞吐率。即使在非常廉價(jià)的商用機(jī)器上也能做到單機(jī)支持每秒100K條以上消息的傳輸。

（3）支持Kafka Server間的消息分區(qū)，及分布式消費(fèi)，同時(shí)保證每個(gè)Partition內(nèi)的消息順序傳輸。

（4）同時(shí)支持離線數(shù)據(jù)處理和實(shí)時(shí)數(shù)據(jù)處理。

（5）Scale out：支持在線水平擴(kuò)展。

所以，不像AMQ，Kafka從設(shè)計(jì)開(kāi)始極為高可用為目的，天然HA。broker支持集群，消息亦支持負(fù)載均衡，還有副本機(jī)制。同樣，Kafka也是使用Zookeeper管理集群節(jié)點(diǎn)信息，包括consumer的消費(fèi)信息也是保存在zk中，下面我們分話(huà)題來(lái)談：

1）消息的安全性

Kafka集群中的Leader負(fù)責(zé)某一topic的某一partition的消息的讀寫(xiě)，理論上consumer和producer只與該Leader節(jié)點(diǎn)打交道，一個(gè)集群里的某一broker即是Leader的同時(shí)也可以擔(dān)當(dāng)某一partition的follower，即Replica。Kafka分配Replica的算法如下：

（1）將所有Broker（假設(shè)共n個(gè)Broker）和待分配的Partition排序

（2）將第i個(gè)Partition分配到第（i mod n）個(gè)Broker上

（3）將第i個(gè)Partition的第j個(gè)Replica分配到第（(i + j) mode n）個(gè)Broker上

同時(shí)，Kafka與Replica既非同步也不是嚴(yán)格意義上的異步。一個(gè)典型的Kafka發(fā)送-消費(fèi)消息的過(guò)程如下：首先首先Producer消息發(fā)送給某Topic的某Partition的Leader，Leader先是將消息寫(xiě)入本地Log，同時(shí)follower（如果落后過(guò)多將會(huì)被踢出出Replica列表）從Leader上pull消息，并且在未寫(xiě)入log的同時(shí)即向Leader發(fā)送ACK的反饋，所以對(duì)于某一條已經(jīng)算作commit的消息來(lái)講，在某一時(shí)刻，其存在于Leader的log中，以及Replica的內(nèi)存中。這可以算作一個(gè)危險(xiǎn)的情況（聽(tīng)起來(lái)嚇人），因?yàn)槿绻藭r(shí)集群掛了這條消息就算丟失了，但結(jié)合producer的屬性（request.required.acks=2 當(dāng)所有follower都收到消息后返回ack）可以保證在絕大多數(shù)情況下消息的安全性。當(dāng)消息算作commit的時(shí)候才會(huì)暴露給consumer，并保證at-least-once的投遞原則。

2）服務(wù)的穩(wěn)定容錯(cuò)性

前面提到過(guò)，Kafka天然支持HA，整個(gè)leader/follower機(jī)制通過(guò)zookeeper調(diào)度，它在所有broker中選出一個(gè)controller，所有Partition的Leader選舉都由controller決定，同時(shí)controller也負(fù)責(zé)增刪Topic以及Replica的重新分配。如果Leader掛了，集群將在ISR（in-sync replicas）中選出新的Leader，選舉基本原則是：新的Leader必須擁有原來(lái)的Leader commit過(guò)的所有消息。假如所有的follower都掛了，Kafka會(huì)選擇第一個(gè)“活”過(guò)來(lái)的Replica（不一定是ISR中的）作為L(zhǎng)eader，因?yàn)槿绻藭r(shí)等待ISR中的Replica是有風(fēng)險(xiǎn)的，假如所有的ISR都無(wú)法“活”，那此partition將會(huì)變成不可用。

3） 吞吐量

Leader節(jié)點(diǎn)負(fù)責(zé)某一topic（可以分成多個(gè)partition）的某一partition的消息的讀寫(xiě)，任何發(fā)布到此partition的消息都會(huì)被直接追加到log文件的尾部，因?yàn)槊織l消息都被append到該partition中，是順序?qū)懘疟P(pán)，因此效率非常高（經(jīng)驗(yàn)證，順序?qū)懘疟P(pán)效率比隨機(jī)寫(xiě)內(nèi)存還要高，這是Kafka高吞吐率的一個(gè)很重要的保證），同時(shí)通過(guò)合理的partition，消息可以均勻的分布在不同的partition里面。Kafka基于時(shí)間或者partition的大小來(lái)刪除消息，同時(shí)broker是無(wú)狀態(tài)的，consumer的消費(fèi)狀態(tài)(offset)是由consumer自己控制的（每一個(gè)consumer實(shí)例只會(huì)消費(fèi)某一個(gè)或多個(gè)特定partition的數(shù)據(jù)，而某個(gè)partition的數(shù)據(jù)只會(huì)被某一個(gè)特定的consumer實(shí)例所消費(fèi)），也不需要broker通過(guò)鎖機(jī)制去控制消息的消費(fèi)，所以吞吐量驚人，這也是Kafka吸引人的地方。

最后說(shuō)下由于zookeeper引起的腦裂（Split Brain）問(wèn)題：每個(gè)consumer分別單獨(dú)通過(guò)Zookeeper判斷哪些partition down了，那么不同consumer從Zookeeper“看”到的view就可能不一樣，這就會(huì)造成錯(cuò)誤的reblance嘗試。而且有可能所有的consumer都認(rèn)為rebalance已經(jīng)完成了，但實(shí)際上可能并非如此。

總結(jié)

以上是生活随笔為你收集整理的Kafka 对比 ActiveMQ的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。