眾所周知kafka的吞吐量比一般的消息隊列要高，號稱the fastest，那他是如何做到的，讓我們從以下幾個方面分析一下原因。
生產者（寫入數據）
生產者（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是系統調用，所以它也有自己的內核空間），最後發送給網卡（3、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。
需要的Java架構師方面的資料可以關注之後私信哈，回復「資料」領取免費架構視頻資料，記得要點贊轉發噢！！！