源：http://incubator.apache.org/kafka/design.html

Message Persistence and Caching

Don't fear the filesystem!

         Kafka在很大程度上依賴檔案系統來實現儲存和高速訊息快取。我們普遍認為磁碟是慢的，由此使人們懷疑一個具有持久化功能的系統能否展現足夠高的效能。事實上，磁碟的所謂快慢完全取決於我們如何去使用它。一個合適的磁碟結構設計可以足以滿足於網路請求。

         問題的關鍵在於，在過去的十年中磁碟的吐量與其尋道時間關聯很大。6塊 7200RPM SATA RAID5陣列的寫速度差不多是300MB/sec。但是隨機讀取的速度差不多是50/sec 差不多10000倍的差距。可見線性的讀寫模式是可預見的最適合。因此，作業系統通過檢測和預測進行預讀和延遲寫。這個問題的進一步討論在ACM的相關佇列論文中有一些介紹。他們發現磁碟順序訪問堪比記憶體的隨機訪問。

         現代的作業系統為擬補記憶體與磁碟效率上的差異，會將主存拿來為磁碟做快取。幾乎所有的現代作業系統都非常樂意做出一點犧牲，在記憶體空閒的時候恨不得將其全部拿來做磁碟快取用。所有的磁碟讀寫將通過這一統一的快取介面。這一特性一直採納除非你不直接使用I/O介面。因此，當你操作一份資料時，該資料可能複製到OS的頁快取，也就是說實際上有效的寫了兩次。

         此外，我們將在JVM之上進行開發，進行過JAVA記憶體開發的人都知道：

l  物件的儲存開銷很大，會是實際儲存資料的一倍，甚至更糟。

l  JAVA的記憶體回收機制隨著堆的規模增長而略顯粗糙並效能下降。

         由於這些原因，使用檔案系統和頁快取較好地維護了記憶體cache和其他的架構。我們需要兩倍的可用記憶體空間以適應全記憶體的訪問需求。就比如，我們需要儲存的是一個壓縮後的整體架構，而不僅僅是資料物件。為此在一個32GB的記憶體機器上，我們可能會消耗掉28-30GB的記憶體空間，這是不用考慮記憶體回收的。另外，這些快取可以一直保持著（即被持久化），即使計算機重啟，這時需要快取的重建（10G的cache大約需要10分鐘），或者我們直接從頭來一遍進行冷啟動。

         這大大簡化業務邏輯程式碼，因為這些一致性維護等工作都交給了OS去做。這比一堆資料寫入時一錘子買賣要靠譜多了。如果你的磁碟使用有利於線性讀取，那麼預載入將是一個很好的解決方案。

         這使得設計變得簡單：與其我們在記憶體中維持一坨資料，然後將它刷進檔案系統，不如反其道而行。不如直接將其持久化到檔案系統。實際上，就是把資料放入OS 的頁快取上，然後讓OS flush他到磁碟上。我們只提供一個可配置的flush策略就行了。

         以上的相關論文請參見【here】

2012-08-29 待續