Kafka集群突破百萬中partition的技術(shù)分析

本篇內(nèi)容介紹了“Kafka集群突破百萬中partition的技術(shù)分析”的有關(guān)知識(shí)，在實(shí)際案例的操作過程中，不少人都會(huì)遇到這樣的困境，接下來就讓小編帶領(lǐng)大家學(xué)習(xí)一下如何處理這些情況吧！希望大家仔細(xì)閱讀，能夠?qū)W有所成！

Kafka 的 topic 在 broker 上是以 partition 為最小單位存放和進(jìn)行復(fù)制的, 因此集群需要維護(hù)每個(gè) partition 的 Leader 信息，單個(gè) partition 的多個(gè)副本都存放在哪些 broker 節(jié)點(diǎn)上，處于復(fù)制同步狀態(tài)的副本都有哪些。為了存放這些元數(shù)據(jù)，kafka 集群會(huì)為每一個(gè) partition 在 zk 集群上創(chuàng)建一個(gè)節(jié)點(diǎn)，partition 的數(shù)量直接決定了 zk 上的節(jié)點(diǎn)數(shù)。

假設(shè)集群上有 1 萬個(gè) topic，每個(gè) topic 包含 100 個(gè) partition，則 ZK 上節(jié)點(diǎn)數(shù)約為 200 多萬個(gè)，快照大小約為 300MB，ZK 節(jié)點(diǎn)數(shù)據(jù)變更，會(huì)把數(shù)據(jù)會(huì)寫在事務(wù)日志中進(jìn)行持久化存儲(chǔ)，當(dāng)事務(wù)日志達(dá)到一定的條目會(huì)全量寫入數(shù)據(jù)到持久化快照文件中，partition 節(jié)點(diǎn)數(shù)擴(kuò)大意味著快照文件也大，全量寫入快照與事務(wù)日志的寫入會(huì)相互影響，從而影響客戶端的響應(yīng)速度，同時(shí) zk 節(jié)點(diǎn)重啟加載快照的時(shí)間也會(huì)變長。

2. Partition 復(fù)制

Kafka 的 partition 復(fù)制由獨(dú)立的復(fù)制線程負(fù)責(zé)，多個(gè) partition 會(huì)共用復(fù)制線程，當(dāng)單個(gè) broker 上的 partition 增大以后，單個(gè)復(fù)制線程負(fù)責(zé)的 partition 數(shù)也會(huì)增多，每個(gè) partition 對(duì)應(yīng)一個(gè)日志文件，當(dāng)大量的 partition 同時(shí)有寫入時(shí)，磁盤上文件的寫入也會(huì)更分散，寫入性能變差，可能出現(xiàn)復(fù)制跟不上，導(dǎo)致 ISR 頻繁波動(dòng)，調(diào)整復(fù)制線程的數(shù)量可以減少單個(gè)線程負(fù)責(zé)的 partition 數(shù)量，但是也加劇了磁盤的爭用。

3. Controller 切換時(shí)長

由于網(wǎng)絡(luò)或者機(jī)器故障等原因，運(yùn)行中的集群可能存在 controller 切換的情況，當(dāng) controller 切換時(shí)需要從 ZK 中恢復(fù) broker 節(jié)點(diǎn)信息、topic 的 partition 復(fù)制關(guān)系、partition 當(dāng)前 leader 在哪個(gè)節(jié)點(diǎn)上等，然后會(huì)把 partition 完整的信息同步給每一個(gè) broker 節(jié)點(diǎn)。

在虛擬機(jī)上測試，100 萬 partition 的元數(shù)據(jù)從 ZK 恢復(fù)到 broker 上約需要 37s 的時(shí)間，100 萬 partition 生成的元數(shù)據(jù)序列化后大約 80MB（數(shù)據(jù)大小與副本數(shù)、topic 名字長度等相關(guān)），其他 broker 接收到元數(shù)據(jù)后，進(jìn)行反序列化并更新到本機(jī) broker 內(nèi)存中，應(yīng)答響應(yīng)時(shí)間約需要 40s（測試時(shí)長與網(wǎng)絡(luò)環(huán)境有關(guān)）。

