kafka中怎么設置分區數

這期內容當中小編將會給大家帶來有關kafka中怎么設置分區數，文章內容豐富且以專業的角度為大家分析和敘述，閱讀完這篇文章希望大家可以有所收獲。

越多的分區可以提供更高的吞吐量

　　首先我們需要明白以下事實：在kafka中，單個patition是kafka并行操作的最小單元。在producer和broker端，向每一個分區寫入數據是可以完全并行化的，此時，可以通過加大硬件資源的利用率來提升系統的吞吐量，例如對數據進行壓縮。在consumer段，kafka只允許單個partition的數據被一個consumer線程消費。因此，在consumer端，每一個Consumer Group內部的consumer并行度完全依賴于被消費的分區數量。綜上所述，通常情況下，在一個Kafka集群中，partition的數量越多，意味著可以到達的吞吐量越大。

　　我們可以粗略地通過吞吐量來計算kafka集群的分區數量。假設對于單個partition，producer端的可達吞吐量為p，Consumer端的可達吞吐量為c，期望的目標吞吐量為t，那么集群所需要的partition數量至少為max(t/p,t/c)。在producer端，單個分區的吞吐量大小會受到批量大小、數據壓縮方法、 確認類型（同步/異步）、復制因子等配置參數的影響。經過測試，在producer端，單個partition的吞吐量通常是在10MB/s左右。在consumer端，單個partition的吞吐量依賴于consumer端每個消息的應用邏輯處理速度。因此，我們需要對consumer端的吞吐量進行測量。

　　雖然隨著時間的推移，我們能夠對分區的數量進行添加，但是對于基于Key來生成的這一類消息需要我們重點關注。當producer向kafka寫入基于key的消息時，kafka通過key的hash值來確定消息需要寫入哪個具體的分區。通過這樣的方案，kafka能夠確保相同key值的數據可以寫入同一個partition。kafka的這一能力對于一部分應用是極為重要的，例如對于同一個key的所有消息，consumer需要按消息的順序進行有序消費。如果partition的數量發生改變，那么上面的有序性保證將不復存在。為了避免上述情況發生，通常的解決辦法是多分配一些分區，以滿足未來的需求。通常情況下，我們需要根據未來1到2年的目標吞吐量來設計kafka的分區數量。

　　一開始，我們可以基于當前的業務吞吐量為kafka集群分配較小的broker數量，隨著時間的推移，我們可以向集群中增加更多的broker，然后在線方式將適當比例的partition轉移到新增加的broker中去。通過這樣的方法，我們可以在滿足各種應用場景（包括基于key消息的場景）的情況下，保持業務吞吐量的擴展性。

　　在設計分區數時，除了吞吐量，還有一些其他因素值得考慮。正如我們后面即將看到的，對于一些應用場景，集群擁有過的分區將會帶來負面的影響。

回到頂部

  越多的分區需要打開更多地文件句柄

　　在kafka的broker中，每個分區都會對照著文件系統的一個目錄。在kafka的數據日志文件目錄中，每個日志數據段都會分配兩個文件，一個索引文件和一個數據文件。當前版本的kafka，每個broker會為每個日志段文件打開一個index文件句柄和一個數據文件句柄。因此，隨著partition的增多，需要底層操作系統配置更高的文件句柄數量限制。這更多的是一個配置問題。我們曾經見到過，在生產環境Kafka集群中，每個broker打開的文件句柄數量超過30,000。

回到頂部

  更多地分區會導致更高的不可用性

Kafka通過多副本復制技術，實現kafka集群的高可用和穩定性。每個partition都會有多個數據副本，每個副本分別存在于不同的broker。所有的數據副本中，有一個數據副本為Leader，其他的數據副本為follower。在kafka集群內部，所有的數據副本皆采用自動化的方式進行管理，并且確保所有的數據副本的數據皆保持同步狀態。不論是producer端還是consumer端發往partition的請求，皆通過leader數據副本所在的broker進行處理。當broker發生故障時，對于leader數據副本在該broker的所有partition將會變得暫時不可用。Kafka將會自動在其他數據副本中選擇出一個leader，用于接收客戶端的請求。這個過程由kafka controller節點broker自動完成，主要是從Zookeeper讀取和修改受影響partition的一些元數據信息。在當前的kafka版本實現中，對于zookeeper的所有操作都是由kafka controller來完成的（serially的方式）。

　　在通常情況下，當一個broker有計劃地停止服務時，那么controller會在服務停止之前，將該broker上的所有leader一個個地移走。由于單個leader的移動時間大約只需要花費幾毫秒，因此從客戶層面看，有計劃的服務停機只會導致系統在很小時間窗口中不可用。（注：在有計劃地停機時，系統每一個時間窗口只會轉移一個leader，其他leader皆處于可用狀態。）

