11.23 apache kafka吞吐量高的原因分析

為什麼kafka能夠承受那麼高的吞吐量?

順序讀寫

kafka的消息是不斷追加到文件中的,這個特性使kafka可以充分利用磁盤的順序讀寫性能

順序讀寫不需要硬盤磁頭的尋道時間,只需很少的扇區旋轉時間,所以速度遠快於隨機讀寫

生產者負責寫入數據,Kafka會將消息持久化到磁盤,保證不會丟失數據,Kafka採用了倆個技術提高寫入的速度。

1.順序寫入:在大學的計算機組成(劃重點)裡我們學過,硬盤是機械結構,需要指針尋址找到存儲數據的位置,所以,如果是隨機IO,磁盤會進行頻繁的尋址,導致寫入速度下降。Kafka使用了順序IO提高了磁盤的寫入速度,Kafka會將數據順序插入到文件末尾,消費者端通過控制偏移量來讀取消息,這樣做會導致數據無法刪除,時間一長,磁盤空間會滿,kafka提供了2種策略來刪除數據:基於時間刪除和基於partition文件的大小刪除。

2.Memory Mapped Files:這個和Java NIO中的內存映射基本相同,在大學的計算機原理裡我們學過(劃重點),mmf直接利用操作系統的Page來實現文件到物理內存的映射,完成之後對物理內存的操作會直接同步到硬盤。mmf通過內存映射的方式大大提高了IO速率,省去了用戶空間到內核空間的複製。它的缺點顯而易見--不可靠,當發生宕機而數據未同步到硬盤時,數據會丟失,Kafka提供了produce.type參數來控制是否主動的進行刷新,如果kafka寫入到mmp後立即flush再返回給生產者則為同步模式,反之為異步模式。

什麼是內存映射文件


內存映射文件,是由一個文件到一塊內存的映射,可以理解為將一個文件映射到進程地址,然後可以通過操作內存來訪問文件數據。說白了就是使用虛擬內存將磁盤的文件數據加載到虛擬內存的內存頁,然後就可以直接操作內存頁數據。
我們讀寫一個文件使用read()和write()方法,這兩個方法是調用系統底層接口來傳輸數據,因為內核空間的文件頁和用戶空間的緩衝區沒有一一對應,所以讀寫數據時會在內核空間和用戶空間之間進行數據拷貝,在操作大量文件數據時會導致性能很低,使用內存映射文件可以非常高效的操作大量文件數據。
通過內存映射機制操作文件比使用常規方法和使用FileChannel讀寫高效的多。
內存映射文件使用文件系統建立從用戶空間到可用文件系統頁的虛擬內存映射,這樣做有以下好處:

  • 用戶進程把文件數據當內存數據,無需調用read()或write()
  • 當用戶進程接觸到映射內存空間,會自動產生頁錯誤,從而將文件數據從磁盤讀到內存;若用戶空間進程修改了內存頁數據,相關頁會自動標記並刷新到磁盤,文件被更新
  • 操作系統的虛擬內存對內存頁進行高速緩存,自動根據系統負載進行內存管理
  • 用戶空間和內核空間的數據總是一一對應,無需執行緩衝區拷貝
  • 大數據的文件使用映射,無需消耗大量內存即可進行數據拷貝

內存映射文件能讓你創建和修改那些因為太大而無法放入內存的文件。 (乾貨——內存映射文件的作用)

  • 有了內存映射文件,你就可以認為文件已經全部讀進了內存,然後把它當成一個非常大的數組來訪問。這種解決辦法能大大簡化修改文件的代碼。
    fileChannel.map(FileChannel.MapMode mode, long position, long size)將此通道的文件區域直接映射到內存中。
  • Attention)注意,你必須指明,它是從文件的哪個位置開始映射的,映射的範圍又有多大;也就是說,它還可以映射一個大文件的某個小片斷。