Controller 控制了 leader 切換與元數(shù)據(jù)的下發(fā)給集群中其他 broker 節(jié)點(diǎn)，controller 的恢復(fù)時(shí)間變長增加了集群不可用風(fēng)險(xiǎn)，當(dāng) controller 切換時(shí)如果存在 partition 的 Leader 需要切換，就可能存在客戶端比較長的時(shí)間內(nèi)拿不到新的 leader，導(dǎo)致服務(wù)中斷。

4. broker 上下線恢復(fù)時(shí)長

日常維護(hù)中可能需要對(duì) broker 進(jìn)行重啟操作，為了不影響用戶使用，broker 在停止前會(huì)通知 controller 進(jìn)行 Leader 切換，同樣 broker 故障時(shí)也會(huì)進(jìn)行 leader 切換，leader 切換信息需要更新 ZK 上的 partition 狀態(tài)節(jié)點(diǎn)數(shù)據(jù)，并同步給其他的 broker 進(jìn)行 metadata 信息更新。當(dāng) partition 數(shù)量變多，意味著單個(gè) broker 節(jié)點(diǎn)上的 partitiion Leader 切換時(shí)間變長。

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

1. 單 ZK 集群

從提升單個(gè) controller 處理性能方面可以進(jìn)行下面的優(yōu)化：

• 并行拉取 zk 節(jié)點(diǎn)

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

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

• 變更同步元數(shù)據(jù)的方式

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

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

2. 小集群組建邏輯集群

下面針對(duì)這些問題一一進(jìn)行講解：

• metadata 服務(wù)

針對(duì) metadata 組裝問題，我們可以在邏輯集群里的多個(gè)物理集群中選一個(gè)為主集群，其他集群為擴(kuò)展集群，由主集群負(fù)責(zé)對(duì)外提供 metadata、消費(fèi)位置、事務(wù)相關(guān)的服務(wù)，當(dāng)然主集群也可以同時(shí)提供消息的生產(chǎn)消費(fèi)服務(wù)，擴(kuò)展集群只能用于業(yè)務(wù)消息的生產(chǎn)和消費(fèi)。我們知道當(dāng) partition 的 Leader 切換時(shí)需要通過集群中的 controller 把新的 metadata 數(shù)據(jù)同步給集群中的 broker。當(dāng)邏輯集群是由多個(gè)相互獨(dú)立的物理集群組成時(shí)，controller 無法感知到其他集群中的 Broker 節(jié)點(diǎn)。

我們可以對(duì)主集群中的 metada 接口進(jìn)行簡單的改造，當(dāng)客戶端拉取 metadata 時(shí)，我們可以跳轉(zhuǎn)到其他的集群上拉取 metadata, 然后在主集群上進(jìn)行融合組裝再返回給客戶端。

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

• 消費(fèi)分組與事務(wù)協(xié)調(diào)

當(dāng)消費(fèi)分組之間的成員需要協(xié)調(diào)拉取數(shù)據(jù)的 partition 時(shí)，服務(wù)端會(huì)根據(jù)保存消費(fèi)位置 topic 的 partition 信息返回對(duì)應(yīng)的協(xié)調(diào)節(jié)點(diǎn)，因此我們在一個(gè)邏輯集群中需要確定消費(fèi)位置 topic 分布的集群，避免訪問不同物理集群的節(jié)點(diǎn)返回的協(xié)調(diào)者不一樣，從不同集群上拉取到的消費(fèi)位置不一樣等問題。我們可以選主集群的 broker 節(jié)點(diǎn)提供消費(fèi)和事務(wù)協(xié)調(diào)的服務(wù)，消費(fèi)位置也只保存在主集群上。

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

組建邏輯集群除了上述的核心問題外，我們也需要關(guān)注 topic 的分配，由于騰訊云的 ckafka 本身就會(huì)把 broker 上創(chuàng)建 topic 的請(qǐng)求轉(zhuǎn)發(fā)給管控模塊創(chuàng)建，因此可以很方便的解決 topic 在多個(gè)物理集群的分布，也可以規(guī)避同一邏輯集群上，不同物理集群內(nèi)可能出現(xiàn)同名 topic 的問題。

• 單物理集群分裂

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

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