自拍偷在线精品自拍偷,亚洲欧美中文日韩v在线观看不卡

十五個(gè)點(diǎn),理解Apache Kafka

大數(shù)據(jù) Kafka
Kafka在世界享有盛名,大部分互聯(lián)網(wǎng)公司都在使用它,那么它到底是什么呢?讓我們一步一步地來理解他,隨后深入探討其工作原理。

一、介紹

Kafka在世界享有盛名,大部分互聯(lián)網(wǎng)公司都在使用它,那么它到底是什么呢?

十五個(gè)點(diǎn),理解Apache Kafka

Kafka由LinkedIn公司于2011年推出,自那時(shí)起功能逐步迭代,目前演變成一個(gè)完整的平臺(tái)級(jí)產(chǎn)品,它允許您冗余地存儲(chǔ)巨大的數(shù)據(jù)量,擁有一個(gè)具有巨大吞吐量(數(shù)百萬/秒)的消息總線,并且支持實(shí)時(shí)流任務(wù)處理??偟膩碚f,Kafka是一個(gè)分布式,可水平擴(kuò)展,容錯(cuò)的日志提交系統(tǒng)

這些描述都非常抽象,讓我們一個(gè)接一個(gè)地理解它們的意思,隨后深入探討其工作原理。

二、分布式

分布式系統(tǒng)意味著不同機(jī)器上的服務(wù)實(shí)例一起工作成一個(gè)整體為用戶提供完整的服務(wù),Kafka的分布式體現(xiàn)在存儲(chǔ)、接收信息、發(fā)送信息在不同的節(jié)點(diǎn)上,它帶來的好處是可擴(kuò)展性和容錯(cuò)性。

三、水平可擴(kuò)展

我們先給垂直可擴(kuò)展下一個(gè)定義,比如說,你的傳統(tǒng)數(shù)據(jù)庫(kù)服務(wù)開始變得超負(fù)載,可以通過簡(jiǎn)單地?cái)U(kuò)充該服務(wù)器資源(CPURAMSSD)緩存這個(gè)問題,這就叫垂直擴(kuò)展-單點(diǎn)增加資源,不過有兩大致命的缺點(diǎn):底層硬件資源有限、需要停機(jī)操作。反之,水平擴(kuò)展通過增加更多的機(jī)器部署服務(wù)解決類似問題。

四、容錯(cuò)

分布式系統(tǒng)被設(shè)計(jì)成可容許一定程序的錯(cuò)誤,不像單點(diǎn)部署發(fā)生異常時(shí)整體服務(wù)都將不可用,有五個(gè)節(jié)點(diǎn)的Kafka實(shí)例,即使有2個(gè)節(jié)點(diǎn)宕機(jī)了仍能繼續(xù)工作。

五、commit日志

一個(gè)commit日記類似預(yù)寫式日記(WAL)和事務(wù)日記,它是可追加的有序的持久化數(shù)據(jù),無法進(jìn)行修改或者刪除。 

十五個(gè)點(diǎn),理解Apache Kafka

這種結(jié)構(gòu)是Kafka的核心,它具備排序功能,而排序則可以保證確定性的處理,這兩者都是分布式系統(tǒng)中的重要問題。

Kafka通常會(huì)將消息持久化到磁盤上,它充分利用磁盤的有序讀取特性,讀寫的時(shí)間復(fù)雜度都為O(1),這是相當(dāng)了不起的,另外讀取和寫入操作不會(huì)相互影響,寫入不會(huì)加鎖阻塞讀取操作。

六、如何工作的

生產(chǎn)者發(fā)到消息至Kafka Node節(jié)點(diǎn),存儲(chǔ)在主題Topic中,消費(fèi)者訂閱主題以接收消息,這是一個(gè)生產(chǎn)訂閱模式。為了使一個(gè)節(jié)點(diǎn)Topic的數(shù)據(jù)量不至過大,Kafka引入分區(qū)的概念,從而具備更好的性能和伸縮性。Kafka保證分區(qū)內(nèi)的所有消息都按照到達(dá)順序排序,區(qū)分消息的方式是通過其偏移量offset,你可以將其理解為普通數(shù)組的下標(biāo)索引。 

十五個(gè)點(diǎn),理解Apache Kafka

