Apache Kafka快速入門(mén)指南

作者：AiChinaTech 2019-11-13 15:44:17

大數(shù)據(jù)

Kafka Kafka是基于發(fā)布訂閱的消息系統(tǒng)。最初起源于LinkedIn，于2011年成為開(kāi)源Apache項(xiàng)目，然后于2012年成為Apache頂級(jí)項(xiàng)目。Kafka用Scala和Java編寫(xiě)，因其分布式可擴(kuò)展架構(gòu)及可持久化、高吞吐率特征而被廣泛使用。

公司主營(yíng)業(yè)務(wù)：網(wǎng)站設(shè)計(jì)、成都網(wǎng)站設(shè)計(jì)、移動(dòng)網(wǎng)站開(kāi)發(fā)等業(yè)務(wù)。幫助企業(yè)客戶真正實(shí)現(xiàn)互聯(lián)網(wǎng)宣傳，提高企業(yè)的競(jìng)爭(zhēng)能力。成都創(chuàng)新互聯(lián)是一支青春激揚(yáng)、勤奮敬業(yè)、活力青春激揚(yáng)、勤奮敬業(yè)、活力澎湃、和諧高效的團(tuán)隊(duì)。公司秉承以“開(kāi)放、自由、嚴(yán)謹(jǐn)、自律”為核心的企業(yè)文化，感謝他們對(duì)我們的高要求，感謝他們從不同領(lǐng)域給我們帶來(lái)的挑戰(zhàn)，讓我們激情的團(tuán)隊(duì)有機(jī)會(huì)用頭腦與智慧不斷的給客戶帶來(lái)驚喜。成都創(chuàng)新互聯(lián)推出左權(quán)免費(fèi)做網(wǎng)站回饋大家。

 簡(jiǎn)介

Kafka是基于發(fā)布訂閱的消息系統(tǒng)。最初起源于LinkedIn，于2011年成為開(kāi)源Apache項(xiàng)目，然后于2012年成為Apache頂級(jí)項(xiàng)目。Kafka用Scala和Java編寫(xiě)，因其分布式可擴(kuò)展架構(gòu)及可持久化、高吞吐率特征而被廣泛使用。

消息隊(duì)列

通常在項(xiàng)目中，我們會(huì)因?yàn)槿缦滦枨蠖胂㈥?duì)列模塊：

1.解耦：消息系統(tǒng)相當(dāng)于在處理過(guò)程中間插入了一個(gè)隱含的、基于數(shù)據(jù)的接口層。無(wú)需預(yù)先定義不同的接口地址和請(qǐng)求應(yīng)答規(guī)范，這允許數(shù)據(jù)上下游獨(dú)立決定雙方的處理過(guò)程，只需要約定數(shù)據(jù)格式即可任意擴(kuò)展服務(wù)類型和業(yè)務(wù)需求。

2.緩沖：消息系統(tǒng)作為一個(gè)緩沖池，應(yīng)對(duì)常見(jiàn)的訪問(wèn)量不均衡情形。比如特殊節(jié)假日的流量劇增和每日不同時(shí)段的訪問(wèn)量差異。以及處理不同數(shù)據(jù)類型所需的不同實(shí)時(shí)性。使整個(gè)業(yè)務(wù)處理架構(gòu)以較低成本獲得一定靈活性。

3. 異步：很多時(shí)候，用戶不想也不需要立即處理消息。消息隊(duì)列提供了異步處理機(jī)制，允許用戶把一個(gè)消息放入隊(duì)列，但并不立即處理它。想向隊(duì)列中放入多少消息就放多少，然后在需要的時(shí)候再去處理它們。

Kafka的特點(diǎn)

作為一種分布式的，基于發(fā)布/訂閱的消息系統(tǒng)。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.支持在線水平擴(kuò)展。

Kafka體系架構(gòu)

如上圖所示，一個(gè)典型的Kafka體系架構(gòu)包括若干Producer(可以是服務(wù)器日志，業(yè) 務(wù)數(shù)據(jù)，頁(yè)面前端產(chǎn)生的page view等等)，若干Broker(Kafka支持水平擴(kuò)展，一般Broker數(shù)量越多，集群吞吐率越高)，若干Consumer (Group)，以及一個(gè)Zookeeper集群。Kafka通過(guò)Zookeeper管理集群配置，選舉leader，以及在Consumer Group發(fā)生變化時(shí)進(jìn)行rebalance。Producer使用push模式將消息發(fā)布到Broker，Consumer使用pull模式從Broker訂閱并消費(fèi)消息。

名詞解釋：

Topic & Partition

