這篇文章主要介紹“Kafka-4.Kafka工作流程及文件存儲機(jī)制的原理是什么”，在日常操作中，相信很多人在Kafka-4.Kafka工作流程及文件存儲機(jī)制的原理是什么問題上存在疑惑，小編查閱了各式資料，整理出簡單好用的操作方法，希望對大家解答”Kafka-4.Kafka工作流程及文件存儲機(jī)制的原理是什么”的疑惑有所幫助！接下來，請跟著小編一起來學(xué)習(xí)吧！

成都做網(wǎng)站、網(wǎng)站設(shè)計(jì)服務(wù)團(tuán)隊(duì)是一支充滿著熱情的團(tuán)隊(duì)，執(zhí)著、敏銳、追求更好，是創(chuàng)新互聯(lián)的標(biāo)準(zhǔn)與要求，同時(shí)竭誠為客戶提供服務(wù)是我們的理念。成都創(chuàng)新互聯(lián)把每個(gè)網(wǎng)站當(dāng)做一個(gè)產(chǎn)品來開發(fā)，精雕細(xì)琢，追求一名工匠心中的細(xì)致，我們更用心！

文件存儲機(jī)制

工作流程

    Kafka 中消息是以 topic 進(jìn)行分類的， 生產(chǎn)者生產(chǎn)消息，消費(fèi)者消費(fèi)消息，都是面向 topic的。 topic 是邏輯上的概念，而 partition 是物理上的概念，每個(gè) partition 對應(yīng)于一個(gè) log 文件，該 log 文件中存儲的就是 producer 生產(chǎn)的數(shù)據(jù)。 Producer 生產(chǎn)的數(shù)據(jù)會被不斷追加到該log 文件末端，且每條數(shù)據(jù)都有自己的 offset。 消費(fèi)者組中的每個(gè)消費(fèi)者， 都會實(shí)時(shí)記錄自己消費(fèi)到了哪個(gè) offset，以便出錯(cuò)恢復(fù)時(shí)，從上次的位置繼續(xù)消費(fèi)。

Kafka文件存儲機(jī)制

    由于生產(chǎn)者生產(chǎn)的消息會不斷追加到 log 文件末尾， 為防止 log 文件過大導(dǎo)致數(shù)據(jù)定位效率低下， Kafka 采取了分片和索引機(jī)制，將每個(gè) partition 分為多個(gè) segment。 每個(gè) segment對應(yīng)兩個(gè)文件——“.index”文件和“.log”文件。 這些文件位于一個(gè)文件夾下， 該文件夾的命名規(guī)則為： topic 名稱+分區(qū)序號。例如， first 這個(gè) topic 有三個(gè)分區(qū)，則其對應(yīng)的文件夾為 first-0,first-1,first-2

00000000000000000000.index
00000000000000000000.log
00000000000000170410.index
00000000000000170410.log
00000000000000239430.index
00000000000000239430.log

index 和 log 文件以當(dāng)前 segment 的第一條消息的 offset 命名。下圖為 index 文件和 log文件的結(jié)構(gòu)示意圖

 “.index”文件存儲大量的索引信息，“.log”文件存儲大量的數(shù)據(jù)，索引文件中的元數(shù)據(jù)指向?qū)?yīng)數(shù)據(jù)文件中 message 的物理偏移地址。

Kafka 生產(chǎn)者

分區(qū)策略

1.    分區(qū)的原因

• 方便在集群中擴(kuò)展，每個(gè) Partition 可以通過調(diào)整以適應(yīng)它所在的機(jī)器，而一個(gè) topic又可以有多個(gè) Partition 組成，因此整個(gè)集群就可以適應(yīng)任意大小的數(shù)據(jù)了；

• 可以提高并發(fā)，因?yàn)榭梢砸?Partition 為單位讀寫了。

2.     分區(qū)的原則
我們需要將 producer 發(fā)送的數(shù)據(jù)封裝成一個(gè) ProducerRecord 對象。

