kafka為什么快 · JAVA

[TOC] # Broker 不同于redis和memcache等內存消息隊列,kafka的設計是把所有的message都寫入速度低容量大的硬盤,以此換取更強的存儲能力.實際上kafka使用硬盤并沒有帶來過多的性能損失,是抄了一條近道首先說,kafka在磁盤上只做了Sequence I/O,由于消息系統讀寫的特殊性,這并不存在什么問題.關于磁盤I/O的性能,引用一組kafka官方給的測試數據(Raid-5,7200rpm): Sequence I/O:600MB/S Random I/O : 100KB/S 所以通過只做Sequence I/O的限制,規避了磁盤訪問速度底下對性能可能造成的影響 # PageCache 然后kafka重度依賴操作系統提供的PageCache功能.當上層有寫操作時,操作系統只是將數據寫入PageCache,同時標記Page屬性為Dirty 當讀操作發生時,先從PageCache中查找,如果發生缺頁才進行磁盤調度,最終返回需要的數據.**實際上PageCache是把盡可能多的空閑內存都當做了磁盤緩存來使用** 同時如果有其他進程申請內存,回收PageCache的代價很小,所以現代OS都支持PageCache 使用PageCache功能同時避免在jvm內部緩存數據,JVM為我們提供了強大的GC能力,同時也引入了一些問題不適用與kafka設計 * 如果在Heap內管理緩存,JVM的GC線程會頻繁掃描Heap空間,帶來不必要的開銷.如果Heap過大,執行一次Full GC對系統的可用性來說將是極大的挑戰 * 所有在JVM內的對象都不免帶有一個Object Overhead(千萬不可小視),內存的有效空間利用率會因此降低 * 所有的In-Process Cache在OS中都有一份同樣的PageCache.所以通過將緩存只放在PageCache可以至少讓可用緩存空間翻倍 * 如果kafka重啟,所有的In-Process Cache都會失效,而OS管理的PageCache依然可以繼續使用 PageCache還只是第一步,kafka為了進一步的優化性能,還采用了SendFile. # sendfile 在解釋sendfile之前,首先介紹下傳統的網絡I/O操作流程,大體上分為以下4步 1. OS從硬盤把數據讀到內核區的PageCache 2. 用戶進程把數據從內核區Copy到用戶區 3. 然后用戶進程再把數據寫入到socket,數據流入內核區的socket Buffer上 4. OS再把數據從Buffer中copy到網卡的Buffer上,這樣就完成一次發送 ![](https://box.kancloud.cn/7c21513c0bf745e9aa8c5c44579085ef_686x534.png) 整個過程共經歷兩次Context Switch,四次System call.同一份數據在內核Buffer與用戶Buffer之間重復拷貝,效率低下其中2,3兩步沒必要,完全可以在內核區完成數據拷貝.這也正是sendfile所解決的問題. 經過sendfile優化后,整個I/O過程就變成了下面的樣子 ![](https://box.kancloud.cn/76d7eba5f600b5da5582b29840c27143_629x534.png) 通過以上的介紹不難看出,kafka的設計初衷是盡一切努力在內存中完成數據交換,無論是對外作為一整個消息系統,或是內部同底層操作系統的交互. 如果Producer和Consumer之間生產和消費進度上配合得當,完全可以實現數據交換零I/O.這也就是我們所說kafka使用硬盤并沒有帶來過多性能損耗