MappedByteBuffer是ByteBuffer的子類:因此它具備了ByteBuffer的所有方法,但新添了force()將緩衝區的內容強制刷新到存儲設備中去、load()將存儲設備中的數據加載到內存中、isLoaded()位置內存中的數據是否與存儲設置上同步。這裡只簡單地演示了一下put()和get()方法,除此之外,你還可以使用asCharBuffer( )之類的方法得到相應基本類型數據的緩衝視圖後,可以方便的讀寫基本類型數據。

apache kafka吞吐量高的原因分析

儘管映射寫似乎要用到FileOutputStream,但是映射文件中的所有輸出 必須使用RandomAccessFile。

  • 但如果只需要讀時可以使用FileInputStream,寫映射文件時一定要使用隨機訪問文件,可能寫時要讀的原因吧。(乾貨——只需要讀時可以使用FileInputStream,寫映射文件時一定要使用隨機訪問文件)

該程序創建了一個128Mb的文件,如果一次性讀到內存可能導致內存溢出,但這裡訪問好像只是一瞬間的事,這是因為,真正調入內存的只是其中的一小部分,其餘部分則被放在交換文件上。這樣你就可以很方便地修改超大型的文件了(最大可以到2 GB)。

  • Attention 注意,Java是調用操作系統的”文件映射機制”來提升性能的。

零拷貝?

在這之前先來了解一下零拷貝:平時從服務器讀取靜態文件時,服務器先將文件從複製到內核空間,再複製到用戶空間,最後再複製到內核空間並通過網卡發送出去,而零拷貝則是直接從內核到內核再到網卡,省去了用戶空間的複製。

Kafka把所有的消息存放到一個文件中,當消費者需要數據的時候直接將文件發送給消費者,比如10W的消息共10M,全部發送給消費者,10M的消息在內網中傳輸是非常快的,假如需要1s,那麼kafka的tps就是10w。Zero copy對應的是Linux中sendfile函數,這個函數會接受一個offsize來確定從哪裡開始讀取。現實中,不可能將整個文件全部發給消費者,他通過消費者傳遞過來的偏移量來使用零拷貝讀取指定內容的數據返回給消費者。

在Linux kernel2.2 之後出現了一種叫做"零拷貝(zero-copy)"系統調用機制,就是跳過“用戶緩衝區”的拷貝,建立一個磁盤空間和內存的直接映射,數據不再複製到“用戶態緩衝區”,系統上下文切換減少為2次,可以提升一倍的性能。

什麼是0拷貝

在寫一個服務端程序時(Web Server或者文件服務器),文件下載是一個基本功能。這時候服務端的任務是:將服務端主機磁盤中的文件不做修改地從已連接的socket發出去,我們通常用下面的代碼完成:

while((n = read(diskfd, buf, BUF_SIZE)) > 0)
write(sockfd, buf , n);

基本操作就是循環的從磁盤讀入文件內容到緩衝區,再將緩衝區的內容發送到socket。但是由於Linux的I/O操作默認是緩衝I/O。這裡面主要使用的也就是read和write兩個系統調用,我們並不知道操作系統在其中做了什麼。實際上在以上I/O操作中,發生了多次的數據拷貝。

當應用程序訪問某塊數據時,操作系統首先會檢查,是不是最近訪問過此文件,文件內容是否緩存在內核緩衝區,如果是,操作系統則直接根據read系統調用提供的buf地址,將內核緩衝區的內容拷貝到buf所指定的用戶空間緩衝區中去。如果不是,操作系統則首先將磁盤上的數據拷貝的內核緩衝區,這一步目前主要依靠DMA來傳輸,然後再把內核緩衝區上的內容拷貝到用戶緩衝區中。
接下來,write系統調用再把用戶緩衝區的內容拷貝到網絡堆棧相關的內核緩衝區中,最後socket再把內核緩衝區的內容發送到網卡上。
說了這麼多,不如看圖清楚:

