同步首發，歡迎**！
不要畏懼檔案系統!
kafka大量依賴檔案系統去儲存和快取訊息。對於硬碟有個傳統的觀念是硬碟總是很慢，這使很多人懷疑基於檔案系統的架構能否提供優異的效能。實際上硬碟的快慢完全取決於使用它的方式。設計良好的硬碟架構可以和記憶體一樣快。
在6塊7200轉的sata raid-5磁碟陣列的線性寫速度差不多是600mb/s，但是隨即寫的速度卻是100k/s，差了差不多6000倍。現代的作業系統都對次做了大量的優化，使用了 read-ahead 和 write-behind的技巧，讀取的時候成塊的預讀取資料，寫的時候將各種微小瑣碎的邏輯寫入組織合併成一次較大的物理寫入。對此的深入討論可以檢視這裡，它們發現線性的訪問磁碟，很多時候比隨機的記憶體訪問快得多。
為了提高效能，現代作業系統往往使用記憶體作為磁碟的快取，現代作業系統樂於把所有空閒記憶體用作磁碟快取，雖然這可能在快取**和重新分配時犧牲一些效能。所有的磁碟讀寫操作都會經過這個快取，這不太可能被繞開除非直接使用i/o。所以雖然每個程式都在自己的執行緒裡只快取了乙份資料，但在作業系統的快取裡還有乙份，這等於存了兩份資料。
另外再來討論一下jvm,以下兩個事實是眾所周知的：
基於以上分析，如果把資料快取在記憶體裡，因為需要儲存兩份，不得不使用兩倍的記憶體空間，kafka基於jvm，又不得不將空間再次加倍,再加上要避免gc帶來的效能影響，在乙個32g記憶體的機器上，不得不使用到28-30g的記憶體空間。並且當系統重啟的時候，又必須要將資料刷到記憶體中（ 10gb 記憶體差不多要用10分鐘），就算使用冷重新整理（不是一次性刷進記憶體，而是在使用資料的時候沒有就刷到記憶體）也會導致最初的時候新能非常慢。但是使用檔案系統，即使系統重啟了，也不需要重新整理資料。使用檔案系統也簡化了維護資料一致性的邏輯。
所以與傳統的將資料快取在記憶體中然後刷到硬碟的設計不同，kafka直接將資料寫到了檔案系統的日誌中。
常量時間的操作效率
在大多數的訊息系統中，資料持久化的機制往往是為每個cosumer提供乙個b樹或者其他的隨機讀寫的資料結構。b樹當然是很棒的，但是也帶了一些代價：比如b樹的複雜度是o(log n)，o(log n)通常被認為就是常量複雜度了，但對於硬碟操作來說並非如此。磁碟進行一次搜尋需要10ms，每個硬碟在同一時間只能進行一次搜尋，這樣併發處理就成了問題。雖然儲存系統使用快取進行了大量優化，但是對於樹結構的效能的觀察結果卻表明，它的效能往往隨著資料的增長而線性下降，資料增長一倍，速度就會降低一倍。
直觀的講，對於主要用於日誌處理的訊息系統，資料的持久化可以簡單的通過將資料追加到檔案中實現，讀的時候從檔案中讀就好了。這樣做的好處是讀和寫都是 o(1) 的，並且讀操作不會阻塞寫操作和其他操作。這樣帶來的效能優勢是很明顯的，因為效能和資料的大小沒有關係了。
漫遊Kafka設計篇之資料持久化
不要畏懼檔案系統 kafka大量依賴檔案系統去儲存和快取訊息。對於硬碟有個傳統的觀念是硬碟總是很慢，這使很多人懷疑基於檔案系統的架構能否提供優異的效能。實際上硬碟的快慢完全取決於使用它的方式。設計良好的硬碟架構可以和記憶體一樣快。在6塊7200轉的sata raid 5磁碟陣列的線性寫速度差不多是6...
漫遊Kafka設計篇之訊息傳輸的事務定義（5）
之前討論了consumer和producer是怎麼工作的，現在來討論一下資料傳輸方面。資料傳輸的事務定義通常有以下三種級別 最多一次 訊息不會被重 送，最多被傳輸一次，但也有可能一次不傳輸。最少一次 訊息不會被漏傳送，最少被傳輸一次，但也有可能被重複傳輸.精確的一次 exactly once 不會漏...
大資料學習之 Kafka 篇
一 簡介 一種分布式的基於發布 訂閱的訊息系統 二 場景 常用組合 常用 flume 收集資料 kafka 把收集來的資料儲存到kafka spark streaming 使用spark streaming 從kafka中取資料 運用場景 1.系統之間的解耦合 2.峰值壓力緩衝 3.非同步通訊 三 ...