kafka之六：爲何Kafka那麼快

轉自：  http://mp.weixin.qq.com/s?__biz=MzIxMjAzMDA1MQ==&mid=2648945468&idx=1&sn=b622788361b384e152080b60e5ea69a7#rd

　　網上有不少Kafka的測試文章，測試結果一般都是「吊打」其餘MQ。感慨它的牛B之餘我以爲必要仔細分析一下它如此快速的緣由。這篇文章不一樣於其餘介紹Kafka使用或者技術實現的文章，我會重點解釋——爲何真快。（固然不是由於它用了Scala！！！！）

生產者（寫入數據）

生產者（producer）是負責向Kafka提交數據的，咱們先分析這一部分。

Kafka會把收到的消息都寫入到硬盤中，它絕對不會丟失數據。爲了優化寫入速度Kafak採用了兩個技術， 順序寫入 和 MMFile 。

順序寫入

由於硬盤是機械結構，每次讀寫都會尋址->寫入，其中尋址是一個「機械動做」，它是最耗時的。因此硬盤最「討厭」隨機I/O，最喜歡順序I/O。爲了提升讀寫硬盤的速度，Kafka就是使用順序I/O。

上圖就展現了Kafka是如何寫入數據的， 每個Partition其實都是一個文件 ，收到消息後Kafka會把數據插入到文件末尾（虛框部分）。

這種方法有一個缺陷—— 沒有辦法刪除數據 ，因此Kafka是不會刪除數據的，它會把全部的數據都保留下來，每一個消費者（Consumer）對每一個Topic都有一個offset用來表示 讀取到了第幾條數據 。

上圖中有兩個消費者，Consumer1有兩個offset分別對應Partition0、Partition1（假設每個Topic一個Partition）；Consumer2有一個offset對應Partition2。這個offset是由客戶端SDK負責保存的，Kafka的Broker徹底無視這個東西的存在；通常狀況下SDK會把它保存到zookeeper裏面。(因此須要給Consumer提供zookeeper的地址)。

若是不刪除硬盤確定會被撐滿，因此Kakfa提供了兩種策略來刪除數據。一是基於時間，二是基於partition文件大小。具體配置能夠參看它的配置文檔。

Memory Mapped Files

即使是順序寫入硬盤，硬盤的訪問速度仍是不可能追上內存。因此Kafka的數據並 不是實時的寫入硬盤 ，它充分利用了現代操做系統 分頁存儲 來利用內存提升I/O效率。

Memory Mapped Files(後面簡稱mmap)也被翻譯成 內存映射文件 ，在64位操做系統中通常能夠表示20G的數據文件，它的工做原理是直接利用操做系統的Page來實現文件到物理內存的直接映射。完成映射以後你對物理內存的操做會被同步到硬盤上（操做系統在適當的時候）。

經過mmap，進程像讀寫硬盤同樣讀寫內存（固然是虛擬機內存），也沒必要關心內存的大小有虛擬內存爲咱們兜底。

使用這種方式能夠獲取很大的I/O提高， 省去了用戶空間到內核空間 複製的開銷（調用文件的read會把數據先放到內核空間的內存中，而後再複製到用戶空間的內存中。）也有一個很明顯的缺陷——不可靠， 寫到mmap中的數據並無被真正的寫到硬盤，操做系統會在程序主動調用flush的時候才把數據真正的寫到硬盤。 Kafka提供了一個參數——producer.type來控制是否是主動flush，若是Kafka寫入到mmap以後就當即flush而後再返回Producer叫 同步 (sync)；寫入mmap以後當即返回Producer不調用flush叫 異步 (async)。

mmap實際上是Linux中的一個函數就是用來實現內存映射的，謝謝Java NIO，它給我提供了一個mappedbytebuffer類能夠用來實現內存映射（因此是沾了Java的光才能夠如此神速和Scala不要緊！！）

消費者（讀取數據）

Kafka使用磁盤文件還想快速？這是我看到Kafka以後的第一個疑問，ZeroMQ徹底沒有任何服務器節點，也不會使用硬盤，按照道理說它應該比Kafka快。但是實際測試下來它的速度仍是被Kafka「吊打」。 「一個用硬盤的比用內存的快」，這絕對違反常識；若是這種事情發生說明——它做弊了。

沒錯，Kafka「做弊」。不管是 順序寫入 仍是 mmap 其實都是做弊的準備工做。

如何提升Web Server靜態文件的速度

仔細想一下，一個Web Server傳送一個靜態文件，如何優化？答案是zero copy。傳統模式下咱們從硬盤讀取一個文件是這樣的