Kafka中Broker服務(wù)節(jié)點(diǎn)是愚蠢的,消費(fèi)者是聰明的,Kafka不會(huì)記錄消費(fèi)者讀取的操作和刪除消息,相反,數(shù)據(jù)被存儲(chǔ)一段時(shí)間或者達(dá)到一定的大小閾值,消費(fèi)者可以自由調(diào)整偏移量offset以重復(fù)獲取他們想要的消息或者舍棄。

值得注意的是為了避免進(jìn)程兩次讀取相同的消息,Kafka引入了消費(fèi)者組的概念,其中包含一個(gè)或者多個(gè)消息者實(shí)例,約定每個(gè)組只能同時(shí)有一個(gè)實(shí)例消費(fèi)分區(qū)的消息。不過這引來了一個(gè)麻煩,連社區(qū)也無力解決,也就是Kafka中的重平衡Rebalance問題,它本質(zhì)是一種協(xié)議,規(guī)定一個(gè)消費(fèi)者組下的所有消費(fèi)者實(shí)例如何達(dá)成一致,來分配訂閱主題的每個(gè)分區(qū),當(dāng)組成員數(shù)發(fā)生變更、訂閱主題數(shù)發(fā)生變更、訂閱主題的分區(qū)數(shù)發(fā)生變更時(shí)都會(huì)觸發(fā)Rebalance,從而達(dá)到最公平的分配策略,不過他和GC的STW類似,在Rebalance期間,所有的消費(fèi)者實(shí)例都會(huì)停止消費(fèi),然后重新分配連接。我們應(yīng)該盡量避免這種情況的發(fā)生,盡量讓消費(fèi)實(shí)例數(shù)等于分區(qū)數(shù)。 

十五個(gè)點(diǎn),理解Apache Kafka

七、持久化至磁盤

正如前面提及的,Kafk將消息存儲(chǔ)至磁盤而不是內(nèi)存RAM,你或許會(huì)驚訝它是如何做出這種選擇的,背后應(yīng)該有許多優(yōu)化使其可行,沒錯(cuò),事實(shí)上優(yōu)化點(diǎn)包括:

  1. Kafka的通信協(xié)議支持消息合并,減少網(wǎng)絡(luò)流量傳輸,Broker節(jié)點(diǎn)一次持續(xù)存儲(chǔ)大量數(shù)據(jù),消費(fèi)者可以一次獲取大量的消息
  2. 操作系統(tǒng)通過提前讀入(read-ahead)和write-behind緩存技術(shù),使得磁盤上的線性讀寫速度快,現(xiàn)代磁盤速度慢的結(jié)論是基于需要磁盤搜索的場(chǎng)景
  3. 現(xiàn)代操作系統(tǒng)引入頁(yè)面緩存(Page cache)技術(shù),頁(yè)緩沖由多個(gè)磁盤塊構(gòu)造,在linux讀寫文件時(shí),它用于緩存文件的邏輯內(nèi)容,從而加塊對(duì)磁盤映射和數(shù)據(jù)的訪問
  4. Kafka存儲(chǔ)消息使用的是不可變的標(biāo)準(zhǔn)二進(jìn)制格式,可以充分利用零拷貝技術(shù)(zero-copy),將數(shù)據(jù)從頁(yè)緩存直接復(fù)制到socket通道中

八、數(shù)據(jù)分布式和復(fù)制

我們來談?wù)凨afka如何實(shí)現(xiàn)容錯(cuò)以及如何在節(jié)點(diǎn)間分配數(shù)據(jù)。

Kafka將分區(qū)數(shù)據(jù)拷貝復(fù)制到多個(gè)Brokers節(jié)點(diǎn)上,避免某個(gè)Broker死亡導(dǎo)致數(shù)據(jù)不可達(dá)。每時(shí)每刻,一個(gè)Broker節(jié)點(diǎn)”擁有”一個(gè)分區(qū),并且是應(yīng)用程序從該分區(qū)讀取寫入的節(jié)點(diǎn),這稱為分區(qū)leader,它將收到的數(shù)據(jù)復(fù)制到其他N個(gè)Broker節(jié)點(diǎn)上,它們稱為follower,并準(zhǔn)備好在leader節(jié)點(diǎn)死亡時(shí)被選舉為leader。這種模式使得消息不易丟失,你可以根據(jù)消息的重要程序合理調(diào)整replication factor參數(shù),下圖是4個(gè)Broker節(jié)點(diǎn),擁有3個(gè)復(fù)制副本的示例: 

十五個(gè)點(diǎn),理解Apache Kafka

你或許會(huì)有疑問,生產(chǎn)者或者消費(fèi)者是如何正確得知分區(qū)的leader是哪個(gè)節(jié)點(diǎn)的?事實(shí)上,Kafka將這些信息保存到Zookeeper服務(wù)中。

九、Zookeeper服務(wù)

Zookeeper是一個(gè)分布式KV對(duì)目錄存儲(chǔ)系統(tǒng),特點(diǎn)是可靠性高、讀取性能高,但是寫入性能差,常被用于存儲(chǔ)元數(shù)據(jù)和保存集群狀態(tài),包括心跳、配置等等。

Kafka將以下消息保存至Zookeeper中:

  1. 消費(fèi)者組的每個(gè)分區(qū)的偏移量,不過后來Kafka將其保存至內(nèi)部主題__consumer_offsets中
  2. 訪問權(quán)限列表
  3. 生產(chǎn)者和消費(fèi)者速率限定額度
  4. 分區(qū)leader信息和它們的健康狀態(tài) 
十五個(gè)點(diǎn),理解Apache Kafka

十、Controller控制器

一個(gè)分布式系統(tǒng)肯定是可協(xié)調(diào)的,當(dāng)事件發(fā)生時(shí),節(jié)點(diǎn)必須以某種方式做出反應(yīng),控制器負(fù)責(zé)決定集群如何做出反應(yīng)并指示節(jié)點(diǎn)做某事,它是功能不能過于復(fù)雜的Broker節(jié)點(diǎn),最主要的職責(zé)是負(fù)責(zé)節(jié)點(diǎn)下線和重新加入時(shí)重平衡和分配新的分區(qū)leader。

控制器從ZooKeeper Watch事件中可以得知某個(gè)Broker節(jié)點(diǎn)實(shí)例下線(或者節(jié)點(diǎn)過期,一般發(fā)生于Broker長(zhǎng)時(shí)間繁忙導(dǎo)致心跳異常)的情況,然后做出反應(yīng),決定哪些節(jié)點(diǎn)應(yīng)成為受影響分區(qū)的新leader,然后通知每個(gè)相關(guān)的follower通過leaderAndlsr請(qǐng)求開始從新的leader復(fù)制數(shù)據(jù)。 

十五個(gè)點(diǎn),理解Apache Kafka

從上面可以得知,原本作為分區(qū)leader的Broker節(jié)點(diǎn)實(shí)例重啟后,它將不再擔(dān)任任何分區(qū)的leader,消費(fèi)者也不會(huì)從這個(gè)節(jié)點(diǎn)上讀取消息,這導(dǎo)致了資源的浪費(fèi),幸運(yùn)的是,Kafka有一個(gè)被稱為優(yōu)先副本(preferred leader replica)的概念-你可以理解成原先為該分區(qū)leader節(jié)點(diǎn)(通過broker id區(qū)分)的副本,如果該副本可用,Kafka會(huì)將集群恢復(fù)成之前狀態(tài),通過設(shè)置auto.leader.rebalance.enabled=true可以使得這個(gè)過程自動(dòng)觸發(fā),默認(rèn)值為true。

Broker節(jié)點(diǎn)下線通常都是短暫的,這意味著一段時(shí)間后會(huì)恢復(fù),這就是為什么當(dāng)一個(gè)節(jié)點(diǎn)離開集群時(shí),與之關(guān)聯(lián)的元數(shù)據(jù)不會(huì)被刪除,如果它是一個(gè)分區(qū)的跟隨者,系統(tǒng)也不會(huì)為此分區(qū)重新分配新的跟隨者。

但是需要注意的是,恢復(fù)加入的節(jié)點(diǎn)不能立即拿回其上次的leader地位,它還沒有資格。

十一、ISR

副本同步隊(duì)列ISR(in-sync replicas),它是由leader維護(hù)的,follower從leader同步數(shù)據(jù)是有延遲的,任意一個(gè)超過閾值都會(huì)被剔除出ISR列表, 存入OSR(Outof-Sync Replicas)列表中,新加入的follower也會(huì)先存放在OSR中。

一個(gè)follower想被選舉成leader,它必須在ISR隊(duì)列中才有資格,不過,在沒有同步副本存在并且已有l(wèi)eader都下線的邊緣情況下,可以選擇可用性而不是一致性。

