kafka是非常流行的分布式流式處理和大資料訊息佇列解決方案，在技術行業已經得到了廣泛採用，在dropbox也不例外。kafka在dropbox的很多分布式系統資料結構中發揮著重要的作用：資料分析、機器學習、監控、搜尋和流式處理，等等。在dropbox，kafka集群由jetstream團隊負責管理，他們的主要職責是提供高質量的kafka服務。他們的乙個主要目標是了解kafka在dropbox基礎設施中的吞吐量極限，這對於針對不同用例做出適當的配置決策來說至關重要。最近，他們建立了乙個自動化測試平台來實現這一目標。這篇文章將分享他們所使用的方法和一些有趣的發現。上圖描繪了本文所使用的測試平台的設定。我們在spark中使用kafka客戶端，這樣就可以以任意規模生成和消費流量。我們搭建了三個不同大小的kafka集群，要調整集群大小，只需要將流量重定向到不同的集群。我們建立了乙個kafka主題，用於生成測試流量。為簡單起見，我們將流量均勻地分布在kafka broker之間。為實現這一目標，我們建立了測試主題，分割槽數量是broker數量的10倍，這樣每個broker都是10個分割槽的首領。因為寫入單個分割槽是序列的，所以如果每個broker的分割槽太少會導致寫入競爭，從而限制了吞吐量。根據我們的實驗，10是乙個恰到好處的數字，可以避免寫入競爭造成吞吐量瓶頸。
由於基礎設施的分布式特性，客戶端遍布在美國的不同地區。因為測試流量遠低於dropbox網路主幹的限制，所以我們可以安全地假設跨區域流量的限制也適用於本地流量。
有一系列因素會影響kafka集群的工作負載：生產者數量、消費者群組數量、初始消費者偏移量、每秒訊息數量、每條訊息的大小，以及所涉及的主題和分割槽的數量，等等。我們可以自由地設定引數，因此，很有必要找到主導的影響因素，以便將測試複雜性降低到實用水平。
我們研究了不同的引數組合，最後得出結論，我們需要考慮的主要因素是每秒產生的訊息數（mps）和每個訊息的位元組大小（bpm）。
我們採取了正式的方法來了解kafka的吞吐量極限。特定的kafka集群都有乙個相關聯的流量空間，這個多維空間中的每乙個點都對應乙個kafka流量模式，可以通過引數向量來表示：\u0026lt;mps、bpm、生產者數量、消費者群組數量、主題數量……\u0026gt;。所有不會導致kafka過載的流量模式都形成了乙個封閉的子空間，其表面就是kafka集群的吞吐量極限。
對於初始測試，我們選擇將mps和bpm作為吞吐量極限的基礎，因此流量空間就降到二維平面。這一系列可接受的流量形成了乙個封閉的區域，找到kafka的吞吐量極限相當於繪製出該區域的邊界。
為了以合理的精度繪製出邊界，我們需要用不同的設定進行數百次實驗，通過手動操作的方式是不切實際的。因此，我們設計了一種演算法，無需人工干預即可執行所有的實驗。
我們需要找到一系列能夠以程式設計方式判斷kafka健康狀況的指標。我們研究了大量的候選指標，最後鎖定以下這些：
同步副本集變化超過50％：這意味著在50％的時間內至少有乙個broker無法及時複製首領的資料。
jetstream團隊還使用這些指標來監控kafka執行狀況，當集群承受過大壓力時，這些指標會首當其衝發出訊號。
為了找到乙個邊界點，我們讓bpm維度固定，並嘗試通過更改mps值來讓kafka過載。當我們有乙個安全的mps值和另乙個導致集群接近過載的mps值時，邊界就找到了。我們將安全的值視為邊界點，然後通過重複這個過程來找到整條邊界線，如下所示：
值得注意的是，我們調整了具有相同生產速率的生產者（用np表示），而不是直接調整mps。主要是因為批處理方式導致單個生產者的生產速率不易控制。相反，改變生產者的數量可以線性地縮放流量。根據我們早期的研究，單獨增加生產者數量不會給kafka帶來明顯的負載差異。
我們通過二分查詢來尋找單邊界點。二分查詢從乙個非常大的np[0,max]視窗開始，其中max是乙個肯定會導致過載的值。在每次迭代中，選擇中間值來生成流量。如果kafka在使用這個值時發生過載，那麼這個值將成為新的上限，否則就成為新的下限。當視窗足夠窄時，停止該過程。我們將對應於當前下限的mps值視為邊界。
我們在上圖中繪製了不同大小的kafka的邊界。基於這個結果，我們可以得出結論，dropbox基礎設施可以承受的最大吞吐量為每個broker 60mb/s。
值得注意的是，這只是乙個保守的極限，因為我們測試用的訊息大小完全是隨機的，主要是為了最小化kafka內部訊息壓縮機制所帶來的影響。在生產環境中，kafka訊息通常遵循某種模式，因為它們通常由相似的過程生成，這為壓縮優化提供了很大的空間。我們測試了乙個極端情況，訊息全部由相同的字元組成，這個時候我們可以看到更高的吞吐量極限。
此外，當有5個消費者群組訂閱測試主題時，這個吞吐量限制仍然有效。換句話說，當讀取吞吐量是當前5倍時，仍然可以實現這樣的寫入吞吐量。當消費者群組增加到5個以上時，隨著網路成為瓶頸，寫入吞吐量開始下降。因為dropbox生產環境中的讀寫流量比遠低於5，所以我們得到的極限適用於所有生產集群。
這個結果為將來的kafka配置提供了指導基礎。假設我們允許最多20％的broker離線，那麼單個broker的最大安全吞吐量應為60mb/s * 0.8 ~= 50mb/s。有了這個，我們可以根據未來用例的估算吞吐量來確定集群大小。
這個平台和自動化測試套件將成為jetstream團隊的一筆寶貴的財富。當我們切換到新硬體、更改網路配置或公升級kafka版本時，可以重新執行這些測試並獲得新的吞吐量極限。我們可以應用相同的方法來探索其他影響kafka效能的因素。最後，這個平台可以作為jetstream的測試平台，以便模擬新的流量模式或在隔離環境中重現問題。
在這篇文章中，我們提出了一種系統方法來了解kafka的吞吐量極限。值得注意的是，我們是基於dropbox的基礎設施得到的這些結果，因此，由於硬體、軟體棧和網路條件的不同，我們得到的數字可能不適用於其他kafka例項。我們希望這裡介紹的技術能夠幫助讀者去了解他們自己的kafka系統。
英文原文：
如何找到Kafka集群的吞吐量極限？ n
kafka是非常流行的分布式流式處理和大資料訊息佇列解決方案，在技術行業已經得到了廣泛採用，在dropbox也不例外。kafka在dropbox的很多分布式系統資料結構中發揮著重要的作用 資料分析 機器學習 監控 搜尋和流式處理，等等。在dropbox，kafka集群由jetstream團隊負責管理...
如何找到Kafka集群的吞吐量極限？ n
kafka是非常流行的分布式流式處理和大資料訊息佇列解決方案，在技術行業已經得到了廣泛採用，在dropbox也不例外。kafka在dropbox的很多分布式系統資料結構中發揮著重要的作用 資料分析 機器學習 監控 搜尋和流式處理，等等。在dropbox，kafka集群由jetstream團隊負責管理...
如何找到Kafka集群的吞吐量極限？ n
kafka是非常流行的分布式流式處理和大資料訊息佇列解決方案，在技術行業已經得到了廣泛採用，在dropbox也不例外。kafka在dropbox的很多分布式系統資料結構中發揮著重要的作用 資料分析 機器學習 監控 搜尋和流式處理，等等。在dropbox，kafka集群由jetstream團隊負責管理...