先複製到內核空間（read是系統調用，放到了DMA，因此用內核空間），而後複製到用戶空間(1,2)；從用戶空間從新複製到內核空間（你用的socket是系統調用，因此它也有本身的內核空間），最後發送給網卡（三、4）。

Zero Copy中直接從內核空間（DMA的）到內核空間（Socket的），而後發送網卡。

這個技術很是廣泛，The C10K problem 裏面也有很詳細的介紹，Nginx也是用的這種技術，稍微搜一下就能找到不少資料。

Java的NIO提供了FileChannle，它的transferTo、transferFrom方法就是Zero Copy。

Kafka是如何耍賴的

想到了嗎？Kafka把全部的消息都存放在一個一個的文件中， 當消費者須要數據的時候Kafka直接把「文件」發送給消費者 。這就是祕訣所在，好比： 10W的消息組合在一塊兒是10MB的數據量，而後Kafka用相似於發文件的方式直接扔出去了，若是消費者和生產者之間的網絡很是好（只要網絡稍微正常一點10MB根本不是事。。。家裏上網都是100Mbps的帶寬了），10MB可能只須要1s。因此答案是——10W的TPS，Kafka每秒鐘處理了10W條消息。

可能你說：不可能把整個文件發出去吧？裏面還有一些不須要的消息呢？是的，Kafka做爲一個「高級做弊分子」天然要把做弊作的有逼格。Zero Copy對應的是sendfile這個函數（以Linux爲例），這個函數接受

• out_fd做爲輸出（通常及時socket的句柄）

• in_fd做爲輸入文件句柄

• off_t表示in_fd的偏移（從哪裏開始讀取）

• size_t表示讀取多少個

沒錯，Kafka是用mmap做爲文件讀寫方式的，它就是一個文件句柄，因此直接把它傳給sendfile；偏移也好解決，用戶會本身保持這個offset，每次請求都會發送這個offset。（還記得嗎？放在zookeeper中的）；數據量更容易解決了，若是消費者想要更快，就所有扔給消費者。若是這樣作通常狀況下消費者確定直接就被 壓死了 ；因此Kafka提供了的兩種方式——Push，我所有扔給你了，你死了無論個人事情；Pull，好吧你告訴我你須要多少個，我給你多少個。

總結

Kafka速度的祕訣在於，它把全部的消息都變成一個的文件。經過mmap提升I/O速度，寫入數據的時候它是末尾添加因此速度最優；讀取數據的時候配合sendfile直接暴力輸出。阿里的RocketMQ也是這種模式，只不過是用Java寫的。

單純的去測試MQ的速度沒有任何意義，Kafka這種「暴力」、「流氓」、「無恥」的作法已經脫了MQ的底褲，更像是一個暴力的「數據傳送器」。 因此對於一個MQ的評價只以速度論英雄，世界上沒人能幹的過Kafka，咱們設計的時候不能聽信網上的流言蜚語——「Kafka最快，你們都在用，因此咱們的MQ用Kafka沒錯」。在這種思想的做用下，你可能根本不會關心「失敗者」；而實際上可能這些「失敗者」是更適合你業務的MQ。

 

Kafka文件存儲機制那些事

分析過程分爲如下4個步驟：

• topic中partition存儲分佈
• partiton中文件存儲方式
• partiton中segment文件存儲結構
• 在partition中如何經過offset查找message

經過上述4過程詳細分析，咱們就能夠清楚認識到kafka文件存儲機制的奧祕。

2.1 topic中partition存儲分佈

假設實驗環境中Kafka集羣只有一個broker，xxx/message-folder爲數據文件存儲根目錄，在Kafka broker中server.properties文件配置(參數log.dirs=xxx/message-folder)，例如建立2個topic名稱分別爲report_push、launch_info, partitions數量都爲partitions=4

存儲路徑和目錄規則爲： 
xxx/message-folder

在Kafka文件存儲中，同一個topic下有多個不一樣partition，每一個partition爲一個目錄，partiton命名規則爲topic名稱+有序序號，第一個partiton序號從0開始，序號最大值爲partitions數量減1。

2.2 partiton中文件存儲方式

下面示意圖形象說明了partition中文件存儲方式: 

• 每一個partion(目錄)至關於一個巨型文件被平均分配到多個大小相等segment(段)數據文件中。但每一個段segment file消息數量不必定相等，這種特性方便old segment file快速被刪除。
• 每一個partiton只須要支持順序讀寫就好了，segment文件生命週期由服務端配置參數決定。

這樣作的好處就是能快速刪除無用文件，有效提升磁盤利用率。

