因為硬盤是機械結(jié)構(gòu)捷凄，每次讀寫都會尋址->寫入，其中尋址是一個“機械動作”围来，它是最耗時的跺涤。所以硬盤最討厭隨機I/O，最喜歡順序I/O监透。為了提高讀寫硬盤的速度桶错，Kafka就是使用順序I/O。

而且Linux對于磁盤的讀寫優(yōu)化也比較多胀蛮，包括read-ahead和write-behind院刁，磁盤緩存等。如果在內(nèi)存做這些操作的時候粪狼，一個是JAVA對象的內(nèi)存開銷很大退腥，另一個是隨著堆內(nèi)存數(shù)據(jù)的增多，JAVA的GC時間會變得很長再榄，使用磁盤操作有以下幾個好處：

1狡刘、順序?qū)懭氪疟P順序讀寫速度超過內(nèi)存隨機讀寫

2、順序?qū)懭隞VM的GC效率低困鸥，內(nèi)存占用大嗅蔬。使用磁盤可以避免這一問題

3、順序?qū)懭胂到y(tǒng)冷啟動后窝革，磁盤緩存依然可用购城。下圖就展示了Kafka是如何寫入數(shù)據(jù)的吕座， 每一個Partition其實都是一個文件 虐译，收到消息后Kafka會把數(shù)據(jù)插入到文件末尾（虛框部分）：[圖片上傳失敗...(image-a5aed8-1600830033531)]這種方法有一個缺陷——沒有辦法刪除數(shù)據(jù) ，所以Kafka是不會刪除數(shù)據(jù)的吴趴，它會把所有的數(shù)據(jù)都保留下來漆诽，每個消費者（Consumer）對每個Topic都有一個offset用來表示讀取到了第幾條數(shù)據(jù) 。[圖片上傳失敗...(image-832208-1600830033531)]

兩個消費者：

1、順序?qū)懭隒onsumer1有兩個offset分別對應(yīng)Partition0厢拭、Partition1（假設(shè)每一個Topic一個Partition）兰英；

2、順序?qū)懭隒onsumer2有一個offset對應(yīng)Partition2供鸠。

這個offset是由客戶端SDK負責(zé)保存的畦贸，Kafka的Broker完全無視這個東西的存在；一般情況下SDK會把它保存到Zookeeper里面楞捂，所以需要給Consumer提供zookeeper的地址薄坏。

如果不刪除硬盤肯定會被撐滿，所以Kakfa提供了兩種策略來刪除數(shù)據(jù)：

1寨闹、順序?qū)懭胍皇腔跁r間胶坠。

2、順序?qū)懭攵腔趐artition文件大小繁堡。

具體配置可以參看它的配置文檔

2沈善、Memory Mapped Files

即便是順序?qū)懭胗脖P，硬盤的訪問速度還是不可能追上內(nèi)存椭蹄。所以Kafka的數(shù)據(jù)并不是實時的寫入硬盤 闻牡，它充分利用了現(xiàn)代操作系統(tǒng)分頁存儲來利用內(nèi)存提高I/O效率。

Memory Mapped Files(后面簡稱mmap)也被翻譯成 內(nèi)存映射文件 塑娇，在64位操作系統(tǒng)中一般可以表示20G的數(shù)據(jù)文件澈侠，它的工作原理是直接利用操作系統(tǒng)的Page來實現(xiàn)文件到物理內(nèi)存的直接映射。完成映射之后你對物理內(nèi)存的操作會被同步到硬盤上（操作系統(tǒng)在適當(dāng)?shù)臅r候）埋酬。

通過mmap哨啃，進程像讀寫硬盤一樣讀寫內(nèi)存（當(dāng)然是虛擬機內(nèi)存），也不必關(guān)心內(nèi)存的大小有虛擬內(nèi)存為我們兜底写妥。使用這種方式可以獲取很大的I/O提升拳球，省去了用戶空間到內(nèi)核空間復(fù)制的開銷（調(diào)用文件的read會把數(shù)據(jù)先放到內(nèi)核空間的內(nèi)存中，然后再復(fù)制到用戶空間的內(nèi)存中珍特。）

但也有一個很明顯的缺陷——不可靠祝峻，寫到mmap中的數(shù)據(jù)并沒有被真正的寫到硬盤，操作系統(tǒng)會在程序主動調(diào)用flush的時候才把數(shù)據(jù)真正的寫到硬盤扎筒。

Kafka提供了一個參數(shù)——producer.type來控制是不是主動flush莱找，如果Kafka寫入到mmap之后就立即flush然后再返回Producer叫 同步 (sync)；寫入mmap之后立即返回Producer不調(diào)用flush叫異步 (async)嗜桌。

