Kafka集群突破百萬中partition的技術分析

本篇內容介紹了“Kafka集群突破百萬中partition的技術分析”的有關知識，在實際案例的操作過程中，不少人都會遇到這樣的困境，接下來就讓小編帶領大家學習一下如何處理這些情況吧！希望大家仔細閱讀，能夠學有所成！

Kafka 的 topic 在 broker 上是以 partition 為最小單位存放和進行復制的, 因此集群需要維護每個 partition 的 Leader 信息，單個 partition 的多個副本都存放在哪些 broker 節點上，處于復制同步狀態的副本都有哪些。為了存放這些元數據，kafka 集群會為每一個 partition 在 zk 集群上創建一個節點，partition 的數量直接決定了 zk 上的節點數。

假設集群上有 1 萬個 topic，每個 topic 包含 100 個 partition，則 ZK 上節點數約為 200 多萬個，快照大小約為 300MB，ZK 節點數據變更，會把數據會寫在事務日志中進行持久化存儲，當事務日志達到一定的條目會全量寫入數據到持久化快照文件中，partition 節點數擴大意味著快照文件也大，全量寫入快照與事務日志的寫入會相互影響，從而影響客戶端的響應速度，同時 zk 節點重啟加載快照的時間也會變長。

2. Partition 復制

Kafka 的 partition 復制由獨立的復制線程負責，多個 partition 會共用復制線程，當單個 broker 上的 partition 增大以后，單個復制線程負責的 partition 數也會增多，每個 partition 對應一個日志文件，當大量的 partition 同時有寫入時，磁盤上文件的寫入也會更分散，寫入性能變差，可能出現復制跟不上，導致 ISR 頻繁波動，調整復制線程的數量可以減少單個線程負責的 partition 數量，但是也加劇了磁盤的爭用。

3. Controller 切換時長

由于網絡或者機器故障等原因，運行中的集群可能存在 controller 切換的情況，當 controller 切換時需要從 ZK 中恢復 broker 節點信息、topic 的 partition 復制關系、partition 當前 leader 在哪個節點上等，然后會把 partition 完整的信息同步給每一個 broker 節點。

在虛擬機上測試，100 萬 partition 的元數據從 ZK 恢復到 broker 上約需要 37s 的時間，100 萬 partition 生成的元數據序列化后大約 80MB（數據大小與副本數、topic 名字長度等相關），其他 broker 接收到元數據后，進行反序列化并更新到本機 broker 內存中，應答響應時間約需要 40s（測試時長與網絡環境有關）。

Controller 控制了 leader 切換與元數據的下發給集群中其他 broker 節點，controller 的恢復時間變長增加了集群不可用風險，當 controller 切換時如果存在 partition 的 Leader 需要切換，就可能存在客戶端比較長的時間內拿不到新的 leader，導致服務中斷。

4. broker 上下線恢復時長

日常維護中可能需要對 broker 進行重啟操作，為了不影響用戶使用，broker 在停止前會通知 controller 進行 Leader 切換，同樣 broker 故障時也會進行 leader 切換，leader 切換信息需要更新 ZK 上的 partition 狀態節點數據，并同步給其他的 broker 進行 metadata 信息更新。當 partition 數量變多，意味著單個 broker 節點上的 partitiion Leader 切換時間變長。

通過上述幾個影響因素，我們知道當 partition 數量增加時會直接影響到 controller 故障恢復時間；單個 broker 上 partition 數量增多會影響磁盤性能，復制的穩定性；broker 重啟 Leader 切換時間增加等。當然我們完全可以在現有的架構下限制每個 broker 上的 partition 數量，來規避單 broker 上受 partition 數量的影響，但是這樣意味著集群內 broker 節點數會增加，controller 負責的 broker 節點數增加，同時 controller 需要管理的 partition 數并不會減少，如果我們想解決大量 partition 共用一個集群的場景，那么核心需要解決的問題就是要么提升單個 controller 的處理性能能力，要么增加 controller 的數量。

1. 單 ZK 集群

從提升單個 controller 處理性能方面可以進行下面的優化：

• 并行拉取 zk 節點

Controller 在拉取 zk 上的元數據時，雖然采用了異步等待數據響應的方式，請求和應答非串行等待，但是單線程處理消耗了大約 37s，我們可以通過多線程并行拉取元數據，每個線程負責一部分 partition，從而縮減拉取元數據的時間。

在虛擬機上簡單模擬獲取 100 萬個節點數據，單線程約花費 28s，分散到 5 個線程上并行處理，每個線程負責 20 萬 partition 數據的拉取，總時間縮短為 14s 左右（這個時間受虛擬機本身性能影響，同虛擬機上如果單線程拉取 20 萬 partition 約只需要 6s 左右），因此在 controller 恢復時，并行拉取 partition 可以明顯縮短恢復時間。

• 變更同步元數據的方式