一個(gè)topic可以認(rèn)為一個(gè)一類消息，每個(gè)topic將被分成多個(gè)partition，每個(gè)partition在存儲(chǔ)層面是append log文件。任何發(fā)布到此partition的消息都會(huì)被追加到log文件的尾部，每條消息在文件中的位置稱為offset(偏移量)，offset為一個(gè)long型的數(shù)字，它唯一標(biāo)記一條消息。每條消息都被append到partition中，順序?qū)懘疟P(pán)因此效率非常高。這是Kafka高吞吐率的重要基礎(chǔ)。

Producer發(fā)送消息到Broker時(shí)，會(huì)根據(jù)Paritition機(jī)制選擇將其存儲(chǔ)到哪一個(gè)Partition。如果Partition機(jī)制設(shè)置合理，所有消息可以均勻分布到不同的Partition里，這樣就實(shí)現(xiàn)了負(fù)載均衡。如果一個(gè)Topic對(duì)應(yīng)一個(gè)文件，那這個(gè)文件所在的機(jī)器I/O將會(huì)成為這個(gè)Topic的性能瓶頸，而有了Partition后，不同的消息可以并行寫(xiě)入不同Broker的不同Partition里，極大的提高了吞吐率?？梢酝ㄟ^(guò)配置項(xiàng)num.partitions來(lái)指定新建Topic的默認(rèn)Partition數(shù)量，也可在創(chuàng)建Topic時(shí)通過(guò)參數(shù)指定，同時(shí)也可以在Topic創(chuàng)建之后通過(guò)Kafka提供的工具修改。

Kafka的復(fù)制機(jī)制

Kafka 中的每個(gè)主題分區(qū)都被復(fù)制了 n 次，其中的 n 是主題的復(fù)制因子(replication factor)。這允許 Kafka 在集群服務(wù)器發(fā)生故障時(shí)自動(dòng)切換到這些副本，以便在出現(xiàn)故障時(shí)消息仍然可用。Kafka 的復(fù)制是以分區(qū)為粒度的，分區(qū)的預(yù)寫(xiě)日志被復(fù)制到 n 個(gè)服務(wù)器。 在 n 個(gè)副本中，一個(gè)副本作為 leader，其他副本成為 followers。顧名思義，producer 只能往 leader 分區(qū)上寫(xiě)數(shù)據(jù)(讀也只能從 leader 分區(qū)上進(jìn)行)，followers 只按順序從 leader 上復(fù)制日志。

日志復(fù)制算法(log replication algorithm)必須提供的基本保證是，如果它告訴客戶端消息已被提交，而當(dāng)前 leader 出現(xiàn)故障，新選出的 leader 也必須具有該消息。在出現(xiàn)故障時(shí)，Kafka 會(huì)從失去 leader 的 ISR 里面選擇一個(gè) follower 作為這個(gè)分區(qū)新的 leader ;換句話說(shuō)，是因?yàn)檫@個(gè) follower 是跟上 leader 寫(xiě)進(jìn)度的。

每個(gè)分區(qū)的 leader 會(huì)維護(hù)一個(gè) ISR。當(dāng) producer 往 Broker 發(fā)送消息，消息先寫(xiě)入到對(duì)應(yīng) leader 分區(qū)上，然后復(fù)制到這個(gè)分區(qū)的所有副本中。只有將消息成功復(fù)制到所有同步副本(ISR)后，這條消息才算被提交。由于消息復(fù)制延遲受到最慢同步副本的限制，因此快速檢測(cè)慢副本并將其從 ISR 中刪除非常重要。 Kafka 復(fù)制協(xié)議的細(xì)節(jié)會(huì)有些細(xì)微差別。

Kafka的同步機(jī)制

Kafka不是完全同步，也不是完全異步，而是一種ISR(In-Sync Replicas)機(jī)制：

1. leader會(huì)維護(hù)一個(gè)與其基本保持同步的Replica列表，該列表稱為ISR，每個(gè)Partition都會(huì)有一個(gè)ISR，而且是由leader動(dòng)態(tài)維護(hù) 。

2. 如果一個(gè)follower比一個(gè)leader落后太多，或者超過(guò)一定時(shí)間未發(fā)起數(shù)據(jù)復(fù)制請(qǐng)求，則leader將其從ISR中移除

3. 當(dāng)ISR中所有Replica都向Leader發(fā)送ACK時(shí)，leader才commit，這時(shí)候producer才能認(rèn)為一個(gè)請(qǐng)求中的消息都commit了。