2.3 partiton中segment文件存儲結構

讀者從2.2節瞭解到Kafka文件系統partition存儲方式，本節深刻分析partion中segment file組成和物理結構。

• segment file組成：由2大部分組成，分別爲index file和data file，此2個文件一一對應，成對出現，後綴」.index」和「.log」分別表示爲segment索引文件、數據文件.
• segment文件命名規則：partion全局的第一個segment從0開始，後續每一個segment文件名爲上一個segment文件最後一條消息的offset值。數值最大爲64位long大小，19位數字字符長度，沒有數字用0填充。

下面文件列表是筆者在Kafka broker上作的一個實驗，建立一個topicXXX包含1 partition，設置每一個segment大小爲500MB,並啓動producer向Kafka broker寫入大量數據,以下圖2所示segment文件列表形象說明了上述2個規則：

以上述圖2中一對segment file文件爲例，說明segment中index<—->data file對應關係物理結構以下：

上述圖3中索引文件存儲大量元數據，數據文件存儲大量消息，索引文件中元數據指向對應數據文件中message的物理偏移地址。

其中以索引文件中元數據3,497爲例，依次在數據文件中表示第3個message(在全局partiton表示第368772個message)、以及該消息的物理偏移地址爲497。

從上述圖3瞭解到segment data file由許多message組成，下面詳細說明message物理結構以下：

參數說明

關鍵字	解釋說明
8 byte offset	在parition(分區)內的每條消息都有一個有序的id號，這個id號被稱爲偏移(offset),它能夠惟一肯定每條消息在parition(分區)內的位置。即offset表示partiion的第多少message
4 byte message size	message大小
4 byte CRC32	用crc32校驗message
1 byte 「magic」	表示本次發佈Kafka服務程序協議版本號
1 byte 「attributes」	表示爲獨立版本、或標識壓縮類型、或編碼類型。
4 byte key length	表示key的長度,當key爲-1時，K byte key字段不填
K byte key	可選
value bytes payload	表示實際消息數據。

2.4 在partition中如何經過offset查找message

例如讀取offset=368776的message，須要經過下面2個步驟查找。

• 第一步查找segment file 
  上述圖2爲例，其中00000000000000000000.index表示最開始的文件，起始偏移量(offset)爲0.第二個文件00000000000000368769.index的消息量起始偏移量爲368770 = 368769 + 1.一樣，第三個文件00000000000000737337.index的起始偏移量爲737338=737337 + 1，其餘後續文件依次類推，以起始偏移量命名並排序這些文件，只要根據offset 二分查找文件列表，就能夠快速定位到具體文件。 
  當offset=368776時定位到00000000000000368769.index|log

• 第二步經過segment file查找message 
  經過第一步定位到segment file，當offset=368776時，依次定位到00000000000000368769.index的元數據物理位置和00000000000000368769.log的物理偏移地址，而後再經過00000000000000368769.log順序查找直到offset=368776爲止。

從上述圖3可知這樣作的優勢，segment index file採起稀疏索引存儲方式，它減小索引文件大小，經過mmap能夠直接內存操做，稀疏索引爲數據文件的每一個對應message設置一個元數據指針,它比稠密索引節省了更多的存儲空間，但查找起來須要消耗更多的時間。

3 Kafka文件存儲機制–實際運行效果

實驗環境：

• Kafka集羣：由2臺虛擬機組成
• cpu：4核
• 物理內存：8GB
• 網卡：千兆網卡
• jvm heap: 4GB

從上述圖5能夠看出，Kafka運行時不多有大量讀磁盤的操做，主要是按期批量寫磁盤操做，所以操做磁盤很高效。這跟Kafka文件存儲中讀寫message的設計是息息相關的。Kafka中讀寫message有以下特色:

寫message：

• 消息從java堆轉入page cache(即物理內存)。
• 由異步線程刷盤,消息從page cache刷入磁盤。

讀message

• 消息直接從page cache轉入socket發送出去。
• 當從page cache沒有找到相應數據時，此時會產生磁盤IO,從磁盤Load消息到page cache,而後直接從socket發出去

4.總結

Kafka高效文件存儲設計特色：

• Kafka把topic中一個parition大文件分紅多個小文件段，經過多個小文件段，就容易按期清除或刪除已經消費完文件，減小磁盤佔用。
• 經過索引信息能夠快速定位message和肯定response的最大大小。
• 經過index元數據所有映射到memory，能夠避免segment file的IO磁盤操做。
• 經過索引文件稀疏存儲，能夠大幅下降index文件元數據佔用空間大小。