　　然而，當broker非計劃地停止服務時（例如，kill -9方式)，系統的不可用時間窗口將會與受影響的partition數量有關。假如，一個2節點的kafka集群中存在2000個partition，每個partition擁有2個數據副本。當其中一個broker非計劃地宕機，所有1000個partition同時變得不可用。假設每一個partition恢復時間是5ms，那么1000個partition的恢復時間將會花費5秒鐘。因此，在這種情況下，用戶將會觀察到系統存在5秒鐘的不可用時間窗口。

　　更不幸的情況發生在宕機的broker恰好是controller節點時。在這種情況下，新leader節點的選舉過程在controller節點恢復到新的broker之前不會啟動。Controller節點的錯誤恢復將會自動地進行，但是新的controller節點需要從zookeeper中讀取每一個partition的元數據信息用于初始化數據。例如，假設一個kafka集群存在10,000個partition，從zookeeper中恢復元數據時每個partition大約花費2ms，則controller的恢復將會增加約20秒的不可用時間窗口。

　　通常情況下，非計劃的宕機事件發生的情況是很少的。如果系統可用性無法容忍這些少數情況的場景，我們最好是將每個broker的partition數量限制在2,000到4,000，每個kafka集群中partition的數量限制在10,000以內。

回到頂部

  越多的分區可能增加端對端的延遲

Kafka端對端延遲定義為producer端發布消息到consumer端接收消息所需要的時間。即consumer接收消息的時間減去producer發布消息的時間。Kafka只有在消息提交之后，才會將消息暴露給消費者。例如，消息在所有in-sync副本列表同步復制完成之后才暴露。因此，in-sync副本復制所花時間將是kafka端對端延遲的最主要部分。在默認情況下，每個broker從其他broker節點進行數據副本復制時，該broker節點只會為此工作分配一個線程，該線程需要完成該broker所有partition數據的復制。經驗顯示，將1000個partition從一個broker到另一個broker所帶來的時間延遲約為20ms，這意味著端對端的延遲至少是20ms。這樣的延遲對于一些實時應用需求來說顯得過長。

　　注意，上述問題可以通過增大kafka集群來進行緩解。例如，將1000個分區leader放到一個broker節點和放到10個broker節點，他們之間的延遲是存在差異的。在10個broker節點的集群中，每個broker節點平均需要處理100個分區的數據復制。此時，端對端的延遲將會從原來的數十毫秒變為僅僅需要幾毫秒。

　　根據經驗，如果你十分關心消息延遲問題，限制每個broker節點的partition數量是一個很好的主意：對于b個broker節點和復制因子為r的kafka集群，整個kafka集群的partition數量最好不超過100*b*r個，即單個partition的leader數量不超過100.

回到頂部

  越多的partition意味著需要客戶端需要更多的內存

　　在最新發布的0.8.2版本的kafka中，我們開發了一個更加高效的Java?producer。新版producer擁有一個比較好的特征，他允許用戶為待接入消息存儲空間設置內存大小上限。在內部實現層面，producer按照每一個partition來緩存消息。在數據積累到一定大小或者足夠的時間時，積累的消息將會從緩存中移除并發往broker節點。

　　如果partition的數量增加，消息將會在producer端按更多的partition進行積累。眾多的partition所消耗的內存匯集起來，有可能會超過設置的內容大小限制。當這種情況發生時，producer必須通過消息堵塞或者丟失一些新消息的方式解決上述問題，但是這兩種做法都不理想。為了避免這種情況發生，我們必須重新將produder的內存設置得更大一些。

　　根據經驗，為了達到較好的吞吐量，我們必須在producer端為每個分區分配至少幾十KB的內存，并且在分區數量顯著增加時調整可以使用的內存數量。

　　類似的事情對于consumer端依然有效。Consumer端每次從kafka按每個分區取出一批消息進行消費。消費的分區數越多，需要的內存數量越大。盡管如此，上述方式主要運用于非實時的應用場景。

回到頂部

  總結

　　通常情況下，kafka集群中越多的partition會帶來越高的吞吐量。但是，我們必須意識到集群的partition總量過大或者單個broker節點partition過多，都會對系統的可用性和消息延遲帶來潛在的影響。未來，我們計劃對這些限制進行一些改進，讓kafka在分區數量方面變得更加可擴展。

上述就是小編為大家分享的kafka中怎么設置分區數了，如果剛好有類似的疑惑，不妨參照上述分析進行理解。如果想知道更多相關知識，歡迎關注億速云行業資訊頻道。