Kafka提供了數(shù)據(jù)復(fù)制算法保證，如果leader發(fā)生故障或掛掉，一個(gè)新leader被選舉并被接受客戶端的消息成功寫(xiě)入。Kafka確保從同步副本列表中選舉一個(gè)副本為leader，或者說(shuō)follower追趕leader數(shù)據(jù)。leader負(fù)責(zé)維護(hù)和跟蹤ISR中所有follower滯后的狀態(tài)。當(dāng)Producer發(fā)送一條消息到Broker后，leader寫(xiě)入消息并復(fù)制到所有follower。消息提交之后才被成功復(fù)制到所有的同步副本。消息復(fù)制延遲受最慢的follower限制，重要的是快速檢測(cè)慢副本，如果follower“落后”太多或者失效，leader將會(huì)把它從ISR中刪除。

消息傳輸保障

前面已經(jīng)介紹了Kafka如何進(jìn)行有效的存儲(chǔ)，以及了解了Producer和Consumer如何工作。接下來(lái)討論的是Kafka如何確保消息在Producer和Consumer之間傳輸。有以下三種可能的傳輸保障(delivery guarantee):

• At most once: 消息可能會(huì)丟，但絕不會(huì)重復(fù)傳輸
• At least once：消息絕不會(huì)丟，但可能會(huì)重復(fù)傳輸
• Exactly once：每條消息肯定會(huì)被傳輸一次且僅傳輸一次

Kafka的消息傳輸保障機(jī)制非常直觀。當(dāng)Producer向Broker發(fā)送消息時(shí)，一旦這條消息被commit，由于副本機(jī)制(replication)的存在，它就不會(huì)丟失。但是如果Producer發(fā)送數(shù)據(jù)給Broker后，遇到的網(wǎng)絡(luò)問(wèn)題而造成通信中斷，那producer就無(wú)法判斷該條消息是否已經(jīng)提交(commit)。雖然Kafka無(wú)法確定網(wǎng)絡(luò)故障期間發(fā)生了什么，但是Producer可以retry多次，確保消息已經(jīng)正確傳輸?shù)紹roker中，所以目前Kafka實(shí)現(xiàn)的是At least once。

Consumer從Broker中讀取消息后，可以選擇Commit，該操作會(huì)在Zookeeper中存下該Consumer在該P(yáng)artition下讀取的消息的offset。該Consumer下一次再讀該P(yáng)artition時(shí)會(huì)從下一條開(kāi)始讀取。如未commit，下一次讀取的開(kāi)始位置會(huì)跟上一次commit之后的開(kāi)始位置相同。當(dāng)然也可以將consumer設(shè)置為autocommit，即Consumer一旦讀取到數(shù)據(jù)立即自動(dòng)commit。如果只討論這一讀取消息的過(guò)程，那Kafka是確保了exactly once, 但是如果由于前面Producer與Broker之間的某種原因?qū)е孪⒌闹貜?fù)，那么這里就是At least once。

考慮這樣一種情況，當(dāng)Consumer讀完消息之后先commit再處理消息，在這種模式下，如果consumer在commit后還沒(méi)來(lái)得及處理消息就crash了，下次重新開(kāi)始工作后就無(wú)法讀到剛剛已提交而未處理的消息，這就對(duì)應(yīng)于At most once了。讀完消息先處理再commit。這種模式下，如果處理完了消息在commit之前Consumer crash了，下次重新開(kāi)始工作時(shí)還會(huì)處理剛剛未commit的消息，實(shí)際上該消息已經(jīng)被處理過(guò)了，這就對(duì)應(yīng)于at least once。

要做到exactly once就需要引入消息去重機(jī)制。Kafka文檔中提及GUID(Globally Unique Identifier)的概念，通過(guò)客戶端生成算法得到每個(gè)消息的unique id，同時(shí)可映射至broker上存儲(chǔ)的地址，即通過(guò)GUID便可查詢提取消息內(nèi)容，也便于發(fā)送方的冪等性保證，需要在broker上提供此去重處理模塊，目前版本尚不支持。

針對(duì)GUID, 如果從客戶端的角度去重，那么需要引入集中式緩存，必然會(huì)增加依賴復(fù)雜度，另外緩存的大小難以界定。不只是Kafka, 類似RabbitMQ以及RocketMQ這類商業(yè)級(jí)中間件也只保障at least once, 且也無(wú)法從自身去進(jìn)行消息去重。所以我們建議業(yè)務(wù)方根據(jù)自身的業(yè)務(wù)特點(diǎn)進(jìn)行去重，比如業(yè)務(wù)消息本身具備冪等性，或者借助Redis等其他產(chǎn)品進(jìn)行去重處理。

Kafka作為消息隊(duì)列：

