Kafka-4.Kafka工作流程及文件存儲機制的原理是什么

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

文件存儲機制

工作流程

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

Kafka文件存儲機制

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

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

index 和 log 文件以當前 segment 的第一條消息的 offset 命名。下圖為 index 文件和 log文件的結構示意圖

 “.index”文件存儲大量的索引信息，“.log”文件存儲大量的數據，索引文件中的元數據指向對應數據文件中 message 的物理偏移地址。

Kafka 生產者

分區策略

1.    分區的原因

• 方便在集群中擴展，每個 Partition 可以通過調整以適應它所在的機器，而一個 topic又可以有多個 Partition 組成，因此整個集群就可以適應任意大小的數據了；

• 可以提高并發，因為可以以 Partition 為單位讀寫了。

2.     分區的原則
我們需要將 producer 發送的數據封裝成一個 ProducerRecord 對象。

1. 副本數據同步策略
   

   

   LEO：指的是每個副本最大的 offset；

   HW：指的是消費者能見到的最大的 offset， ISR 隊列中最小的 LEO。

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

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

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

   Exactly Once 語義

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

   
           At Least Once + 冪等性 = Exactly Once

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

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

   Kafka 高效讀寫數據

   1）順序寫磁盤

        Kafka 的 producer 生產數據，要寫入到 log 文件中，寫的過程是一直追加到文件末端，為順序寫。 官網有數據表明，同樣的磁盤，順序寫能到 600M/s，而隨機寫只有 100K/s。這與磁盤的機械機構有關，順序寫之所以快，是因為其省去了大量磁頭尋址的時間。

   2）零復制技術

   Zookeeper 在 Kafka 中的作用

       Kafka 集群中有一個 broker 會被選舉為 Controller，負責管理集群 broker 的上下線，所有 topic 的分區副本分配和 leader 選舉等工作。

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

       以下為 partition 的 leader 選舉過程：

   

   
   Kafka 事務

   Kafka 從 0.11 版本開始引入了事務支持。事務可以保證 Kafka 在 Exactly Once 語義的基礎上，生產和消費可以跨分區和會話，要么全部成功，要么全部失敗。

   Producer 事務

   為了實現跨分區跨會話的事務，需要引入一個全局唯一的 Transaction ID，并將 Producer獲得的PID 和Transaction ID 綁定。這樣當Producer 重啟后就可以通過正在進行的 TransactionID 獲得原來的 PID。為了管理 Transaction， Kafka 引入了一個新的組件 Transaction Coordinator。 Producer 就是通過和 Transaction Coordinator 交互獲得 Transaction ID 對應的任務狀態。 Transaction Coordinator 還負責將事務所有寫入 Kafka 的一個內部 Topic，這樣即使整個服務重啟，由于事務狀態得到保存，進行中的事務狀態可以得到恢復，從而繼續進行。

   Consumer 事務 

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

   到此，關于“Kafka-4.Kafka工作流程及文件存儲機制的原理是什么”的學習就結束了，希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學習，快去試試吧！若想繼續學習更多相關知識，請繼續關注億速云網站，小編會繼續努力為大家帶來更多實用的文章！