apache kafka吞吐量高的原因分析

數據拷貝


從上圖中可以看出,共產生了四次數據拷貝,即使使用了DMA來處理了與硬件的通訊,CPU仍然需要處理兩次數據拷貝,與此同時,在用戶態與內核態也發生了多次上下文切換,無疑也加重了CPU負擔。

在此過程中,我們沒有對文件內容做任何修改,那麼在內核空間和用戶空間來回拷貝數據無疑就是一種浪費,而零拷貝主要就是為了解決這種低效性。

什麼是零拷貝技術(zero-copy)?

零拷貝主要的任務就是避免CPU將數據從一塊存儲拷貝到另外一塊存儲,主要就是利用各種零拷貝技術,避免讓CPU做大量的數據拷貝任務,減少不必要的拷貝,或者讓別的組件來做這一類簡單的數據傳輸任務,讓CPU解脫出來專注於別的任務。這樣就可以讓系統資源的利用更加有效。

我們繼續回到引文中的例子,我們如何減少數據拷貝的次數呢?一個很明顯的著力點就是減少數據在內核空間和用戶空間來回拷貝,這也引入了零拷貝的一個類型:

讓數據傳輸不需要經過user space

使用mmap

我們減少拷貝次數的一種方法是調用mmap()來代替read調用:

buf = mmap(diskfd, len);
write(sockfd, buf, len);

應用程序調用mmap(),磁盤上的數據會通過DMA被拷貝的內核緩衝區,接著操作系統會把這段內核緩衝區與應用程序共享,這樣就不需要把內核緩衝區的內容往用戶空間拷貝。應用程序再調用write(),操作系統直接將內核緩衝區的內容拷貝到socket緩衝區中,這一切都發生在內核態,最後,socket緩衝區再把數據發到網卡去。
同樣的,看圖很簡單:

apache kafka吞吐量高的原因分析

mmap


使用mmap替代read很明顯減少了一次拷貝,當拷貝數據量很大時,無疑提升了效率。但是使用mmap是有代價的。當你使用mmap時,你可能會遇到一些隱藏的陷阱。例如,當你的程序map了一個文件,但是當這個文件被另一個進程截斷(truncate)時, write系統調用會因為訪問非法地址而被SIGBUS信號終止。SIGBUS信號默認會殺死你的進程併產生一個coredump,如果你的服務器這樣被中止了,那會產生一筆損失。

通常我們使用以下解決方案避免這種問題:

  1. 為SIGBUS信號建立信號處理程序
    當遇到SIGBUS信號時,信號處理程序簡單地返回,write系統調用在被中斷之前會返回已經寫入的字節數,並且errno會被設置成success,但是這是一種糟糕的處理辦法,因為你並沒有解決問題的實質核心。
  2. 使用文件租借鎖
    通常我們使用這種方法,在文件描述符上使用租借鎖,我們為文件向內核申請一個租借鎖,當其它進程想要截斷這個文件時,內核會向我們發送一個實時的RT_SIGNAL_LEASE信號,告訴我們內核正在破壞你加持在文件上的讀寫鎖。這樣在程序訪問非法內存並且被SIGBUS殺死之前,你的write系統調用會被中斷。write會返回已經寫入的字節數,並且置errno為success。

我們應該在mmap文件之前加鎖,並且在操作完文件後解鎖:

if(fcntl(diskfd, F_SETSIG, RT_SIGNAL_LEASE) == -1) {
perror("kernel lease set signal");
return -1;
}
/* l_type can be F_RDLCK F_WRLCK 加鎖*/
/* l_type can be F_UNLCK 解鎖*/
if(fcntl(diskfd, F_SETLEASE, l_type)){
perror("kernel lease set type");
return -1;
}

使用sendfile

從2.1版內核開始,Linux引入了sendfile來簡化操作:

#include
ssize_t sendfile(int out_fd, int in_fd, off_t *offset, size_t count);