1. 副本數(shù)據(jù)同步策略
   

   

   LEO：指的是每個(gè)副本最大的 offset；

   HW：指的是消費(fèi)者能見到的最大的 offset， ISR 隊(duì)列中最小的 LEO。

   （1）follower 故障follower 發(fā)生故障后會被臨時(shí)踢出 ISR，待該 follower 恢復(fù)后， follower 會讀取本地磁盤記錄的上次的 HW，并將 log 文件高于 HW 的部分截取掉，從 HW 開始向 leader 進(jìn)行同步。等該 follower 的 LEO 大于等于該 Partition 的 HW，即 follower 追上 leader 之后，就可以重新加入 ISR 了。

   （2）leader故障leader 發(fā)生故障之后，會從 ISR 中選出一個(gè)新的 leader，之后，為保證多個(gè)副本之間的數(shù)據(jù)一致性， 其余的 follower 會先將各自的 log 文件高于 HW 的部分截掉，然后從新的 leader 同步數(shù)據(jù)。

       注意： 這只能保證副本之間的數(shù)據(jù)一致性，并不能保證數(shù)據(jù)不丟失或者不重復(fù)。

   Exactly Once 語義

   將服務(wù)器的 ACK 級別設(shè)置為-1，可以保證 Producer 到 Server 之間不會丟失數(shù)據(jù)，即 AtLeast Once 語義。相對的，將服務(wù)器 ACK 級別設(shè)置為 0，可以保證生產(chǎn)者每條消息只會被發(fā)送一次，即 At Most Once 語義。
           At Least Once 可以保證數(shù)據(jù)不丟失，但是不能保證數(shù)據(jù)不重復(fù)；相對的， At Least Once可以保證數(shù)據(jù)不重復(fù)，但是不能保證數(shù)據(jù)不丟失。 但是，對于一些非常重要的信息，比如說交易數(shù)據(jù)，下游數(shù)據(jù)消費(fèi)者要求數(shù)據(jù)既不重復(fù)也不丟失，即 Exactly Once 語義。 在 0.11 版本以前的 Kafka，對此是無能為力的，只能保證數(shù)據(jù)不丟失，再在下游消費(fèi)者對數(shù)據(jù)做全局去重。對于多個(gè)下游應(yīng)用的情況，每個(gè)都需要單獨(dú)做全局去重，這就對性能造成了很大影響。
           0.11 版本的 Kafka，引入了一項(xiàng)重大特性：冪等性。所謂的冪等性就是指 Producer 不論向 Server 發(fā)送多少次重復(fù)數(shù)據(jù)， Server 端都只會持久化一條。冪等性結(jié)合 At Least Once 語義，就構(gòu)成了 Kafka 的 Exactly Once 語義。即：

   
           At Least Once + 冪等性 = Exactly Once

           要啟用冪等性，只需要將 Producer 的參數(shù)中 enable.idompotence 設(shè)置為 true 即可。 Kafka的冪等性實(shí)現(xiàn)其實(shí)就是將原來下游需要做的去重放在了數(shù)據(jù)上游。開啟冪等性的 Producer 在初始化的時(shí)候會被分配一個(gè) PID，發(fā)往同一 Partition 的消息會附帶 Sequence Number。而Broker 端會對<PID, Partition, SeqNumber>做緩存，當(dāng)具有相同主鍵的消息提交時(shí)， Broker 只會持久化一條。

           但是 PID 重啟就會變化，同時(shí)不同的 Partition 也具有不同主鍵，所以冪等性無法保證跨分區(qū)跨會話的 Exactly Once。

   Kafka 高效讀寫數(shù)據(jù)

   1）順序?qū)懘疟P

        Kafka 的 producer 生產(chǎn)數(shù)據(jù)，要寫入到 log 文件中，寫的過程是一直追加到文件末端，為順序?qū)憽?官網(wǎng)有數(shù)據(jù)表明，同樣的磁盤，順序?qū)懩艿?600M/s，而隨機(jī)寫只有 100K/s。這與磁盤的機(jī)械機(jī)構(gòu)有關(guān)，順序?qū)懼钥欤且驗(yàn)槠涫∪チ舜罅看蓬^尋址的時(shí)間。

   2）零復(fù)制技術(shù)

   Zookeeper 在 Kafka 中的作用

       Kafka 集群中有一個(gè) broker 會被選舉為 Controller，負(fù)責(zé)管理集群 broker 的上下線，所有 topic 的分區(qū)副本分配和 leader 選舉等工作。

       Controller 的管理工作都是依賴于 Zookeeper 的。

       以下為 partition 的 leader 選舉過程：

   

   
   Kafka 事務(wù)

   Kafka 從 0.11 版本開始引入了事務(wù)支持。事務(wù)可以保證 Kafka 在 Exactly Once 語義的基礎(chǔ)上，生產(chǎn)和消費(fèi)可以跨分區(qū)和會話，要么全部成功，要么全部失敗。

   Producer 事務(wù)

   為了實(shí)現(xiàn)跨分區(qū)跨會話的事務(wù)，需要引入一個(gè)全局唯一的 Transaction ID，并將 Producer獲得的PID 和Transaction ID 綁定。這樣當(dāng)Producer 重啟后就可以通過正在進(jìn)行的 TransactionID 獲得原來的 PID。為了管理 Transaction， Kafka 引入了一個(gè)新的組件 Transaction Coordinator。 Producer 就是通過和 Transaction Coordinator 交互獲得 Transaction ID 對應(yīng)的任務(wù)狀態(tài)。 Transaction Coordinator 還負(fù)責(zé)將事務(wù)所有寫入 Kafka 的一個(gè)內(nèi)部 Topic，這樣即使整個(gè)服務(wù)重啟，由于事務(wù)狀態(tài)得到保存，進(jìn)行中的事務(wù)狀態(tài)可以得到恢復(fù)，從而繼續(xù)進(jìn)行。

   Consumer 事務(wù) 

   上述事務(wù)機(jī)制主要是從 Producer 方面考慮，對于 Consumer 而言，事務(wù)的保證就會相對較弱，尤其時(shí)無法保證 Commit 的信息被精確消費(fèi)。這是由于 Consumer 可以通過 offset 訪問任意信息，而且不同的 Segment File 生命周期不同，同一事務(wù)的消息可能會出現(xiàn)重啟后被刪除的情況。

   到此，關(guān)于“Kafka-4.Kafka工作流程及文件存儲機(jī)制的原理是什么”的學(xué)習(xí)就結(jié)束了，希望能夠解決大家的疑惑。理論與實(shí)踐的搭配能更好的幫助大家學(xué)習(xí)，快去試試吧！若想繼續(xù)學(xué)習(xí)更多相關(guān)知識，請繼續(xù)關(guān)注創(chuàng)新互聯(lián)網(wǎng)站，小編會繼續(xù)努力為大家?guī)砀鄬?shí)用的文章！

   分享文章：Kafka-4.Kafka工作流程及文件存儲機(jī)制的原理是什么
   分享地址：http://www.rwnh.cn/article32/jdcesc.html

   成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供網(wǎng)站收錄、面包屑導(dǎo)航、云服務(wù)器、網(wǎng)站制作、響應(yīng)式網(wǎng)站、自適應(yīng)網(wǎng)站

   廣告

   聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來源： 創(chuàng)新互聯(lián)