Kafka支持單集羣20萬分區

Kafka支持單集羣20萬分區

以前網上關於肯定Kafka分區數的博客多多少少都源自於饒軍大神的文章，現在他帶來了這方面的第二篇文章，特此翻譯一下，記錄一下其中的要點。

　　原貼地址： https://www.confluent.io/blog/apache-kafka-supports-200k-partitions-per-cluster

---

 

　　Kafka中topic能夠設置多個分區，而分區是最小的並行度單位。一般而言，分區數越多吞吐量也越高。可是依然有不少因素制約了一個Kafka集羣所能支持的最大分區數。我如今高興地宣佈Kafka 1.1.0版本在這方面取得了重大的改進。目前生產環境中單Kafka集羣支持的分區上限獲得了極大的提高。

　　爲了便於理解這個改進是如何實現的，咱們重溫一下分區leader和controller的基本概念。首先，每一個分區均可以配置多個副本用於實現高可用性以及持久性。其中的一個副本被指定爲leader而全部client只與leader進行交互；其次，cluster中的某個broker被指定爲controller來管理整個集羣。若broker掛掉，controller負責爲該broker上全部分區選舉leader。

　　默認狀況下關閉Kafka broker執行的是一個受控關閉操做（下稱controlled shutdown）。Controlled shutdown對client的影響是最小的。一個典型的controlled shutdown分爲如下幾步：1. 發送SIGTERM信號給待關閉的broker；2. Broker發送請求給controller代表本身要正常關閉；3. Controller變動該broker上全部分區的leader並將這部分數據保存回Zookeeper；4. Controller發送新的leader信息給其餘broker；5. Controller發送響應給關閉中的broker代表操做成功，因而broker成功關閉。此時，client端不受任何影響由於新leader已經轉移到其餘broker上。下面的兩張圖描述了這個過程，注意到圖中(4)和(5)步是能夠並行執行的：

       

上圖中步驟(1)發起broker關閉；步驟(2)發送controlled shutdown請求給controller；步驟(3)中controller寫入新leader到Zookeeper；步驟(4)controller發送新leader信息到其餘broker；步驟(5)controller發送成功信息給關閉中的broker

 　　在Kafka 1.1.0以前，一旦發起controlled shutdown，controller每次只能爲一個分區選舉leader。對於每一個分區而言，controller順序執行：選擇新leader、同步寫leader信息回Zookeeper以及同步leader信息給其餘broker等操做。這種設計是低效率的：首先，同步寫入Zookeeper就有很高的延時，從而總體拖慢controller shudown時間；其次，每次處理一個分區的作法致使須要給其餘broker發送不少次請求，即便這些請求自己攜帶的數據量是很小的，從而最終致使對新leader的處理時間被極大地拉長。

　　Kafka 1.1.0爲controlled shutdown引入了多個方面的性能提高。第一個提高就是使用異步API來替代了以前的同步寫入Zookeeper。在controlled shutdown過程當中，Kafka再也不是每次寫入一個leader信息，等待其完成而後再寫入下一個。相反地，controller使用異步API一次性地提交多個分區的leader到Zookeeper上，而後統一等待其執行完畢。這就等於在Kafka與Zookeeper之間構建了一種管道式請求處理流程，從而減小了總體的延時。第二個提高則是將於新leader的交互操做批量化。與其每次爲一個分區發送RPC請求，controller使用單個RPC請求一次性地攜帶全部受影響分區的leader信息。

　　同時，Kafka對於controller failover的時間也作了優化。當controller掛掉後，Kafka集羣自動檢測controller失敗並選擇其餘broker做爲新的controller。在開啓controller工做以前，新選出的controller必需要從Zookeeper中加載全部分區的狀態信息到內存中。若是controller直接崩潰的話，分區不可用的時間窗口將等同於Zookeeper會話超時時間加上controller狀態加載時間，因此下降加載時間可以有效地幫助咱們改善Kafka可用性。在1.1.0以前，加載操做使用的也是同步Zookeeper API。在1.1.0中被替換成了異步API。

　　社區對controlled shutdown時間和加載時間都作了測試。每一個測試都使用了5節點Zookeeper的集羣。在測試controlled shutdown時，社區搭建了一個5節點broker的Kafka集羣併爲該集羣建立了25000個單分區的topic，每一個topic都是雙副本，故每一個broker上平均有10000個分區。以後測試controlled shutdown，測試結果以下：

　　提高的很大一部分來自於修復了打日誌(logging)的開銷：以前在每一個分區leader變動時都會記錄集羣中全部分區的數據——這其實是不必的。經過修復了這個logging的bug，controller shutdown從6.5分鐘被壓縮到30秒，而採用異步API更進一步地將其拉低到3秒。這些提高都極大地縮短了Kafka集羣重啓恢復的時間。

　　在第二項測試中，社區一樣搭建了一個5節點集羣，只不過此次建立了2000個配置有50分區的topic，單副本——故總數是1000000個分區。當測試controller狀態加載時間時發現比1.0.0有了100%的提高（1.0.0耗時28秒，1.1.0耗時14秒）。

　　有了這些提高，Kafka單集羣可以支持多少分區呢？確切的數字天然依賴於諸如可容忍的不可用窗口時間、Zookeeper延時、broker存儲類型等因素。根據經驗法則咱們評估單臺broker可以支撐的分區數可達4000個，而單集羣可以支撐200000個分區。固然後者主要受限於集羣對controller崩潰這種不常見情形的容忍度，另外其餘影響分區數的因素也要考慮進來。

　　1.1.0所作的改進僅僅是提高Kafka高擴展性的一小步。事實上社區在1.1.0版本還嘗試了更多的分區並改進了它們的延時表現。後面可能會在另外一篇文章中給出具體的說明。在將來，Kafka社區計劃實現單集羣支撐百萬級分區的構想，因此，敬請期待~~