二奥溺、讀取數(shù)據(jù)Kafka在讀取磁盤時做了哪些優(yōu)化？

1骨宠、基于sendfile實現(xiàn)Zero Copy

傳統(tǒng)模式下浮定，當(dāng)需要對一個文件進行傳輸?shù)臅r候相满，其具體流程細節(jié)如下：

1、基于sendfile實現(xiàn)Zero Copy調(diào)用read函數(shù)桦卒，文件數(shù)據(jù)被copy到內(nèi)核緩沖區(qū)

2立美、read函數(shù)返回，文件數(shù)據(jù)從內(nèi)核緩沖區(qū)copy到用戶緩沖區(qū)

3方灾、write函數(shù)調(diào)用建蹄，將文件數(shù)據(jù)從用戶緩沖區(qū)copy到內(nèi)核與socket相關(guān)的緩沖區(qū)。

4裕偿、數(shù)據(jù)從socket緩沖區(qū)copy到相關(guān)協(xié)議引擎躲撰。

以上細節(jié)是傳統(tǒng)read/write方式進行網(wǎng)絡(luò)文件傳輸?shù)姆绞剑覀兛梢钥吹交鞣眩谶@個過程當(dāng)中拢蛋，文件數(shù)據(jù)實際上是經(jīng)過了四次copy操作：

硬盤—>內(nèi)核buf—>用戶buf—>socket相關(guān)緩沖區(qū)—>協(xié)議引擎

而sendfile系統(tǒng)調(diào)用則提供了一種減少以上多次copy，提升文件傳輸性能的方法蔫巩。在內(nèi)核版本2.1中谆棱，引入了sendfile系統(tǒng)調(diào)用，以簡化網(wǎng)絡(luò)上和兩個本地文件之間的數(shù)據(jù)傳輸圆仔。sendfile的引入不僅減少了數(shù)據(jù)復(fù)制垃瞧，還減少了上下文切換。

sendfile(socket, file, len);

運行流程如下：

1坪郭、sendfile系統(tǒng)調(diào)用个从，文件數(shù)據(jù)被copy至內(nèi)核緩沖區(qū)

2、再從內(nèi)核緩沖區(qū)copy至內(nèi)核中socket相關(guān)的緩沖區(qū)

3歪沃、最后再socket相關(guān)的緩沖區(qū)copy到協(xié)議引擎

相較傳統(tǒng)read/write方式嗦锐，2.1版本內(nèi)核引進的sendfile已經(jīng)減少了內(nèi)核緩沖區(qū)到user緩沖區(qū)，再由user緩沖區(qū)到socket相關(guān)緩沖區(qū)的文件copy沪曙，而在內(nèi)核版本2.4之后奕污，文件描述符結(jié)果被改變，sendfile實現(xiàn)了更簡單的方式液走，再次減少了一次copy操作碳默。

在Apache、Nginx缘眶、lighttpd等web服務(wù)器當(dāng)中嘱根，都有一項sendfile相關(guān)的配置，使用sendfile可以大幅提升文件傳輸性能巷懈。

Kafka把所有的消息都存放在一個一個的文件中该抒，當(dāng)消費者需要數(shù)據(jù)的時候Kafka直接把文件發(fā)送給消費者，配合mmap作為文件讀寫方式砸喻，直接把它傳給sendfile柔逼。

2、批量壓縮

在很多情況下割岛，系統(tǒng)的瓶頸不是CPU或磁盤愉适，而是網(wǎng)絡(luò)IO，對于需要在廣域網(wǎng)上的數(shù)據(jù)中心之間發(fā)送消息的數(shù)據(jù)流水線尤其如此癣漆。進行數(shù)據(jù)壓縮會消耗少量的CPU資源,不過對于kafka而言,網(wǎng)絡(luò)IO更應(yīng)該需要考慮维咸。

1、如果每個消息都壓縮惠爽，但是壓縮率相對很低癌蓖，所以Kafka使用了批量壓縮，即將多個消息一起壓縮而不是單個消息壓縮

2婚肆、Kafka允許使用遞歸的消息集合租副，批量的消息可以通過壓縮的形式傳輸并且在日志中也可以保持壓縮格式，直到被消費者解壓縮

3较性、Kafka支持多種壓縮協(xié)議用僧，包括Gzip和Snappy壓縮協(xié)議

三、總結(jié)

Kafka速度的秘訣在于赞咙，它把所有的消息都變成一個批量的文件责循，并且進行合理的批量壓縮，減少網(wǎng)絡(luò)IO損耗攀操，通過mmap提高I/O速度院仿，寫入數(shù)據(jù)的時候由于單個Partion是末尾添加所以速度最優(yōu)；讀取數(shù)據(jù)的時候配合sendfile直接暴力輸出速和。