大家好，這是一個爲了夢想而保持學習的博客。這個專題會記錄我對於KAFKA的學習和實戰經驗，希望對大家有所幫助，目錄形式依舊爲問答的方式，相當於是模擬面試。
一、概述
在對kafka有了基礎的認知之後，回過頭來看看，當前kafka的 存儲架構 還存在哪些問題呢？
很多地方有提到kafka無法承載大量的分區這個問題，但是都只給了個結論，沒有說明其中緣由，這裏我們就來梳理一下。
二、磁盤順序寫特性被破壞，導致寫入吞吐量下降
我們從前面的【十一】小節知道，kafka有如此高的寫入吞吐量，主要是得益於追加寫的性能極高，但是如果這個特性被破壞，那麼寫入吞吐量就會有明顯的下降，那麼什麼時候會破壞這個特性呢？我們先從基本的磁盤IO說起。
機械硬盤的IO過程可以簡單的理解爲兩個階段：尋址 + 數據寫入 其中尋址是個物理動作，就是需要通過旋轉加上磁臂去找到對應的扇區，這個過程的耗時是毫秒級的，相對於其他計算機類的操作，高出了好幾個數量級。 而數據寫入呢，就是將我們的數據寫入物理載體中，相對來說也是很快的。
從這個大概的過程中，我們知道，機械硬盤的IO過程慢就慢在尋址這個操作上，那我們有沒有什麼辦法能優化掉這個過程呢？其中一個優化點就是追加寫。
試想你一直只對一個文件進行寫入，那麼磁臂就根本就不需要再尋址了呀，接着往下寫就好啦，所以就省去了尋址的這個開銷，讓寫磁盤的性能能接近寫內存。
也正是由於追加寫的這個特性，在Linux的IO調度層面，有4種不同的調度策略，都嘗試將隨機的IO請求儘可能的合併成順序寫或者臨近讀，從而優化IO性能，在這裏我簡單的提一下，大家有興趣可以進行查閱相關資料：
- NOOP：大致上就是所有進程共用一個先進先出隊列，做了簡單的相鄰請求合併。
- CFQ（默認）：特點是按照I/O請求的地址進行排序，而不是按照先進先出的順序響應的，並且會爲每個進程都創建一個這樣特點的隊列。但是存在“餓死”的場景，也就是我一個很小的讀請求要讀取很後面的地址，但是因爲排序之後，被前面的很大的I/O請求給卡住了，導致無法被執行。
- DEADLINE：針對CFQ算法進行了優化，爲每個請求設置了超時時間，如果達到了這麼個時間一定要被調度執行，讀等待時間爲500ms，寫等待時間爲5s。
- ANTICIPATORY：爲每個I/O都設置6ms的等待時間窗口，如果6ms內收到了相鄰的I/O請求，那麼就進行合併，通過增加時間的方式來獲取更高的性能，儘可能的將隨機讀寫轉換爲順序讀寫。
進入正題，爲什麼kafka的分區數多了知道會破壞追加寫的特性呢？
分區底層對應的是底層一個個segment文件，如果一個broker上，有上萬個分區，那麼對應的就需要去寫上萬個segment，那麼從磁盤的角度來說就是我剛寫完A文件，又要重新尋址去寫B文件，以此類推，當文件一多，就相當於是隨機IO了，追加寫的特性就由此被破壞，寫入吞吐量就受到了非常大的影響。另外提一句，RocketMQ就是基於這個原因將所有分區數據都寫到一個commitLog中來規避這個問題。
最後再提一句，我們在說隨機I/O和追加寫的時候，是站在磁盤的角度去說的，跟上層持不持有file的引用或者用什麼流去寫入沒有什麼關係，這也是我之前認知的一個誤區。
另外就是，這個問題只會存在於機械硬盤，雲盤和SSD都不會存在，因爲雲盤走的是帶寬，而SSD是元器件也不需要物理旋轉尋址。
三、集羣故障轉移受影響，導致故障轉移耗時增加
另外一個影響點就是我們日常運維會遇到的問題，故障轉移和集羣狀態恢復時間受到影響。
其中的影響點主要是由於kafka故障轉移時主要依靠controller+zk去實現的，而整個過程的是單線程順序去執行的，整個過程大概分爲：計算新的leader + 更新zk數據 + 通知其他節點將follower變爲leader + 更新元數據。而在這個過着執行完之前，對應受影響的分區都是沒有leader可以去提供讀寫服務的，所以對業務的影響是很大的。
試想我們集羣有幾十萬的分區數，那麼這個過程將非常耗時，達到分鐘級別甚至小時級別。但是kafka在1.1.0版本優化了這個問題，主要優化點三個：zk批量異步寫/批量計算通知/日誌優化。
具體參見胡夕大佬的翻譯文章：【譯】Apache Kafka支持單集羣20萬分區
四、元數據太過龐大，導致更新元數據操作變重
這個問題就是顯而易見的了，當分區數很多的時候，整個集羣的元數據將會變得龐大，一旦集羣狀態變化，整個集羣都會更新元數據，但是由於元數據太過龐大會讓這個更新操作變得非常沉重。
五、日誌清理受影響
kafka的日誌文件操作，是broker有個後臺清理線程去定時檢查執行的，一旦一臺broker上的文件過多，會導致線程處理不過來，無法及時清理掉對應的磁盤文件，從而導致磁盤被打滿等異常情況。