如何理解Kafka的副本機制

這篇文章主要講解了“如何理解Kafka的副本機制”，文中的講解內容簡單清晰，易于學習與理解，下面請大家跟著小編的思路慢慢深入，一起來研究和學習“如何理解Kafka的副本機制”吧！

一、Kafka集群

Kafka 使用 Zookeeper 來維護集群成員 (brokers) 的信息。每個 broker 都有一個唯一標識  broker.id，用于標識自己在集群中的身份，可以在配置文件 server.properties 中進行配置，或者由程序自動生成。下面是 Kafka  brokers 集群自動創建的過程：

• 每一個 broker 啟動的時候，它會在 Zookeeper 的 /brokers/ids 路徑下創建一個 臨時節點，并將自己的 broker.id  寫入，從而將自身注冊到集群;

• 當有多個 broker 時，所有 broker 會競爭性地在 Zookeeper 上創建 /controller 節點，由于 Zookeeper  上的節點不會重復，所以必然只會有一個 broker 創建成功，此時該 broker 稱為 controller broker。它除了具備其他 broker  的功能外，還負責管理主題分區及其副本的狀態。

• 當 broker 出現宕機或者主動退出從而導致其持有的 Zookeeper 會話超時時，會觸發注冊在 Zookeeper 上的 watcher 事件，此時  Kafka 會進行相應的容錯處理;如果宕機的是 controller broker 時，還會觸發新的 controller 選舉。

二、副本機制

為了保證高可用，kafka 的分區是多副本的，如果一個副本丟失了，那么還可以從其他副本中獲取分區數據。但是這要求對應副本的數據必須是完整的，這是  Kafka 數據一致性的基礎，所以才需要使用 controller broker 來進行專門的管理。下面將詳解介紹 Kafka 的副本機制。

2.1 分區和副本

Kafka 的主題被分為多個分區 ，分區是 Kafka 最基本的存儲單位。每個分區可以有多個副本 (可以在創建主題時使用  replication-factor 參數進行指定)。其中一個副本是首領副本 (Leader  replica)，所有的事件都直接發送給首領副本;其他副本是跟隨者副本 (Follower  replica)，需要通過復制來保持與首領副本數據一致，當首領副本不可用時，其中一個跟隨者副本將成為新首領。

2.2 ISR機制

每個分區都有一個 ISR(in-sync Replica)  列表，用于維護所有同步的、可用的副本。首領副本必然是同步副本，而對于跟隨者副本來說，它需要滿足以下條件才能被認為是同步副本：

• 與 Zookeeper 之間有一個活躍的會話，即必須定時向 Zookeeper 發送心跳;

• 在規定的時間內從首領副本那里低延遲地獲取過消息。

如果副本不滿足上面條件的話，就會被從 ISR 列表中移除，直到滿足條件才會被再次加入。

這里給出一個主題創建的示例：使用 --replication-factor 指定副本系數為 3，創建成功后使用 --describe 命令可以看到分區 0  的有 0,1,2 三個副本，且三個副本都在 ISR 列表中，其中 1 為首領副本。

2.3 不完全的首領選舉

對于副本機制，在 broker 級別有一個可選的配置參數 unclean.leader.election.enable，默認值為  fasle，代表禁止不完全的首領選舉。這是針對當首領副本掛掉且 ISR  中沒有其他可用副本時，是否允許某個不完全同步的副本成為首領副本，這可能會導致數據丟失或者數據不一致，在某些對數據一致性要求較高的場景  (如金融領域)，這可能無法容忍的，所以其默認值為 false，如果你能夠允許部分數據不一致的話，可以配置為 true。

2.4 最少同步副本

ISR 機制的另外一個相關參數是 min.insync.replicas , 可以在 broker 或者主題級別進行配置，代表 ISR  列表中至少要有幾個可用副本。這里假設設置為 2，那么當可用副本數量小于該值時，就認為整個分區處于不可用狀態。此時客戶端再向分區寫入數據時候就會拋出異常  org.apache.kafka.common.errors.NotEnoughReplicasExceptoin: Messages are rejected  since there are fewer in-sync replicas than required。

2.5 發送確認

Kafka 在生產者上有一個可選的參數 ack，該參數指定了必須要有多少個分區副本收到消息，生產者才會認為消息寫入成功：

• acks=0 ：消息發送出去就認為已經成功了，不會等待任何來自服務器的響應;

• acks=1 ：只要集群的首領節點收到消息，生產者就會收到一個來自服務器成功響應;

• acks=all ：只有當所有參與復制的節點全部收到消息時，生產者才會收到一個來自服務器的成功響應。

三、數據請求

3.1 元數據請求機制

在所有副本中，只有領導副本才能進行消息的讀寫處理。由于不同分區的領導副本可能在不同的 broker 上，如果某個 broker  收到了一個分區請求，但是該分區的領導副本并不在該 broker 上，那么它就會向客戶端返回一個 Not a Leader for Partition  的錯誤響應。為了解決這個問題，Kafka 提供了元數據請求機制。

首先集群中的每個 broker  都會緩存所有主題的分區副本信息，客戶端會定期發送發送元數據請求，然后將獲取的元數據進行緩存。定時刷新元數據的時間間隔可以通過為客戶端配置  metadata.max.age.ms 來進行指定。有了元數據信息后，客戶端就知道了領導副本所在的 broker，之后直接將讀寫請求發送給對應的 broker  即可。