ISR列表維護(hù)標(biāo)準(zhǔn)如下:

  1. 它在過去的X秒內(nèi)有完整同步leader消息,通過replica.lag.time.max.ms配置約定
  2. 它在過去的X秒內(nèi)向Zookeeper發(fā)送了一個(gè)心跳,通過zookeeper.session.timeout.ms配置約定

十二、生產(chǎn)者acks設(shè)置

明顯,存在一系列意外事件會(huì)導(dǎo)致leader下線,假如leader節(jié)點(diǎn)接收到生產(chǎn)者的消息,在存儲(chǔ)并且響應(yīng)ack后節(jié)點(diǎn)崩潰了,此時(shí)Kafka會(huì)從ISR列表中選舉一個(gè)新的leader,但是由于生產(chǎn)者ack配置默認(rèn)為1,意思是只考慮leader接收情況不考慮follower同步情況,最終導(dǎo)致部分消息丟失了,所以我們應(yīng)該在生產(chǎn)者端設(shè)置acks=all,要求每條數(shù)據(jù)必須是寫入所有副本之后,才能認(rèn)為是寫成功,另外一層意思是起碼有一個(gè)leader和一個(gè)follower。不過這種設(shè)置影響集群性能,降低了吞吐量,使得生產(chǎn)者需要在發(fā)送下一批消息之前等待更多時(shí)間。

十五個(gè)點(diǎn),理解Apache Kafka

十三、水位

通過ack=all約定了leader節(jié)點(diǎn)在消息沒有同步到所有的ISR列表前不會(huì)有任何返回,另外,節(jié)點(diǎn)會(huì)跟蹤所有同步副本具有的最大偏移量,也就是高水位偏移量HW(high watermark offset),consumer無法消費(fèi)分區(qū)下leader副本中偏移量大于分區(qū)HW的任何消息。當(dāng)某個(gè)副本成為leader副本時(shí)、broker出現(xiàn)崩潰導(dǎo)致副本被踢出ISR時(shí)、producer向leader寫入消息后、leader處理follower fetch請(qǐng)求時(shí),都會(huì)嘗試更新分區(qū)HW,從而保證了數(shù)據(jù)一致性和正常消費(fèi)時(shí)不會(huì)出現(xiàn)讀取到舊值。 

十五個(gè)點(diǎn),理解Apache Kafka

十四、腦裂

想象一下,當(dāng)正常存活的controller控制器由于長(zhǎng)時(shí)間GC-STW導(dǎo)致不可用,然后Zookeeper會(huì)認(rèn)為/controller節(jié)點(diǎn)(節(jié)點(diǎn)3)已經(jīng)過期隨即刪除并發(fā)送通知到其他broker節(jié)點(diǎn),其他每個(gè)broker節(jié)點(diǎn)都嘗試升級(jí)為控制器節(jié)點(diǎn),假設(shè)節(jié)點(diǎn)2從競(jìng)爭(zhēng)中勝出成功新的控制器節(jié)點(diǎn)并在ZK中創(chuàng)建/controller節(jié)點(diǎn)。

然后其他節(jié)點(diǎn)接收到通知,了解到節(jié)點(diǎn)2成為了新的控制器節(jié)點(diǎn),除了還在GC暫停的節(jié)點(diǎn)3,或者通知壓根沒到達(dá)的節(jié)點(diǎn)3,也就是說節(jié)點(diǎn)3不知道leadership已經(jīng)發(fā)生了變化,它還以為自己是控制器節(jié)點(diǎn)。此時(shí),同時(shí)存在兩個(gè)控制器,并行發(fā)出可能存在沖突的命令,導(dǎo)致嚴(yán)重的后果。

幸運(yùn)的是,Kafka提供了epoch number的方式可以輕松區(qū)分出真實(shí)的控制器,它是自增長(zhǎng)的序列號(hào),信息存儲(chǔ)在ZooKeeper中,顯然序列號(hào)最大的那個(gè)節(jié)點(diǎn)才是真實(shí)的。 

十五個(gè)點(diǎn),理解Apache Kafka

十五、什么時(shí)候應(yīng)該使用Kafka

從上面幾點(diǎn)可知,Kafka可以成為事件驅(qū)動(dòng)架構(gòu)的中心部分,使你可以真正將應(yīng)用程序彼此分離。 

十五個(gè)點(diǎn),理解Apache Kafka

 

責(zé)任編輯:未麗燕 來源: 今日頭條
點(diǎn)贊
收藏

51CTO技術(shù)棧公眾號(hào)