Kafka寫入為什么那么快，相信很多沒有經(jīng)驗(yàn)的人對此束手無策，為此本文總結(jié)了問題出現(xiàn)的原因和解決方法，通過這篇文章希望你能解決這個(gè)問題。

成都創(chuàng)新互聯(lián)公司專注于鐘樓網(wǎng)站建設(shè)服務(wù)及定制，我們擁有豐富的企業(yè)做網(wǎng)站經(jīng)驗(yàn)。 熱誠為您提供鐘樓營銷型網(wǎng)站建設(shè)，鐘樓網(wǎng)站制作、鐘樓網(wǎng)頁設(shè)計(jì)、鐘樓網(wǎng)站官網(wǎng)定制、微信平臺(tái)小程序開發(fā)服務(wù)，打造鐘樓網(wǎng)絡(luò)公司原創(chuàng)品牌,更為您提供鐘樓網(wǎng)站排名全網(wǎng)營銷落地服務(wù)。

Kafka 的消息是保存或緩存在磁盤上的，一般認(rèn)為在磁盤上讀寫數(shù)據(jù)是會(huì)降低性能的，因?yàn)閷ぶ窌?huì)比較消耗時(shí)間，但是實(shí)際上，Kafka  的特性之一就是高吞吐率。

即使是普通的服務(wù)器，Kafka 也可以輕松支持每秒最高的寫入請求，超過了大部分的消息中間件，這種特性也使得 Kafka  在日志處理等海量數(shù)據(jù)場景廣泛應(yīng)用。

下面從數(shù)據(jù)寫入和讀取兩方面分析，為什么 Kafka 速度這么快。

數(shù)據(jù)寫入

Kafka 會(huì)把收到的消息都寫入到硬盤中，它絕對不會(huì)丟失數(shù)據(jù)。為了優(yōu)化寫入速度 Kafka 采用了兩個(gè)技術(shù)， 順序?qū)懭牒?MMFile(Memory  Mapped File)。

順序?qū)懭?/strong>

磁盤讀寫的快慢取決于你怎么使用它，也就是順序讀寫或者隨機(jī)讀寫。在順序讀寫的情況下，磁盤的順序讀寫速度和內(nèi)存持平。

因?yàn)橛脖P是機(jī)械結(jié)構(gòu)，每次讀寫都會(huì)尋址->寫入，其中尋址是一個(gè)“機(jī)械動(dòng)作”，它是最耗時(shí)的。

所以硬盤最討厭隨機(jī) I/O，最喜歡順序 I/O。為了提高讀寫硬盤的速度，Kafka 就是使用順序 I/O。

而且 Linux 對于磁盤的讀寫優(yōu)化也比較多，包括 read-ahead 和 write-behind，磁盤緩存等。

如果在內(nèi)存做這些操作的時(shí)候，一個(gè)是 Java 對象的內(nèi)存開銷很大，另一個(gè)是隨著堆內(nèi)存數(shù)據(jù)的增多，Java 的 GC 時(shí)間會(huì)變得很長。

使用磁盤操作有以下幾個(gè)好處：

• 磁盤順序讀寫速度超過內(nèi)存隨機(jī)讀寫。

• JVM 的 GC 效率低，內(nèi)存占用大。使用磁盤可以避免這一問題。

• 系統(tǒng)冷啟動(dòng)后，磁盤緩存依然可用。

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

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

兩個(gè)消費(fèi)者：

• Consumer1 有兩個(gè) Offset 分別對應(yīng) Partition0、Partition1(假設(shè)每一個(gè) Topic 一個(gè)  Partition)。

• Consumer2 有一個(gè) Offset 對應(yīng) Partition2。

這個(gè) Offset 是由客戶端 SDK 負(fù)責(zé)保存的，Kafka 的 Broker 完全無視這個(gè)東西的存在。

一般情況下 SDK 會(huì)把它保存到 Zookeeper 里面，所以需要給 Consumer 提供 Zookeeper 的地址。

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

• 基于時(shí)間

• 基于 Partition 文件大小

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

Memory Mapped Files

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

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

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

通過 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)存中，然后再復(fù)制到用戶空間的內(nèi)存中)

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

Kafka 提供了一個(gè)參數(shù) producer.type 來控制是不是主動(dòng) Flush：

• 如果 Kafka 寫入到 mmap 之后就立即 Flush，然后再返回 Producer 叫同步 (Sync)。

• 如果 Kafka 寫入 mmap 之后立即返回 Producer 不調(diào)用 Flush 叫異步 (Async)。

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

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

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

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

• 調(diào)用 Read 函數(shù)，文件數(shù)據(jù)被 Copy 到內(nèi)核緩沖區(qū)。

• Read 函數(shù)返回，文件數(shù)據(jù)從內(nèi)核緩沖區(qū) Copy 到用戶緩沖區(qū)

• Write 函數(shù)調(diào)用，將文件數(shù)據(jù)從用戶緩沖區(qū) Copy 到內(nèi)核與 Socket 相關(guān)的緩沖區(qū)。

• 數(shù)據(jù)從 Socket 緩沖區(qū) Copy 到相關(guān)協(xié)議引擎。

以上細(xì)節(jié)是傳統(tǒng) Read/Write 方式進(jìn)行網(wǎng)絡(luò)文件傳輸?shù)姆绞?，我們可以看到，在這個(gè)過程當(dāng)中，文件數(shù)據(jù)實(shí)際上是經(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ò)上和兩個(gè)本地文件之間的數(shù)據(jù)傳輸。

Sendfile 的引入不僅減少了數(shù)據(jù)復(fù)制，還減少了上下文切換。

sendfile(socket, file, len);

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

• Sendfile 系統(tǒng)調(diào)用，文件數(shù)據(jù)被 Copy 至內(nèi)核緩沖區(qū)。

• 再從內(nèi)核緩沖區(qū) Copy 至內(nèi)核中 Socket 相關(guān)的緩沖區(qū)。

• ***再 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)了更簡單的方式，再次減少了一次 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，對于需要在廣域網(wǎng)上的數(shù)據(jù)中心之間發(fā)送消息的數(shù)據(jù)流水線尤其如此。

進(jìn)行數(shù)據(jù)壓縮會(huì)消耗少量的 CPU 資源，不過對于 Kafka 而言，網(wǎng)絡(luò) IO 更應(yīng)該考慮：

• 因?yàn)槊總€(gè)消息都壓縮，但是壓縮率相對很低，所以 Kafka 使用了批量壓縮，即將多個(gè)消息一起壓縮而不是單個(gè)消息壓縮。

• Kafka 允許使用遞歸的消息集合，批量的消息可以通過壓縮的形式傳輸并且在日志中也可以保持壓縮格式，直到被消費(fèi)者解壓縮。

• Kafka 支持多種壓縮協(xié)議，包括 Gzip 和 Snappy 壓縮協(xié)議。

Kafka 速度的秘訣在于它把所有的消息都變成一個(gè)批量的文件，并且進(jìn)行合理的批量壓縮，減少網(wǎng)絡(luò) IO 損耗，通過 mmap 提高 I/O 速度。

寫入數(shù)據(jù)的時(shí)候由于單個(gè) Partion 是末尾添加，所以速度***;讀取數(shù)據(jù)的時(shí)候配合 Sendfile 直接暴力輸出。

看完上述內(nèi)容，你們掌握Kafka寫入為什么那么快的方法了嗎？如果還想學(xué)到更多技能或想了解更多相關(guān)內(nèi)容，歡迎關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道，感謝各位的閱讀！