kafka的優缺點都有那些

Kafka是由Apache軟體基金會開發的一個開源流處理平臺，由Scala和Java編寫。Kafka是一種高吞吐量的分散式釋出訂閱訊息系統，它可以處理消費者在網站中的所有動作流資料。 

（1）優點：kafka的優點非常多

高效能：單機測試能達到 100w tps；

低延時：生產和消費的延時都很低，e2e的延時在正常的cluster中也很低；

可用性高：replicate + isr + 選舉 機制保證；

工具鏈成熟：監控 運維 管理 方案齊全；

生態成熟：大資料場景必不可少 kafka stream.

（2）不足

無法彈性擴容：對partition的讀寫都在partition leader所在的broker，如果該broker壓力過大，也無法通過新增broker來解決問題；

擴容成本高：叢集中新增的broker只會處理新topic，如果要分擔老topic-partition的壓力，需要手動遷移partition，這時會佔用大量叢集頻寬；

消費者新加入和退出會造成整個消費組rebalance：導致資料重複消費，影響消費速度，增加e2e延遲；

partition過多會使得效能顯著下降：ZK壓力大，broker上partition過多讓磁碟順序寫幾乎退化成隨機寫。

在瞭解了kafka的架構之後，你可以仔細想一想，為什麼kafka擴容這麼費勁呢？其實這本質上和redis叢集擴容是一樣的！當redis叢集出現熱key時，某個例項扛不住了，你通過加機器並不能解決什麼問題，因為那個熱key還是在之前的某個例項中，新擴容的例項起不到分流的作用。大資料培訓kafka類似，它擴容有兩種：新加機器（加broker）以及給topic增加partition。

給topic新加partition這個操作，你可以聯想一下mysql的分表。比如使用者訂單表，由於量太大把它按使用者id拆分成1024個子表user_order_{0..1023}，如果到後期發現還不夠用，要增加這個分表數，就會比較麻煩。因為分表總數增多，會讓user_id的hash值發生變化，從而導致老的資料無法查詢。所以只能停服做資料遷移，然後再重新上線。

kafka給topic新增partition一樣的道理，比如在某些場景下msg包含key，那producer就要保證相同的key放到相同的partition。但是如果partition總量增加了，根據key去進行hash，比如 hash(key) % parition_num，得到的結果就不同，就無法保證相同的key存到同一個partition。

當然也可以在producer上實現一個自定義的partitioner，保證不論怎麼擴partition相同的key都落到相同的partition上，但是這又會使得新增加的partition沒有任何資料。

其實你可以發現一個問題，kafka的核心複雜度幾乎都在儲存這一塊。資料如何分片，如何高效的儲存，如何高效地讀取，如何保證一致性，如何從錯誤中恢復，如何擴容再平衡……

版權宣告：本文為「尚矽谷」的原創文章，轉載請附上原文出處連結及本宣告。下載相關視訊學習資料到官方網站。