Kafka 是非常流行的分布式流式處理和大數(shù)據(jù)消息隊(duì)列解決方案，在技術(shù)行業(yè)已經(jīng)得到了廣泛采用，在 Dropbox 也不例外。Kafka 在 Dropbox 的很多分布式系統(tǒng)數(shù)據(jù)結(jié)構(gòu)中發(fā)揮著重要的作用：數(shù)據(jù)分析、機(jī)器學(xué)習(xí)、監(jiān)控、搜索和流式處理，等等。在 Dropbox，Kafka 集群由 Jetstream 團(tuán)隊(duì)負(fù)責(zé)管理，他們的主要職責(zé)是提供高質(zhì)量的 Kafka 服務(wù)。他們的一個(gè)主要目標(biāo)是了解 Kafka 在 Dropbox 基礎(chǔ)設(shè)施中的吞吐量極限，這對(duì)于針對(duì)不同用例做出適當(dāng)?shù)呐渲脹Q策來(lái)說(shuō)至關(guān)重要。最近，他們創(chuàng)建了一個(gè)自動(dòng)化測(cè)試平臺(tái)來(lái)實(shí)現(xiàn)這一目標(biāo)。這篇文章將分享他們所使用的方法和一些有趣的發(fā)現(xiàn)。

測(cè)試平臺(tái)

上圖描繪了本文所使用的測(cè)試平臺(tái)的設(shè)置。我們?cè)?Spark 中使用 Kafka 客戶端，這樣就可以以任意規(guī)模生成和消費(fèi)流量。我們搭建了三個(gè)不同大小的 Kafka 集群，要調(diào)整集群大小，只需要將流量重定向到不同的集群。我們創(chuàng)建了一個(gè) Kafka 主題，用于生成測(cè)試流量。為簡(jiǎn)單起見(jiàn)，我們將流量均勻地分布在 Kafka broker 之間。為實(shí)現(xiàn)這一目標(biāo)，我們創(chuàng)建了測(cè)試主題，分區(qū)數(shù)量是 broker 數(shù)量的 10 倍，這樣每個(gè) broker 都是 10 個(gè)分區(qū)的首領(lǐng)。因?yàn)閷懭雴蝹€(gè)分區(qū)是串行的，所以如果每個(gè) broker 的分區(qū)太少會(huì)導(dǎo)致寫入競(jìng)爭(zhēng)，從而限制了吞吐量。根據(jù)我們的實(shí)驗(yàn)，10 是一個(gè)恰到好處的數(shù)字，可以避免寫入競(jìng)爭(zhēng)造成吞吐量瓶頸。

由于基礎(chǔ)設(shè)施的分布式特性，客戶端遍布在美國(guó)的不同地區(qū)。因?yàn)闇y(cè)試流量遠(yuǎn)低于 Dropbox 網(wǎng)絡(luò)主干的限制，所以我們可以安全地假設(shè)跨區(qū)域流量的限制也適用于本地流量。

---

是什么影響了工作負(fù)載?

有一系列因素會(huì)影響 Kafka 集群的工作負(fù)載：生產(chǎn)者數(shù)量、消費(fèi)者群組數(shù)量、初始消費(fèi)者偏移量、每秒消息數(shù)量、每條消息的大小，以及所涉及的主題和分區(qū)的數(shù)量，等等。我們可以自由地設(shè)置參數(shù)，因此，很有必要找到主導(dǎo)的影響因素，以便將測(cè)試復(fù)雜性降低到實(shí)用水平。

我們研究了不同的參數(shù)組合，最后得出結(jié)論，我們需要考慮的主要因素是每秒產(chǎn)生的消息數(shù)(mps)和每個(gè)消息的字節(jié)大小(bpm)。

流量模型

我們采取了正式的方法來(lái)了解 Kafka 的吞吐量極限。特定的 Kafka 集群都有一個(gè)相關(guān)聯(lián)的流量空間，這個(gè)多維空間中的每一個(gè)點(diǎn)都對(duì)應(yīng)一個(gè) Kafka 流量模式，可以通過(guò)參數(shù)向量來(lái)表示：。所有不會(huì)導(dǎo)致 Kafka 過(guò)載的流量模式都形成了一個(gè)封閉的子空間，其表面就是 Kafka 集群的吞吐量極限。

對(duì)于初始測(cè)試，我們選擇將 mps 和 bpm 作為吞吐量極限的基礎(chǔ)，因此流量空間就降到二維平面。這一系列可接受的流量形成了一個(gè)封閉的區(qū)域，找到 Kafka 的吞吐量極限相當(dāng)于繪制出該區(qū)域的邊界。

自動(dòng)化測(cè)試

為了以合理的精度繪制出邊界，我們需要用不同的設(shè)置進(jìn)行數(shù)百次實(shí)驗(yàn)，通過(guò)手動(dòng)操作的方式是不切實(shí)際的。因此，我們?cè)O(shè)計(jì)了一種算法，無(wú)需人工干預(yù)即可運(yùn)行所有的實(shí)驗(yàn)。

過(guò)載指示器

我們需要找到一系列能夠以編程方式判斷 Kafka 健康狀況的指標(biāo)。我們研究了大量的候選指標(biāo)，最后鎖定以下這些：

IO 線程空閑低于 20%：這意味著 Kafka 用于處理客戶端請(qǐng)求的工作線程池太忙而無(wú)法處理更多工作負(fù)載。

同步副本集變化超過(guò) 50%：這意味著在 50%的時(shí)間內(nèi)至少有一個(gè) broker 無(wú)法及時(shí)復(fù)制首領(lǐng)的數(shù)據(jù)。