傳統(tǒng)的消息有兩種模式：隊(duì)列和發(fā)布訂閱。 在隊(duì)列模式中，消費(fèi)者池從服務(wù)器讀取消息(每個(gè)消息只被其中一個(gè)讀取); 發(fā)布訂閱模式：消息廣播給所有的消費(fèi)者。這兩種模式都有優(yōu)缺點(diǎn)，隊(duì)列的優(yōu)點(diǎn)是允許多個(gè)消費(fèi)者瓜分處理數(shù)據(jù)，這樣可以擴(kuò)展處理。但是，隊(duì)列不像多個(gè)訂閱者，一旦消息者進(jìn)程讀取后故障了，那么消息就丟了。而發(fā)布和訂閱允許你廣播數(shù)據(jù)到多個(gè)消費(fèi)者，由于每個(gè)訂閱者都訂閱了消息，所以沒(méi)辦法縮放處理。

Kafka中的Consumer Group有兩種形式：

a、隊(duì)列：允許同名的消費(fèi)者組成員共同處理。

b、發(fā)布訂閱：廣播消息給多個(gè)消費(fèi)者組。

Kafka的每個(gè)topic都具有這兩種模式。

傳統(tǒng)的消息系統(tǒng)按順序保存數(shù)據(jù)，如果多個(gè)消費(fèi)者從隊(duì)列消費(fèi)，則服務(wù)器按存儲(chǔ)的順序發(fā)送消息，但是，盡管服務(wù)器按順序發(fā)送，多個(gè)并行請(qǐng)求將會(huì)是異步的，因此消息可能亂序到達(dá)。這意味著只要消息存在并行消費(fèi)的情況，順序就無(wú)法保證。消息系統(tǒng)常常通過(guò)僅設(shè)1個(gè)消費(fèi)者來(lái)解決這個(gè)問(wèn)題，但是這意味著沒(méi)用到并行處理。

Kafka有比傳統(tǒng)的消息系統(tǒng)更強(qiáng)的順序保證。通過(guò)并行Topic的Parition，Kafka提供了順序保證和負(fù)載均衡。每個(gè)Partition僅由同一個(gè)消費(fèi)者組中的一個(gè)消費(fèi)者消費(fèi)到。并確保消費(fèi)者是該P(yáng)artition的唯一消費(fèi)者，并按順序消費(fèi)數(shù)據(jù)。每個(gè)topic有多個(gè)分區(qū)，則需要對(duì)多個(gè)消費(fèi)者做負(fù)載均衡，但請(qǐng)注意，相同的消費(fèi)者組中不能有比分區(qū)更多的消費(fèi)者，否則多出的消費(fèi)者一直處于空等待，不會(huì)收到消息。

Kafka作為存儲(chǔ)系統(tǒng)

所有發(fā)布消息到消息隊(duì)列和消費(fèi)分離的系統(tǒng)，實(shí)際上都充當(dāng)了一個(gè)臨時(shí)存儲(chǔ)系統(tǒng)。Kafka還是一個(gè)非常高性能的存儲(chǔ)系統(tǒng)。寫(xiě)入到Kafka的數(shù)據(jù)將寫(xiě)到磁盤(pán)并復(fù)制到集群中保證容錯(cuò)性。并允許生產(chǎn)者等待消息應(yīng)答，直到消息完全寫(xiě)入。Kafka的存儲(chǔ)結(jié)構(gòu)保證無(wú)論服務(wù)器上有50KB或50TB數(shù)據(jù)，執(zhí)行效率是相似的，因此可達(dá)到水平擴(kuò)展的目標(biāo)。還可以認(rèn)為Kafka是一種專用于高性能，低延遲，提交日志存儲(chǔ)，復(fù)制，和傳播特殊用途的分布式文件系統(tǒng)。

Kafka流處理

Kafka的更高目標(biāo)是實(shí)時(shí)流處理。在Kafka中，流處理持續(xù)獲取輸入topic的數(shù)據(jù)，進(jìn)行處理加工，然后寫(xiě)入輸出topic。例如，一個(gè)零售APP，接收銷售和出貨的輸入流，統(tǒng)計(jì)數(shù)量或調(diào)整價(jià)格后輸出。

簡(jiǎn)單的需求可以直接使用Producer和Consumer API進(jìn)行處理。對(duì)于復(fù)雜的轉(zhuǎn)換，Kafka提供了更強(qiáng)大的Streams API，可構(gòu)建聚合計(jì)算或連接流到一起的復(fù)雜應(yīng)用程序。

綜上所述，Kafka 的設(shè)計(jì)可以幫助我們解決很多架構(gòu)上的問(wèn)題。但是想要用好 Kafka 的高性能、低耦合、高可靠性等特性，我們需要非常了解 Kafka，以及我們自身的業(yè)務(wù)需求，綜合考慮應(yīng)用場(chǎng)景。

【本文是51CTO專欄機(jī)構(gòu)“AiChinaTech”的原創(chuàng)文章，微信公眾號(hào)( id: tech-AI)”】

分享名稱：ApacheKafka快速入門(mén)指南
文章源于：http://www.5511xx.com/article/dhieoog.html