上文中提到 100 萬 partition 生成的元數據約 80MB，如果我們限制了單 broker 上 partition 數量，意味著我們需要增加 broker 的節點數，controller 切換并行同步給大量的 broker，會給 controller 節點帶來流量的沖擊，同時同步 80MB 的元數據也會消耗比較長的時間。因此需要改變現在集群同步元數據的方式，比如像存放消費位置一樣，通過內置 topic 來存放元數據，controller 把寫入到 ZK 上的數據通過消息的方式發送到內置存放元數據的 topic 上，broker 分別從 topic 上消費這些數據并更新內存中的元數據，這類的方案雖然可以在 controller 切換時全量同步元數據，但是需要對現在的 kafka 架構進行比較大的調整（當然還有其他更多的辦法，比如不使用 ZK 來管理元數據等，不過這不在本篇文章探討的范圍內）。

那有沒有其他的辦法，在對 kafka 架構改動較小的前提下來支持大規模 partition 的場景呢？我們知道 kafka 客戶端與 broker 交互時，會先通過指定的地址拉取 topic 元數據，然后再根據元數據連接 partition 相應的 Leader 進行生產和消費，我們通過控制元數據，可以控制客戶端生產消費連接的機器，這些機器在客戶端并不要求一定在同一個集群中，只需要客戶端能夠拿到這些 partition 的狀態信息，因此我們可以讓不同的 topic 分布到不同的集群上，然后再想辦法把不同集群上的 topic 信息組合在一起返回給客戶端，就能達到客戶端同時連接不同集群的效果，從客戶端視角來看就就是一個大的集群。這樣不需要單個物理集群支撐非常大的規模，可以通過組合多個物理集群的方式來達到支撐更大的規模，通過這種方式，擴容時不需要用戶停機修改業務，下面我們就來描述一下怎么實現這種方案。

2. 小集群組建邏輯集群

下面針對這些問題一一進行講解：

• metadata 服務

針對 metadata 組裝問題，我們可以在邏輯集群里的多個物理集群中選一個為主集群，其他集群為擴展集群，由主集群負責對外提供 metadata、消費位置、事務相關的服務，當然主集群也可以同時提供消息的生產消費服務，擴展集群只能用于業務消息的生產和消費。我們知道當 partition 的 Leader 切換時需要通過集群中的 controller 把新的 metadata 數據同步給集群中的 broker。當邏輯集群是由多個相互獨立的物理集群組成時，controller 無法感知到其他集群中的 Broker 節點。

我們可以對主集群中的 metada 接口進行簡單的改造，當客戶端拉取 metadata 時，我們可以跳轉到其他的集群上拉取 metadata, 然后在主集群上進行融合組裝再返回給客戶端。

雖然跳轉拉取 metadata 的方式有一些性能上的消耗，但是正常情況下并不在消息生產和消費的路徑上，對客戶端影響不大。通過客戶端拉取時再組裝 metadata，可以規避跨物理集群更新 metadata 的問題，同時也能夠保證實時性。

• 消費分組與事務協調

當消費分組之間的成員需要協調拉取數據的 partition 時，服務端會根據保存消費位置 topic 的 partition 信息返回對應的協調節點，因此我們在一個邏輯集群中需要確定消費位置 topic 分布的集群，避免訪問不同物理集群的節點返回的協調者不一樣，從不同集群上拉取到的消費位置不一樣等問題。我們可以選主集群的 broker 節點提供消費和事務協調的服務，消費位置也只保存在主集群上。

通過上述的一些改造，我們就可以支持更大的業務規模，用戶在使用時只需要知道主集群的地址就可以了。

組建邏輯集群除了上述的核心問題外，我們也需要關注 topic 的分配，由于騰訊云的 ckafka 本身就會把 broker 上創建 topic 的請求轉發給管控模塊創建，因此可以很方便的解決 topic 在多個物理集群的分布，也可以規避同一邏輯集群上，不同物理集群內可能出現同名 topic 的問題。

• 單物理集群分裂

進行集群的分裂涉及到 ZK 集群的分裂和對 broker 節點進行分組拆分，首先對集群中的 broker 節點分成兩組，每組連接不同的 ZK 節點，比如我們可以在原來的 zk 集群中增加 observer 節點，新增的 broker 為一組，原來集群中的 broker 為一組，我們讓新 broker 只填寫 observer 的地址。ZK 集群分裂前，通過 KAFKA 內置遷移工具可以很方便地把不同的 topic 遷移到各自的 broker 分組上，同一個 topic 的 partition 只會分布在同一個分組的 broker 節點上，后續把 observer 節點從現有的 ZK 集群中移除出去，然后讓 observer 與別的 ZK 節點組成新的 ZK 集群，從而實現 kafka 集群的分裂。

“Kafka集群突破百萬中partition的技術分析”的內容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業相關的知識可以關注億速云網站，小編將為大家輸出更多高質量的實用文章！