Kafka解析

www.jasongj.com/2015/01/02/Kafka深度解析

Terminology:

Broker?
Kafka集群包含一個或多個服務(wù)器，這種服務(wù)器被稱為broker

Topic?
每條發(fā)布到Kafka集群的消息都有一個類別，這個類別被稱為topic。（物理上不同topic的消息分開存儲，邏輯上一個topic的消息雖然保存于一個或多個broker上但用戶只需指定消息的topic即可生產(chǎn)或消費(fèi)數(shù)據(jù)而不必關(guān)心數(shù)據(jù)存于何處）

Partition?
parition是物理上的概念，每個topic包含一個或多個partition，創(chuàng)建topic時可指定parition數(shù)量。每個partition對應(yīng)于一個文件夾，該文件夾下存儲該partition的數(shù)據(jù)和索引文件

Producer?
負(fù)責(zé)發(fā)布消息到Kafka broker

Consumer?
消費(fèi)消息。每個consumer屬于一個特定的consumer group（可為每個consumer指定group name，若不指定group name則屬于默認(rèn)的group）。使用consumer high level API時，同一topic的一條消息只能被同一個consumer group內(nèi)的一個consumer消費(fèi)，但多個consumer group可同時消費(fèi)這一消息。

架構(gòu)：?

一個典型的kafka集群中包含若干producer（可以是web前端產(chǎn)生的page view，或者是服務(wù)器日志，系統(tǒng)CPU、memory等），若干broker（Kafka支持水平擴(kuò)展，一般broker數(shù)量越多，集群吞吐率越高），若干consumer group，以及一個Zookeeper集群。Kafka通過Zookeeper管理集群配置，選舉leader，以及在consumer group發(fā)生變化時進(jìn)行rebalance。producer使用push模式將消息發(fā)布到broker，consumer使用pull模式從broker訂閱并消費(fèi)消息。 　

Consumer Group?
High Level Consumer將從某個Partition讀取的最后一條消息的offset存于ZooKeeper中（ Kafka從0.8.2版本開始同時支持將offset存于Zookeeper中與將offset存于專用的Kafka Topic中 ）。 這個offset基于客戶程序提供給Kafka的名字來保存，這個名字被稱為Consumer Group。 Consumer Group是整個Kafka集群全局的，而非某個Topic的。 每一個High Level Consumer實(shí)例都屬于一個Consumer Group，若不指定則屬于默認(rèn)的Group。

Push vs. Pull

　　作為一個messaging system，Kafka遵循了傳統(tǒng)的方式，選擇由producer向broker push消息并由consumer從broker pull消息。一些logging-centric system，比如Facebook的Scribe和Cloudera的Flume,采用非常不同的push模式。事實(shí)上，push模式和pull模式各有優(yōu)劣。?
　　push模式很難適應(yīng)消費(fèi)速率不同的消費(fèi)者，因?yàn)橄l(fā)送速率是由broker決定的。push模式的目標(biāo)是盡可能以最快速度傳遞消息，但是這樣很容易造成consumer來不及處理消息，典型的表現(xiàn)就是拒絕服務(wù)以及網(wǎng)絡(luò)擁塞。而pull模式則可以根據(jù)consumer的消費(fèi)能力以適當(dāng)?shù)乃俾氏M(fèi)消息。

Topic & Partition

　　Topic在邏輯上可以被認(rèn)為是一個queue。每條消費(fèi)都必須指定它的topic，可以簡單理解為必須指明把這條消息放進(jìn)哪個queue里。為了使得Kafka的吞吐率可以水平擴(kuò)展，物理上把topic分成一個或多個partition，每個partition在物理上對應(yīng)一個文件夾，該文件夾下存儲這個partition的所有消息和索引文件。

Kafka保證同一Consumer Group中只有一個Consumer會消費(fèi)某條消息，實(shí)際上，Kafka保證的是穩(wěn)定狀態(tài)下每一個Consumer實(shí)例只會消費(fèi)某一個或多個特定Partition的數(shù)據(jù)，而某個Partition的數(shù)據(jù)只會被某一個特定的Consumer實(shí)例所消費(fèi)。 也就是說Kafka對消息的分配是以Partition為單位分配的，而非以每一條消息作為分配單元。 這樣設(shè)計的劣勢是無法保證同一個Consumer Group里的Consumer均勻消費(fèi)數(shù)據(jù)，優(yōu)勢是每個Consumer不用都跟大量的Broker通信，減少通信開銷，同時也降低了分配難度，實(shí)現(xiàn)也更簡單。 另外，因?yàn)橥粋€Partition里的數(shù)據(jù)是有序的，這種設(shè)計可以保證每個Partition里的數(shù)據(jù)可以被有序消費(fèi)。?
總結(jié)下來就是：每一個Consumer實(shí)例只會消費(fèi)某一個或多個特定Partition的數(shù)據(jù)，而某個Partition的數(shù)據(jù)只會被某一個特定的Consumer實(shí)例所消費(fèi)。

如果某Consumer Group中Consumer（每個Consumer只創(chuàng)建1個MessageStream）數(shù)量少于Partition數(shù)量，則至少有一個Consumer會消費(fèi)多個Partition的數(shù)據(jù)，如果Consumer的數(shù)量與Partition數(shù)量相同，則正好一個Consumer消費(fèi)一個Partition的數(shù)據(jù)。 而如果Consumer的數(shù)量多于Partition的數(shù)量時，會有部分Consumer無法消費(fèi)該Topic下任何一條消息。

Consumer Rebalance的算法如下：

將目標(biāo)Topic下的所有Partirtion排序，存于PT?
對某Consumer Group下所有Consumer排序，存于CG，第i個Consumer記為Ci?
N=size(PT)/size(CG)，向上取整?
解除Ci對原來分配的Partition的消費(fèi)權(quán)（i從0開始）?
將第i?N到（i+1）?N?1個Partition分配給Ci?
目前，最新版（0.8.2.1）Kafka的Consumer Rebalance的控制策略是由每一個Consumer通過在Zookeeper上注冊Watch完成的。 每個Consumer被創(chuàng)建時會觸發(fā)Consumer Group的Rebalance，具體啟動流程如下：

High Level Consumer啟動時將其ID注冊到其Consumer Group下，在Zookeeper上的路徑為/consumers/[consumer group]/ids/[consumer id]?
在/consumers/[consumer group]/ids上注冊Watch?
在/brokers/ids上注冊Watch?
如果Consumer通過Topic Filter創(chuàng)建消息流，則它會同時在/brokers/topics上也創(chuàng)建Watch?
強(qiáng)制自己在其Consumer Group內(nèi)啟動Rebalance流程?

在這種策略下，每一個Consumer或者Broker的增加或者減少都會觸發(fā)Consumer Rebalance。 因?yàn)槊總€Consumer只負(fù)責(zé)調(diào)整自己所消費(fèi)的Partition，為了保證整個Consumer Group的一致性，當(dāng)一個Consumer觸發(fā)了Rebalance時，該Consumer Group內(nèi)的其它所有其它Consumer也應(yīng)該同時觸發(fā)Rebalance。

如果想更深入的了解 ?請查看http://www.infoq.com/cn/profile/%E9%83%AD%E4%BF%8A

總結(jié)

以上是生活随笔為你收集整理的Kafka基础知识入门的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

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