下圖就展示了Kafka是如何寫入數(shù)據(jù)的， 每一個(gè)Partition其實(shí)都是一個(gè)文件 ，收到消息后Kafka會(huì)把數(shù)據(jù)插入到文件末尾(虛框部分)：

這種方法有一個(gè)缺陷——沒(méi)有辦法刪除數(shù)據(jù) ，所以Kafka是不會(huì)刪除數(shù)據(jù)的，它會(huì)把所有的數(shù)據(jù)都保留下來(lái)，每個(gè)消費(fèi)者(Consumer)對(duì)每個(gè)Topic都有一個(gè)offset用來(lái)表示讀取到了第幾條數(shù)據(jù) 。 兩個(gè)消費(fèi)者：

1. 順序?qū)懭隒onsumer1有兩個(gè)offset分別對(duì)應(yīng)Partition0、Partition1(假設(shè)每一個(gè)Topic一個(gè)Partition);
2. 順序?qū)懭隒onsumer2有一個(gè)offset對(duì)應(yīng)Partition2。 這個(gè)offset是由客戶端SDK負(fù)責(zé)保存的，Kafka的Broker完全無(wú)視這個(gè)東西的存在; 一般情況下SDK會(huì)把它保存到Zookeeper里面，所以需要給Consumer提供zookeeper的地址。

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

1. 順序?qū)懭胍皇腔跁r(shí)間。
2. 順序?qū)懭攵腔趐artition文件大小。

Memory Mapped Files

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

Memory Mapped Files(后面簡(jiǎn)稱mmap)也被翻譯成 內(nèi)存映射文件 ，在64位操作系統(tǒng)中一般可以表示20G的數(shù)據(jù)文件，它的工作原理是直接利用操作系統(tǒng)的Page來(lái)實(shí)現(xiàn)文件到物理內(nèi)存的直接映射。

完成映射之后你對(duì)物理內(nèi)存的操作會(huì)被同步到硬盤上(操作系統(tǒng)在適當(dāng)?shù)臅r(shí)候)。

通過(guò)mmap，進(jìn)程像讀寫硬盤一樣讀寫內(nèi)存(當(dāng)然是虛擬機(jī)內(nèi)存)，也不必關(guān)心內(nèi)存的大小有虛擬內(nèi)存為我們兜底。

使用這種方式可以獲取很大的I/O提升，省去了用戶空間到內(nèi)核空間復(fù)制的開銷(調(diào)用文件的read會(huì)把數(shù)據(jù)先放到內(nèi)核空間的內(nèi)存中，然后再?gòu)?fù)制到用戶空間的內(nèi)存中。) 但也有一個(gè)很明顯的缺陷——不可靠，寫到mmap中的數(shù)據(jù)并沒(méi)有被真正的寫到硬盤，操作系統(tǒng)會(huì)在程序主動(dòng)調(diào)用flush的時(shí)候才把數(shù)據(jù)真正的寫到硬盤。

Kafka提供了一個(gè)參數(shù)——producer.type來(lái)控制是不是主動(dòng)flush，如果Kafka寫入到mmap之后就立即flush然后再返回Producer叫 同步 (sync);寫入mmap之后立即返回Producer不調(diào)用flush叫異步 (async)。

二、讀取數(shù)據(jù)

Kafka在讀取磁盤時(shí)做了哪些優(yōu)化?

基于sendfile實(shí)現(xiàn)Zero Copy

傳統(tǒng)模式下，當(dāng)需要對(duì)一個(gè)文件進(jìn)行傳輸?shù)臅r(shí)候，其具體流程細(xì)節(jié)如下：

1. 基于sendfile實(shí)現(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é)議引擎。

以上細(xì)節(jié)是傳統(tǒng)read/write方式進(jìn)行網(wǎng)絡(luò)文件傳輸?shù)姆绞?，我們可以看到，在這個(gè)過(guò)程當(dāng)中，文件數(shù)據(jù)實(shí)際上是經(jīng)過(guò)了四次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)用，以簡(jiǎn)化網(wǎng)絡(luò)上和兩個(gè)本地文件之間的數(shù)據(jù)傳輸。sendfile的引入不僅減少了數(shù)據(jù)復(fù)制，還減少了上下文切換。 sendfile(socket, file, len);

運(yùn)行流程如下：

1. sendfile系統(tǒng)調(diào)用，文件數(shù)據(jù)被copy至內(nèi)核緩沖區(qū)
2. 再?gòu)膬?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)核引進(jìn)的sendfile已經(jīng)減少了內(nèi)核緩沖區(qū)到user緩沖區(qū)，再由user緩沖區(qū)到socket相關(guān)緩沖區(qū)的文件copy，而在內(nèi)核版本2.4之后，文件描述符結(jié)果被改變，sendfile實(shí)現(xiàn)了更簡(jiǎn)單的方式，再次減少了一次copy操作。

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

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

批量壓縮

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

1. 如果每個(gè)消息都?jí)嚎s，但是壓縮率相對(duì)很低，所以Kafka使用了批量壓縮，即將多個(gè)消息一起壓縮而不是單個(gè)消息壓縮
2. Kafka允許使用遞歸的消息集合，批量的消息可以通過(guò)壓縮的形式傳輸并且在日志中也可以保持壓縮格式，直到被消費(fèi)者解壓縮
3. Kafka支持多種壓縮協(xié)議，包括Gzip和Snappy壓縮協(xié)議

三、總結(jié)

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