Kafka——zookeeper的作用

Stitches發表於2024-04-13
Kafka

Zookeeper

https://blog.csdn.net/m0_46109609/article/details/110139341

1、leader 選舉和 follower 資訊同步

Kafka 中每個 Topic 的分割槽有 N 個副本，其中 N 是 Topic 的複製因子。Kafka 透過多副本機制實現故障轉移，當 Kafka 叢集中一個 Broker 失效情況下仍然保證服務可用，在 Kafka 中發生複製時確保分割槽副本日誌有序地寫到其它 Broker 節點。N 複製分割槽中，其中一個為 Leader，剩下都為 Follower，Leader 處理分割槽的所有讀寫請求，Follower 會被定期地去複製 Leader 上的資料。

img

Kafka 提供了資料複製演算法的保證，如果 Leader 發生當機，新 Leader 會當選並開始接收客戶端訊息進行寫入。Follower 實現追趕 leader 資料，Leader 負責維護和跟蹤 ISR 中所有 Follower 的滯後狀態。當生產者傳送一條訊息到 Broker 時，Leader 寫入訊息並複製到所有 Follower，訊息提交之後才被成功複製到所有同步的副本。

2、Broker 註冊

Broker是分散式部署並且相互之間相互獨立，但是需要有一個註冊系統能夠將整個叢集中的Broker管理起來，此時就使用到了Zookeeper。在Zookeeper上會有一個專門用來進行Broker伺服器列表記錄的節點：/brokers/ids。

每個 Broker 在啟動時，都會到 Zookeeper 上進行註冊，即到 /brokers/ids 下建立屬於自己的節點，例如 /brokers/ids/[0...N]。

Kafka 透過全域性唯一的數字來指代每個 Broker 節點，建立完節點後節點的 IP、Port 會記錄到節點資訊中去，Broker 節點為臨時節點，一旦 Broker 當機資訊就會丟失。

3、Topic 註冊

在Kafka中，同一個Topic的訊息會被分成多個分割槽並將其分佈在多個Broker上，這些分割槽資訊及與Broker的對應關係也都是由Zookeeper在維護，由專門的節點來記錄，如：/brokers/topics。

Kafka 中每個 Topic 都會以 /brokers/topics/[topic] 形式記錄和 Broker 的關係，例如 /brokers/topics/login、/brokers/topics/search 等。Broker 啟動後會到對應 Topic 節點下注冊自己的 BrokerID 並寫入針對該 Topic 的分割槽總數，例如 /brokers/topics/login/3->2，它表示 BrokerID=3 的伺服器，對於 login 這個主題訊息提供了 2 個分割槽進行訊息儲存。這個節點也是臨時節點。

4、生產者負載均衡

傳統四層負載均衡、七層負載均衡：https://zhuanlan.zhihu.com/p/64777456

同一個 Topic 的訊息分割槽分佈在多個 Broker 上，因此生產者需要將訊息合理地分佈到這些 Broker 上，如何實現生產者的負載均衡，Kafka 支援傳統的四層負載均衡，也支援 Zookeeper 方式的負載均衡。

  • 傳統四層負載均衡：根據生產者的 IP、Port 為其關聯一個 Broker，由該生產者生產的訊息都會傳送到 Broker。每個生產者不需要同其它系統建立額外的 TCP 連線。但是無法實現真正的負載，因為實際每個生產者生產的訊息量及每個 Broker 儲存的訊息量都是不一致的，生產者間訊息量的不同導致負載差異。
  • Zookeeper 負載均衡：每個 Broker 節點啟動時會到對應 Topic 節點下注冊自己的 BrokerID->PartitionNums 記錄，生產者可以透過該節點的變化感知 Broker 伺服器列表的變更，實現動態的負載均衡。

5、消費者負載均衡

與生產者類似，Kafka中的消費者同樣需要進行負載均衡來實現多個消費者合理地從對應的Broker伺服器上接收訊息，每個消費者分組包含若干消費者，每條訊息都只會傳送給分組中的一個消費者，不同的消費者分組消費自己特定的Topic下面的訊息，互不干擾。

6、分割槽和消費者的關係

Kafka 會為每個消費者組分配一個全域性唯一 Group ID，組內部的所有消費者共享該ID。消費者組訂閱的主題下的每個分割槽只能分配給消費者組下某一個特定的消費者（該分割槽還可以分配給其他 Group）。同時，Kafka為每個消費者分配一個Consumer ID，通常採用"Hostname:UUID"形式表示。

Kafka 規定了每個消費分割槽只能被同消費者組的一個消費者消費，因此需要在 ZK 上記錄消費分割槽與消費者之間的關係，將 ConsumerID 寫入到 ZK 對應訊息分割槽的臨時節點上，例如：/consumers/[group_id]/owners/[topic]/[broker_id——partition_id]，其中 [broker_id——partition_id] 是訊息分割槽的標識，節點內容就是消費者的 ConsumerID。

7、訊息消費進度 Offset

在消費者對指定訊息分割槽進行訊息消費的過程中，需要定時地將分割槽訊息的消費進度Offset記錄到Zookeeper上，以便在該消費者進行重啟或者其他消費者重新接管該訊息分割槽的訊息消費後，能夠從之前的進度開始繼續進行訊息消費。Offset在Zookeeper中由一個專門節點進行記錄，其節點路徑為：/consumers/[group_id]/offsets/[topic]/[broker_id-partition_id]，節點內容就是 Offset。

8、消費者註冊

消費者初始化啟動時加入消費者組步驟如下：

  • 每個消費者啟動時都會到 ZK 節點下建立一個屬於自己的消費者節點，例如 /consumers/[group_id]/ids/[consumer_id]，完成節點建立後，消費者會將自己訂閱的 Topic 資訊寫入該臨時節點。
  • 對消費者分組中的消費者的變化註冊監聽。每個消費者都需要關注所屬消費者分組中其他消費者伺服器的變化情況，即對 /consumers/[group_id]/ids 節點註冊子節點變化的Watcher監聽，一旦發現消費者新增或減少，就觸發消費者的負載均衡。
  • 對Broker伺服器變化註冊監聽。消費者需要對 /broker/ids/[0-N] 中的節點進行監聽，如果發現Broker伺服器列表發生變化，那麼就根據具體情況來決定是否需要進行消費者負載均衡。

img

相關文章