如果在定時請求的時間間隔內發生的分區副本的選舉，則意味著原來緩存的信息可能已經過時了，此時還有可能會收到 Not a Leader for  Partition 的錯誤響應，這種情況下客戶端會再次求發出元數據請求，然后刷新本地緩存，之后再去正確的 broker  上執行對應的操作，過程如下圖：

3.2 數據可見性

需要注意的是，并不是所有保存在分區首領上的數據都可以被客戶端讀取到，為了保證數據一致性，只有被所有同步副本 (ISR 中所有副本)  都保存了的數據才能被客戶端讀取到。

3.3 零拷貝

Kafka 所有數據的寫入和讀取都是通過零拷貝來實現的。傳統拷貝與零拷貝的區別如下：

傳統模式下的四次拷貝與四次上下文切換

以將磁盤文件通過網絡發送為例。傳統模式下，一般使用如下偽代碼所示的方法先將文件數據讀入內存，然后通過 Socket 將內存中的數據發送出去。

buffer = File.read Socket.send(buffer)

這一過程實際上發生了四次數據拷貝。首先通過系統調用將文件數據讀入到內核態 Buffer(DMA 拷貝)，然后應用程序將內存態 Buffer  數據讀入到用戶態 Buffer(CPU 拷貝)，接著用戶程序通過 Socket 發送數據時將用戶態 Buffer 數據拷貝到內核態 Buffer(CPU  拷貝)，最后通過 DMA 拷貝將數據拷貝到 NIC Buffer。同時，還伴隨著四次上下文切換，如下圖所示：

sendfile和transferTo實現零拷貝

Linux 2.4+ 內核通過 sendfile 系統調用，提供了零拷貝。數據通過 DMA 拷貝到內核態 Buffer 后，直接通過 DMA 拷貝到  NIC Buffer，無需 CPU 拷貝。這也是零拷貝這一說法的來源。除了減少數據拷貝外，因為整個讀文件到網絡發送由一個 sendfile  調用完成，整個過程只有兩次上下文切換，因此大大提高了性能。零拷貝過程如下圖所示：圖片 從具體實現來看，Kafka 的數據傳輸通過 TransportLayer  來完成，其子類 PlaintextTransportLayer 的 transferFrom 方法通過調用 Java NIO 中 FileChannel 的  transferTo 方法實現零拷貝，如下所示：

@Override public long transferFrom(FileChannel fileChannel, long position, long count) throws IOException {     return fileChannel.transferTo(position, count, socketChannel); }

注： transferTo 和 transferFrom 并不保證一定能使用零拷貝。實際上是否能使用零拷貝與操作系統相關，如果操作系統提供  sendfile 這樣的零拷貝系統調用，則這兩個方法會通過這樣的系統調用充分利用零拷貝的優勢，否則并不能通過這兩個方法本身實現零拷貝。

四、物理存儲

4.1 分區分配

在創建主題時，Kafka 會首先決定如何在 broker 間分配分區副本，它遵循以下原則：

• 在所有 broker 上均勻地分配分區副本;

• 確保分區的每個副本分布在不同的 broker 上;

• 如果使用了 broker.rack 參數為 broker 指定了機架信息，那么會盡可能的把每個分區的副本分配到不同機架的 broker  上，以避免一個機架不可用而導致整個分區不可用。

基于以上原因，如果你在一個單節點上創建一個 3 副本的主題，通常會拋出下面的異常：

Error while executing topic command : org.apache.kafka.common.errors.InvalidReplicationFactor    Exception: Replication factor: 3 larger than available brokers: 1.

4.2 分區數據保留規則

保留數據是 Kafka 的一個基本特性， 但是 Kafka 不會一直保留數據，也不會等到所有消費者都讀取了消息之后才刪除消息。相反， Kafka  為每個主題配置了數據保留期限，規定數據被刪除之前可以保留多長時間，或者清理數據之前可以保留的數據量大小。分別對應以下四個參數：

• log.retention.bytes ：刪除數據前允許的最大數據量;默認值-1，代表沒有限制;

• log.retention.ms：保存數據文件的毫秒數，如果未設置，則使用 log.retention.minutes 中的值，默認為 null;

• log.retention.minutes：保留數據文件的分鐘數，如果未設置，則使用 log.retention.hours 中的值，默認為  null;

• log.retention.hours：保留數據文件的小時數，默認值為 168，也就是一周。

因為在一個大文件里查找和刪除消息是很費時的，也很容易出錯，所以 Kafka  把分區分成若干個片段，當前正在寫入數據的片段叫作活躍片段。活動片段永遠不會被刪除。如果按照默認值保留數據一周，而且每天使用一個新片段，那么你就會看到，在每天使用一個新片段的同時會刪除一個最老的片段，所以大部分時間該分區會有  7 個片段存在。

4.3 文件格式

通常保存在磁盤上的數據格式與生產者發送過來消息格式是一樣的。如果生產者發送的是壓縮過的消息，那么同一個批次的消息會被壓縮在一起，被當作“包裝消息”進行發送  (格式如下所示) ，然后保存到磁盤上。之后消費者讀取后再自己解壓這個包裝消息，獲取每條消息的具體信息。

感謝各位的閱讀，以上就是“如何理解Kafka的副本機制”的內容了，經過本文的學習后，相信大家對如何理解Kafka的副本機制這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是億速云，小編將為大家推送更多相關知識點的文章，歡迎關注！