Kafka為什麼速度快

磁碟讀寫的快慢取決於你怎麼使用它，也就是順序讀寫或者隨機讀寫。在順序讀寫的情況下，磁碟的順序讀寫速度和記憶體持平。

如果不刪除硬碟肯定會被撐滿，所以kakfa提供了兩種策略來刪除日誌[^ log.cleanup.policy配置]：

[1] 基於時間

檢查當前日誌檔案中是否有保留時間超過設定的閾值來尋找可刪除的日誌分段檔案集合。

過期時間可以通過如上三項配置，其配置優先順序從上到下依次降低。

[2] 基於日誌大小

日誌刪除任務檢查當前日誌的大小是否超過設定的閾值[^ log.retention.bytes 配置]來尋找可刪除的日誌分段的檔案集合。

[3] 基於日誌起始偏移量

即便是順序寫入硬碟，硬碟的訪問速度還是不可能追上記憶體。所以kafka的資料並不是實時的寫入硬碟，它充分利用了現代作業系統分頁儲存來利用記憶體提高i/o效率。

完成對映之後你對物理記憶體的操作會被同步到硬碟上（作業系統在適當的時候）。

通過mmap，程序像讀寫硬碟一樣讀寫記憶體（當然是虛擬機器記憶體），也不必關心記憶體的大小有虛擬記憶體為我們兜底。

使用這種方式可以獲取很大的i/o提公升，省去了使用者空間到核心空間複製的開銷（呼叫檔案的read會把資料先放到核心空間的記憶體中，然後再複製到使用者空間的記憶體中。）

但也有乙個很明顯的缺陷——不可靠寫到mmap中的資料並沒有被真正的寫到硬碟，作業系統會在程式主動呼叫flush的時候才把資料真正的寫到硬碟。

kafka提供了乙個引數——producer.type來控制是不是主動flush，如果kafka寫入到mmap之後就立即flush然後再返回producer叫同步 (sync)；寫入mmap之後立即返回producer不呼叫flush叫非同步 (async)

傳統模式下，當需要對乙個檔案進行傳輸的時候，其具體流程細節如下：

基於sendfile實現zero copy呼叫read函式，檔案資料被copy到核心緩衝區

read函式返回，檔案資料從核心緩衝區copy到使用者緩衝區

write函式呼叫，將檔案資料從使用者緩衝區copy到核心與socket相關的緩衝區。

資料從socket緩衝區copy到相關協議引擎。

以上細節是傳統read/write方式進行網路檔案傳輸的方式，我們可以看到，在這個過程當中，檔案資料實際上是經過了四次copy操作：

硬碟—>核心buf—>使用者buf—>socket相關緩衝區—>協議引擎

而sendfile系統呼叫則提供了一種減少以上多次copy，提公升檔案傳輸效能的方法。

在核心版本2.1中，引入了sendfile系統呼叫，以簡化網路上和兩個本地檔案之間的資料傳輸。sendfile的引入不僅減少了資料複製，還減少了上下文切換。

sendfile(socket, file, len)
;

執行流程如下：sendfile系統呼叫，檔案資料被copy至核心緩衝區

再從核心緩衝區copy至核心中socket相關的緩衝區

最後再socket相關的緩衝區copy到協議引擎

相較傳統read/write方式，2.1版本核心引進的sendfile已經減少了核心緩衝區到user緩衝區，再由user緩衝區到socket相關緩衝區的檔案copy，而在核心版本2.4之後，檔案描述符結果被改變，sendfile實現了更簡單的方式，再次減少了一次copy操作。

在apache、nginx、lighttpd等web伺服器當中，都有一項sendfile相關的配置，使用sendfile可以大幅提公升檔案傳輸效能。

kafka把所有的訊息都存放在乙個乙個的檔案中，當消費者需要資料的時候kafka直接把檔案傳送給消費者，配合mmap作為檔案讀寫方式，直接把它傳給sendfile。

在很多情況下，系統的瓶頸不是cpu或磁碟，而是網路io，對於需要在廣域網上的資料中心之間傳送訊息的資料流水線尤其如此。進行資料壓縮會消耗少量的cpu資源,不過對於kafka而言,網路io更應該需要考慮。

如果每個訊息都壓縮，但是壓縮率相對很低，所以kafka使用了批量壓縮，即將多個訊息一起壓縮而不是單個訊息壓縮

kafka允許使用遞迴的訊息集合，批量的訊息可以通過壓縮的形式傳輸並且在日誌中也可以保持壓縮格式，直到被消費者解壓縮