Jetstream 團(tuán)隊(duì)還使用這些指標(biāo)來(lái)監(jiān)控 Kafka 運(yùn)行狀況，當(dāng)集群承受過(guò)大壓力時(shí)，這些指標(biāo)會(huì)首當(dāng)其沖發(fā)出信號(hào)。

---

找到邊界

為了找到一個(gè)邊界點(diǎn)，我們讓 bpm 維度固定，并嘗試通過(guò)更改 mps 值來(lái)讓 Kafka 過(guò)載。當(dāng)我們有一個(gè)安全的 mps 值和另一個(gè)導(dǎo)致集群接近過(guò)載的 mps 值時(shí)，邊界就找到了。我們將安全的值視為邊界點(diǎn)，然后通過(guò)重復(fù)這個(gè)過(guò)程來(lái)找到整條邊界線，如下所示：

值得注意的是，我們調(diào)整了具有相同生產(chǎn)速率的生產(chǎn)者(用 np 表示)，而不是直接調(diào)整 mps。主要是因?yàn)榕幚矸绞綄?dǎo)致單個(gè)生產(chǎn)者的生產(chǎn)速率不易控制。相反，改變生產(chǎn)者的數(shù)量可以線性地縮放流量。根據(jù)我們?cè)缙诘难芯?#xff0c;單獨(dú)增加生產(chǎn)者數(shù)量不會(huì)給 Kafka 帶來(lái)明顯的負(fù)載差異。

我們通過(guò)二分查找來(lái)尋找單邊界點(diǎn)。二分查找從一個(gè)非常大的 np[0,max] 窗口開(kāi)始，其中 max 是一個(gè)肯定會(huì)導(dǎo)致過(guò)載的值。在每次迭代中，選擇中間值來(lái)生成流量。如果 Kafka 在使用這個(gè)值時(shí)發(fā)生過(guò)載，那么這個(gè)值將成為新的上限，否則就成為新的下限。當(dāng)窗口足夠窄時(shí)，停止該過(guò)程。我們將對(duì)應(yīng)于當(dāng)前下限的 mps 值視為邊界。

---

結(jié)果

我們?cè)谏蠄D中繪制了不同大小的 Kafka 的邊界。基于這個(gè)結(jié)果，我們可以得出結(jié)論，Dropbox 基礎(chǔ)設(shè)施可以承受的最大吞吐量為每個(gè) broker 60MB/s。

值得注意的是，這只是一個(gè)保守的極限，因?yàn)槲覀儨y(cè)試用的消息大小完全是隨機(jī)的，主要是為了最小化 Kafka 內(nèi)部消息壓縮機(jī)制所帶來(lái)的影響。在生產(chǎn)環(huán)境中，Kafka 消息通常遵循某種模式，因?yàn)樗鼈兺ǔＳ上嗨频倪^(guò)程生成，這為壓縮優(yōu)化提供了很大的空間。我們測(cè)試了一個(gè)極端情況，消息全部由相同的字符組成，這個(gè)時(shí)候我們可以看到更高的吞吐量極限。

此外，當(dāng)有 5 個(gè)消費(fèi)者群組訂閱測(cè)試主題時(shí)，這個(gè)吞吐量限制仍然有效。換句話說(shuō)，當(dāng)讀取吞吐量是當(dāng)前 5 倍時(shí)，仍然可以實(shí)現(xiàn)這樣的寫入吞吐量。當(dāng)消費(fèi)者群組增加到 5 個(gè)以上時(shí)，隨著網(wǎng)絡(luò)成為瓶頸，寫入吞吐量開(kāi)始下降。因?yàn)?Dropbox 生產(chǎn)環(huán)境中的讀寫流量比遠(yuǎn)低于 5，所以我們得到的極限適用于所有生產(chǎn)集群。

這個(gè)結(jié)果為將來(lái)的 Kafka 配置提供了指導(dǎo)基礎(chǔ)。假設(shè)我們?cè)试S最多 20%的 broker 離線，那么單個(gè) broker 的最大安全吞吐量應(yīng)為 60MB/s * 0.8 ~= 50MB/s。有了這個(gè)，我們可以根據(jù)未來(lái)用例的估算吞吐量來(lái)確定集群大小。

---

對(duì)未來(lái)工作的影響

這個(gè)平臺(tái)和自動(dòng)化測(cè)試套件將成為 Jetstream 團(tuán)隊(duì)的一筆寶貴的財(cái)富。當(dāng)我們切換到新硬件、更改網(wǎng)絡(luò)配置或升級(jí) Kafka 版本時(shí)，可以重新運(yùn)行這些測(cè)試并獲得新的吞吐量極限。我們可以應(yīng)用相同的方法來(lái)探索其他影響 Kafka 性能的因素。最后，這個(gè)平臺(tái)可以作為 Jetstream 的測(cè)試平臺(tái)，以便模擬新的流量模式或在隔離環(huán)境中重現(xiàn)問(wèn)題。

總結(jié)

在這篇文章中，我們提出了一種系統(tǒng)方法來(lái)了解 Kafka 的吞吐量極限。值得注意的是，我們是基于 Dropbox 的基礎(chǔ)設(shè)施得到的這些結(jié)果，因此，由于硬件、軟件棧和網(wǎng)絡(luò)條件的不同，我們得到的數(shù)字可能不適用于其他 Kafka 實(shí)例。我們希望這里介紹的技術(shù)能夠幫助讀者去了解他們自己的 Kafka 系統(tǒng)。

英文原文：https://blogs.dropbox.com/tech/2019/01/finding-kafkas-throughput-limit-in-dropbox-infrastructure/

總結(jié)

以上是生活随笔為你收集整理的吞吐量达到瓶颈后下降_如何找到 Kafka 集群的吞吐量极限？的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。