千鋒扣丁學(xué)堂大數(shù)據(jù)培訓(xùn)之帶你解讀Apache Kafka
2019-07-17 10:15:20
2994瀏覽
今天千鋒扣丁學(xué)堂
大數(shù)據(jù)培訓(xùn)老師給大家分享一篇關(guān)于Apache Kafka的詳細(xì)介紹，首先Kafka在世界享有盛名，大部分互聯(lián)網(wǎng)公司都在使用它，那么它到底是什么呢?讓我們一步一步地來理解他，隨后深入探討其工作原理。
一、介紹
Kafka由LinkedIn公司于2011年推出，自那時起功能逐步迭代，目前演變成一個完整的平臺級產(chǎn)品，它允許您冗余地存儲巨大的數(shù)據(jù)量，擁有一個具有巨大吞吐量(數(shù)百萬/秒)的消息總線，并且支持實時流任務(wù)處理?？偟膩碚f，Kafka是一個分布式，可水平擴(kuò)展，容錯的日志提交系統(tǒng)
這些描述都非常抽象，讓我們一個接一個地理解它們的意思，隨后深入探討其工作原理。
二、分布式
分布式系統(tǒng)意味著不同機(jī)器上的服務(wù)實例一起工作成一個整體為用戶提供完整的服務(wù)，Kafka的分布式體現(xiàn)在存儲、接收信息、發(fā)送信息在不同的節(jié)點上，它帶來的好處是可擴(kuò)展性和容錯性。
三、水平可擴(kuò)展
我們先給垂直可擴(kuò)展下一個定義，比如說，你的傳統(tǒng)數(shù)據(jù)庫服務(wù)開始變得超負(fù)載，可以通過簡單地擴(kuò)充該服務(wù)器資源(CPURAMSSD)緩存這個問題，這就叫垂直擴(kuò)展-單點增加資源，不過有兩大致命的缺點：底層硬件資源有限、需要停機(jī)操作。反之，水平擴(kuò)展通過增加更多的機(jī)器部署服務(wù)解決類似問題。
四、容錯
分布式系統(tǒng)被設(shè)計成可容許一定程序的錯誤，不像單點部署發(fā)生異常時整體服務(wù)都將不可用，有五個節(jié)點的Kafka實例，即使有2個節(jié)點宕機(jī)了仍能繼續(xù)工作。
五、commit日志
一個commit日記類似預(yù)寫式日記(WAL)和事務(wù)日記，它是可追加的有序的持久化數(shù)據(jù)，無法進(jìn)行修改或者刪除。
這種結(jié)構(gòu)是Kafka的核心，它具備排序功能，而排序則可以保證確定性的處理，這兩者都是分布式系統(tǒng)中的重要問題。
Kafka通常會將消息持久化到磁盤上，它充分利用磁盤的有序讀取特性，讀寫的時間復(fù)雜度都為O(1),這是相當(dāng)了不起的，另外讀取和寫入操作不會相互影響，寫入不會加鎖阻塞讀取操作。
六、如何工作的
生產(chǎn)者發(fā)到消息至KafkaNode節(jié)點，存儲在主題Topic中，消費者訂閱主題以接收消息，這是一個生產(chǎn)訂閱模式。為了使一個節(jié)點Topic的數(shù)據(jù)量不至過大，Kafka引入分區(qū)的概念，從而具備更好的性能和伸縮性。Kafka保證分區(qū)內(nèi)的所有消息都按照到達(dá)順序排序，區(qū)分消息的方式是通過其偏移量offset，你可以將其理解為普通數(shù)組的下標(biāo)索引。
Kafka中Broker服務(wù)節(jié)點是愚蠢的，消費者是聰明的，Kafka不會記錄消費者讀取的操作和刪除消息，相反，數(shù)據(jù)被存儲一段時間或者達(dá)到一定的大小閾值，消費者可以自由調(diào)整偏移量offset以重復(fù)獲取他們想要的消息或者舍棄。
值得注意的是為了避免進(jìn)程兩次讀取相同的消息，Kafka引入了消費者組的概念，其中包含一個或者多個消息者實例，約定每個組只能同時有一個實例消費分區(qū)的消息。不過這引來了一個麻煩，連社區(qū)也無力解決，也就是Kafka中的重平衡Rebalance問題,它本質(zhì)是一種協(xié)議，規(guī)定一個消費者組下的所有消費者實例如何達(dá)成一致，來分配訂閱主題的每個分區(qū)，當(dāng)組成員數(shù)發(fā)生變更、訂閱主題數(shù)發(fā)生變更、訂閱主題的分區(qū)數(shù)發(fā)生變更時都會觸發(fā)Rebalance，從而達(dá)到最公平的分配策略，不過他和GC的STW類似，在Rebalance期間，所有的消費者實例都會停止消費，然后重新分配連接。我們應(yīng)該盡量避免這種情況的發(fā)生，盡量讓消費實例數(shù)等于分區(qū)數(shù)。
七、持久化至磁盤
正如前面提及的，Kafk將消息存儲至磁盤而不是內(nèi)存RAM，你或許會驚訝它是如何做出這種選擇的，背后應(yīng)該有許多優(yōu)化使其可行，沒錯，事實上優(yōu)化點包括：
Kafka的通信協(xié)議支持消息合并，減少網(wǎng)絡(luò)流量傳輸，Broker節(jié)點一次持續(xù)存儲大量數(shù)據(jù)，消費者可以一次獲取大量的消息
操作系統(tǒng)通過提前讀入(read-ahead)和write-behind緩存技術(shù)，使得磁盤上的線性讀寫速度快，現(xiàn)代磁盤速度慢的結(jié)論是基于需要磁盤搜索的場景
現(xiàn)代操作系統(tǒng)引入頁面緩存(Pagecache)技術(shù)，頁緩沖由多個磁盤塊構(gòu)造，在linux讀寫文件時，它用于緩存文件的邏輯內(nèi)容，從而加塊對磁盤映射和數(shù)據(jù)的訪問
Kafka存儲消息使用的是不可變的標(biāo)準(zhǔn)二進(jìn)制格式，可以充分利用零拷貝技術(shù)(zero-copy),將數(shù)據(jù)從頁緩存直接復(fù)制到socket通道中
八、數(shù)據(jù)分布式和復(fù)制
我們來談?wù)凨afka如何實現(xiàn)容錯以及如何在節(jié)點間分配數(shù)據(jù)。
Kafka將分區(qū)數(shù)據(jù)拷貝復(fù)制到多個Brokers節(jié)點上，避免某個Broker死亡導(dǎo)致數(shù)據(jù)不可達(dá)。每時每刻，一個Broker節(jié)點”擁有”一個分區(qū)，并且是應(yīng)用程序從該分區(qū)讀取寫入的節(jié)點，這稱為分區(qū)leader，它將收到的數(shù)據(jù)復(fù)制到其他N個Broker節(jié)點上，它們稱為follower,并準(zhǔn)備好在leader節(jié)點死亡時被選舉為leader。這種模式使得消息不易丟失，你可以根據(jù)消息的重要程序合理調(diào)整replicationfactor參數(shù)，下圖是4個Broker節(jié)點，擁有3個復(fù)制副本的示例：
你或許會有疑問，生產(chǎn)者或者消費者是如何正確得知分區(qū)的leader是哪個節(jié)點的?事實上，Kafka將這些信息保存到Zookeeper服務(wù)中。
九、Zookeeper服務(wù)
Zookeeper是一個分布式KV對目錄存儲系統(tǒng)，特點是可靠性高、讀取性能高，但是寫入性能差，常被用于存儲元數(shù)據(jù)和保存集群狀態(tài)，包括心跳、配置等等。
Kafka將以下消息保存至Zookeeper中：
消費者組的每個分區(qū)的偏移量，不過后來Kafka將其保存至內(nèi)部主題__consumer_offsets中
訪問權(quán)限列表
生產(chǎn)者和消費者速率限定額度
分區(qū)leader信息和它們的健康狀態(tài)
十、Controller控制器
一個分布式系統(tǒng)肯定是可協(xié)調(diào)的，當(dāng)事件發(fā)生時，節(jié)點必須以某種方式做出反應(yīng)，控制器負(fù)責(zé)決定集群如何做出反應(yīng)并指示節(jié)點做某事，它是功能不能過于復(fù)雜的Broker節(jié)點，最主要的職責(zé)是負(fù)責(zé)節(jié)點下線和重新加入時重平衡和分配新的分區(qū)leader。
控制器從ZooKeeperWatch事件中可以得知某個Broker節(jié)點實例下線(或者節(jié)點過期，一般發(fā)生于Broker長時間繁忙導(dǎo)致心跳異常)的情況，然后做出反應(yīng)，決定哪些節(jié)點應(yīng)成為受影響分區(qū)的新leader，然后通知每個相關(guān)的follower通過leaderAndlsr請求開始從新的leader復(fù)制數(shù)據(jù)。
從上面可以得知，原本作為分區(qū)leader的Broker節(jié)點實例重啟后，它將不再擔(dān)任任何分區(qū)的leader，消費者也不會從這個節(jié)點上讀取消息，這導(dǎo)致了資源的浪費，幸運的是，Kafka有一個被稱為優(yōu)先副本(preferredleaderreplica)的概念-你可以理解成原先為該分區(qū)leader節(jié)點(通過brokerid區(qū)分)的副本,如果該副本可用，Kafka會將集群恢復(fù)成之前狀態(tài)，通過設(shè)置auto.leader.rebalance.enabled=true可以使得這個過程自動觸發(fā)，默認(rèn)值為true。
Broker節(jié)點下線通常都是短暫的，這意味著一段時間后會恢復(fù)，這就是為什么當(dāng)一個節(jié)點離開集群時，與之關(guān)聯(lián)的元數(shù)據(jù)不會被刪除，如果它是一個分區(qū)的跟隨者，系統(tǒng)也不會為此分區(qū)重新分配新的跟隨者。
但是需要注意的是，恢復(fù)加入的節(jié)點不能立即拿回其上次的leader地位，它還沒有資格。
十一、ISR
副本同步隊列ISR(in-syncreplicas)，它是由leader維護(hù)的，follower從leader同步數(shù)據(jù)是有延遲的，任意一個超過閾值都會被剔除出ISR列表,存入OSR(Outof-SyncReplicas)列表中，新加入的follower也會先存放在OSR中。
一個follower想被選舉成leader，它必須在ISR隊列中才有資格,不過，在沒有同步副本存在并且已有l(wèi)eader都下線的邊緣情況下，可以選擇可用性而不是一致性。
ISR列表維護(hù)標(biāo)準(zhǔn)如下：
它在過去的X秒內(nèi)有完整同步leader消息，通過replica.lag.time.max.ms配置約定
它在過去的X秒內(nèi)向Zookeeper發(fā)送了一個心跳，通過zookeeper.session.timeout.ms配置約定
十二、生產(chǎn)者acks設(shè)置
明顯，存在一系列意外事件會導(dǎo)致leader下線，假如leader節(jié)點接收到生產(chǎn)者的消息，在存儲并且響應(yīng)ack后節(jié)點崩潰了,此時Kafka會從ISR列表中選舉一個新的leader,但是由于生產(chǎn)者ack配置默認(rèn)為1,意思是只考慮leader接收情況不考慮follower同步情況，最終導(dǎo)致部分消息丟失了，所以我們應(yīng)該在生產(chǎn)者端設(shè)置acks=all，要求每條數(shù)據(jù)必須是寫入所有副本之后，才能認(rèn)為是寫成功，另外一層意思是起碼有一個leader和一個follower。不過這種設(shè)置影響集群性能，降低了吞吐量，使得生產(chǎn)者需要在發(fā)送下一批消息之前等待更多時間。
十三、水位
通過ack=all約定了leader節(jié)點在消息沒有同步到所有的ISR列表前不會有任何返回，另外，節(jié)點會跟蹤所有同步副本具有的最大偏移量，也就是高水位偏移量HW(highwatermarkoffset)，consumer無法消費分區(qū)下leader副本中偏移量大于分區(qū)HW的任何消息。當(dāng)某個副本成為leader副本時、broker出現(xiàn)崩潰導(dǎo)致副本被踢出ISR時、producer向leader寫入消息后、leader處理followerfetch請求時，都會嘗試更新分區(qū)HW，從而保證了數(shù)據(jù)一致性和正常消費時不會出現(xiàn)讀取到舊值。
十四、腦裂
想象一下，當(dāng)正常存活的controller控制器由于長時間GC-STW導(dǎo)致不可用，然后Zookeeper會認(rèn)為/controller節(jié)點(節(jié)點3)已經(jīng)過期隨即刪除并發(fā)送通知到其他broker節(jié)點，其他每個broker節(jié)點都嘗試升級為控制器節(jié)點，假設(shè)節(jié)點2從競爭中勝出成功新的控制器節(jié)點并在ZK中創(chuàng)建/controller節(jié)點。
然后其他節(jié)點接收到通知，了解到節(jié)點2成為了新的控制器節(jié)點，除了還在GC暫停的節(jié)點3，或者通知壓根沒到達(dá)的節(jié)點3，也就是說節(jié)點3不知道leadership已經(jīng)發(fā)生了變化，它還以為自己是控制器節(jié)點。此時，同時存在兩個控制器，并行發(fā)出可能存在沖突的命令，導(dǎo)致嚴(yán)重的后果。
幸運的是，Kafka提供了epochnumber的方式可以輕松區(qū)分出真實的控制器，它是自增長的序列號，信息存儲在ZooKeeper中，顯然序列號最大的那個節(jié)點才是真實的。
以上就是關(guān)于千鋒扣丁學(xué)堂大數(shù)據(jù)培訓(xùn)之帶你解讀Apache Kafka的全部內(nèi)容，
想要了解更多關(guān)于大數(shù)據(jù)開發(fā)方面內(nèi)容的小伙伴，請關(guān)注扣丁學(xué)堂大數(shù)據(jù)培訓(xùn)官網(wǎng)、微信等平臺，扣丁學(xué)堂IT職業(yè)在線學(xué)習(xí)教育有專業(yè)的大數(shù)據(jù)講師為您指導(dǎo)，此外扣丁學(xué)堂老師精心推出的大數(shù)據(jù)視頻教程定能讓你快速掌握大數(shù)據(jù)從入門到精通開發(fā)實戰(zhàn)技能?？鄱W(xué)堂大數(shù)據(jù)學(xué)習(xí)群：209080834。
【關(guān)注微信公眾號獲取更多學(xué)習(xí)資料】 【掃碼進(jìn)入Python全棧開發(fā)免費公開課】
查看更多關(guān)于“大數(shù)據(jù)培訓(xùn)資訊”的相關(guān)文章>
標(biāo)簽:
大數(shù)據(jù)培訓(xùn)
大數(shù)據(jù)視頻教程
大數(shù)據(jù)分析培訓(xùn)
大數(shù)據(jù)學(xué)習(xí)視頻
Hadoop生態(tài)圈
數(shù)據(jù)結(jié)構(gòu)
算法
返回頂部