系統調用sendfile()在代表輸入文件的描述符in_fd和代表輸出文件的描述符out_fd之間傳送文件內容(字節)。描述符out_fd必須指向一個套接字,而in_fd指向的文件必須是可以mmap的。這些侷限限制了sendfile的使用,使sendfile只能將數據從文件傳遞到套接字上,反之則不行。
使用sendfile不僅減少了數據拷貝的次數,還減少了上下文切換,數據傳送始終只發生在kernel space。

apache kafka吞吐量高的原因分析

sendfile系統調用過程

在我們調用sendfile時,如果有其它進程截斷了文件會發生什麼呢?假設我們沒有設置任何信號處理程序,sendfile調用僅僅返回它在被中斷之前已經傳輸的字節數,errno會被置為success。如果我們在調用sendfile之前給文件加了鎖,sendfile的行為仍然和之前相同,我們還會收到RT_SIGNAL_LEASE的信號。

目前為止,我們已經減少了數據拷貝的次數了,但是仍然存在一次拷貝,就是頁緩存到socket緩存的拷貝。那麼能不能把這個拷貝也省略呢?

藉助於硬件上的幫助,我們是可以辦到的。之前我們是把頁緩存的數據拷貝到socket緩存中,實際上,我們僅僅需要把緩衝區描述符傳到socket緩衝區,再把數據長度傳過去,這樣DMA控制器直接將頁緩存中的數據打包發送到網絡中就可以了。

總結一下,sendfile系統調用利用DMA引擎將文件內容拷貝到內核緩衝區去,然後將帶有文件位置和長度信息的緩衝區描述符添加socket緩衝區去,這一步不會將內核中的數據拷貝到socket緩衝區中,DMA引擎會將內核緩衝區的數據拷貝到協議引擎中去,避免了最後一次拷貝。

apache kafka吞吐量高的原因分析

帶DMA的sendfile

不過這一種收集拷貝功能是需要硬件以及驅動程序支持的。

使用splice#####

sendfile只適用於將數據從文件拷貝到套接字上,限定了它的使用範圍。Linux在2.6.17版本引入splice系統調用,用於在兩個文件描述符中移動數據:

#define _GNU_SOURCE /* See feature_test_macros(7) */
#include <fcntl.h>
ssize_t splice(int fd_in, loff_t *off_in, int fd_out, loff_t *off_out, size_t len, unsigned int flags);
/<fcntl.h>

splice調用在兩個文件描述符之間移動數據,而不需要數據在內核空間和用戶空間來回拷貝。他從fd_in拷貝len長度的數據到fd_out,但是有一方必須是管道設備,這也是目前splice的一些侷限性。flags參數有以下幾種取值:

  • SPLICE_F_MOVE :嘗試去移動數據而不是拷貝數據。這僅僅是對內核的一個小提示:如果內核不能從pipe移動數據或者pipe的緩存不是一個整頁面,仍然需要拷貝數據。Linux最初的實現有些問題,所以從2.6.21開始這個選項不起作用,後面的Linux版本應該會實現。
  • ** SPLICE_F_NONBLOCK** :splice 操作不會被阻塞。然而,如果文件描述符沒有被設置為不可被阻塞方式的 I/O ,那麼調用 splice 有可能仍然被阻塞。
  • ** SPLICE_F_MORE**: 後面的splice調用會有更多的數據。

splice調用利用了Linux提出的管道緩衝區機制, 所以至少一個描述符要為管道。

分區

kafka中的topic中的內容可以被分為多分partition存在,每個partition又分為多個段segment,所以每次操作都是針對一小部分做操作,很輕便,並且增加並行操作的能力

apache kafka吞吐量高的原因分析

批量發送

kafka允許進行批量發送消息,producter發送消息的時候,可以將消息緩存在本地,等到了固定條件發送到kafka

  1. 等消息條數到固定條數
  2. 一段時間發送一次


分享到:


相關文章: