1 背景

在讀完kafka官方文檔，kafka設計里的持久化一章后，給我的第一印象是內容很抽象，于是草擬和總結了給個副標題，并把相關內容進行了歸類;有些生澀的句子，盡量用大白話和舉例進行說明，并加入了總結。

2 磁盤IO速度的快和慢，不取決我們的主觀認知，而是由我們的使用方式?jīng)Q定的

kafka 里消息的緩存和存儲，嚴重依賴文件系統(tǒng)。(根據(jù)上下文推測，這里的緩存消息和存儲消息，指的是broker端 緩存和存儲消息)

在我們普遍的認知里，都覺得“磁盤IO速度是非常慢的”，這種固有的觀點，使得人們懷疑持久性結構是否能夠提供競爭性的性能。

(和其它MQ中間件相對，你把數(shù)據(jù) 存入到磁盤上，還有性能上的優(yōu)勢嗎?)

但實際上，磁盤速度，取決于他們的使用方式，設計得當?shù)拇疟P結構往往可以和網(wǎng)絡一樣快。

從順序寫數(shù)據(jù)到磁盤的角度分析 ------順序寫磁盤，比隨機訪問內存的速度還快

事實上 關于磁盤性能，在過去十年中，硬盤驅動器的吞吐量與磁盤尋道的延遲一直存在差異。

在具有六個 7200rpm SATA RAID-5 陣列的 JBOD 配置上，線性寫入性能約為 600MB/秒，但隨機寫入性能僅為約 100k/秒，相差超過 6000 倍。

這些線性讀取和寫入是所有使用模式中最可預測的，并且經(jīng)過操作系統(tǒng)的大力優(yōu)化?，F(xiàn)代操作系統(tǒng)提供預讀和后寫技術，以大塊倍數(shù)預取數(shù)據(jù)，并將較小的邏輯寫入分組為較大的物理寫入。

有關此問題的進一步討論可以在這篇 ACM Queue 文章中找到;他們實際上發(fā)現(xiàn)順序磁盤訪問在某些情況下比隨機內存訪問更快!如下圖所示：

從磁盤讀寫數(shù)據(jù)的角度 ------使用磁盤緩存，加速磁盤讀寫速度

為了彌補這種性能差異，現(xiàn)代操作系統(tǒng)在使用主內存進行磁盤緩存方面變得越來越積極。

現(xiàn)代操作系統(tǒng)將所有空閑內存快樂地用于磁盤緩存，當內存被回收時幾乎沒有性能損失。

所有磁盤讀寫都將通過這個統(tǒng)一緩存進行。

這個特性很難關閉，即使進程在進程內保持數(shù)據(jù)緩存，這些數(shù)據(jù)也可能會在OS頁面緩存中重復存儲，實際上將所有東西存儲兩次。

(日常 數(shù)據(jù)在寫入磁盤時，并沒有刷新到磁盤上，只是寫到了磁盤緩存里，而磁盤緩存其實是操作系統(tǒng)的主內存;即把數(shù)據(jù)寫入文件的時候，其實還是寫到內存中)

圖 kafka broker端 數(shù)據(jù)寫入過程

kafka在寫入數(shù)據(jù)到文件系統(tǒng)時，同步寫入到pagecache，異步刷新并持久化到磁盤里。

3 把數(shù)據(jù)緩存到JVM有哪些劣勢了?

kafka構建在JVM之上，任何花費過時間了解過 Java內存使用的人都知道兩件事：

對象的內存開銷很高，通常會使存儲的數(shù)據(jù)大小翻倍(或更糟)。(即原數(shù)據(jù)可能只有1K大小，但是轉換為java對象，可能要3K)

隨著堆內數(shù)據(jù)的增加，Java垃圾回收變得越來越繁瑣和慢。(jvm里緩存的數(shù)據(jù)，會放到堆內存中;隨這數(shù)據(jù)越來越多，達到GC的臨界點會越來越快，導致GC越來越頻繁 ;這樣就會導致系統(tǒng)會把資源用于GC，而不是業(yè)務處理了)

4 把數(shù)據(jù)緩存到文件系統(tǒng)有哪些優(yōu)勢了?

使用文件系統(tǒng)并依賴頁面緩存方式，比維護內存中緩存或其他結構要更優(yōu) 。主要原因：

相對于把數(shù)據(jù)緩存到jvm中，直接使用操作系統(tǒng)頁面緩存，可讓程序能使用的緩存加倍。(因為jvm 對象的內存開銷很高，他會膨脹。1K的數(shù)據(jù)放入到頁面緩存還是1K;但是轉換為JVM對象，可能就占用了3K空間)

把消息數(shù)據(jù)使用字節(jié)結構并且壓縮的方式進行存儲，比單個對象的存儲更節(jié)約空間，并且還可能進一步帶來緩存內存的加倍使用。

這樣做即使在 32GB 機器上也可產(chǎn)生高達 28-30GB 的緩存，而不會造成 GC 損失。(---即使緩存中的數(shù)據(jù)變大，也不會帶來頻繁的GC)

即使kafka 服務重新啟動，此緩存也將保持熱狀態(tài)。(頁面緩存中數(shù)據(jù)還在，因為kafka進程重新，而操作系統(tǒng)可能不會重啟) 而如果把數(shù)據(jù)放入到進程內緩存，kafka服務重啟時將需要在內存中重建(對于 10GB 緩存可能需要 10 分鐘)，否則它將需要以完全冷的緩存啟動 (這可能意味著糟糕的初始性能)。

極大地簡化了代碼，因為用于維護緩存和文件系統(tǒng)之間一致性的所有邏輯現(xiàn)在都在操作系統(tǒng)中，這往往比一次性進程內嘗試更有效、更正確。

如果您的磁盤使用有利于順序讀取的方式，那么操作系統(tǒng)的預讀實際上是在每次磁盤讀取時使用有用的數(shù)據(jù)預先填充此緩存。

(這里涉及到操作系統(tǒng)讀取磁盤上的數(shù)據(jù)時的一種優(yōu)化---預讀。即往磁盤里讀一行數(shù)據(jù)，操作系統(tǒng)實際上是把這一行數(shù)據(jù)，和他后面的5K數(shù)據(jù)，都會一次性讀出來，放入到緩存里。這對于kafka這種順序消費消息的模式，非常適用，因為多讀出來的數(shù)據(jù)，其實在后續(xù)消費的時候，是需要的，這避免了重復從硬盤多次讀取數(shù)據(jù)，非常類似于一次性加載大塊的數(shù)據(jù)到內存中;然后還沒有浪費內存空間，因為這些數(shù)據(jù)后續(xù)馬上也是需要被消費者消費的)

5 kafka 以文件系統(tǒng)進行存儲和緩存的設計建議

我們不是在內存中保留盡可能多的內容，而是在空間不足時將其全部刷新到文件系統(tǒng)，而是將其反轉。所有數(shù)據(jù)都會立即寫入文件系統(tǒng)上的持久日志，而不必刷新到磁盤。實際上，這僅僅意味著它被轉移到內核的頁面緩存中

(我們不會把數(shù)據(jù) 緩存到jvm進程內存里，當空間不足時，再刷新到緩存里;而是采用了相反的方式：即所有數(shù)據(jù)會立即寫入到文件系統(tǒng)里，即磁盤緩存里(即頁緩存里)，但不會寫入后馬上刷新數(shù)據(jù)到磁盤里)

============以下為個人總結和觀點==============

6 kafka 這種同步寫文件緩存，異步順序刷新數(shù)據(jù)到磁盤的方式就不怕，操作系統(tǒng)掛了，數(shù)據(jù)會丟失嗎?

如果page cache在持久化到磁盤前，broker進程宕機了，這個時候不會丟失消息，重啟broker即可;如果此時操作系統(tǒng)宕機或者物理機宕機了，page cache里的數(shù)據(jù)還沒有持久化到磁盤里，此種情況數(shù)據(jù)就丟了。

kafka應對此種情況，建議是通過多副本機制來解決的，核心思想也挺簡單的：如果數(shù)據(jù)保存在一臺機器上你覺得可靠性不夠，那么我就把相同的數(shù)據(jù)保存到多臺機器上，某臺機器宕機了可以由其它機器提供相同的服務和數(shù)據(jù)。 更加詳細的配置 請看《kafka 消息“零丟失”的配方》 broker端丟失消息的情況和解決方法一節(jié)

7 那能不能自己控制這個數(shù)據(jù)刷盤行為了?

可以的，在kafka的官方配置文檔里有兩個參數(shù)：

log.flush.interval.messages 和 log.flush.interval.ms

一個控制消息量達到了多少，一個控制間隔時間多少;會把頁緩存里消息刷新到磁盤里;但這個控制刷盤行為也是異步的

8 總結

1、kafka broker端會把文件系統(tǒng)，做為消息緩存和存儲;因為操作系統(tǒng)在寫數(shù)據(jù)到磁盤時，已進行了優(yōu)化

2、kafka broker 在寫入數(shù)據(jù)到文件系統(tǒng)時，同步寫入到磁盤緩存里(即內存里)，異步把緩存中的數(shù)據(jù)寫入到磁盤里。這是kafka 寫數(shù)據(jù)到文件系統(tǒng)高效的主要原因，也是核心業(yè)務 寫數(shù)據(jù)主流程 高效的主原因;異步順序刷新數(shù)據(jù)到磁盤里，我覺得是性能高的次要原因，畢竟不阻塞到主流程

3、kafka 作為消息系統(tǒng)，天生就是順序寫入數(shù)據(jù)到文件系統(tǒng)，并順序讀取文件系統(tǒng)的，這種天然的順序性，恰好可以利用操作系統(tǒng)的預讀功能：即一次磁盤IO 讀取數(shù)據(jù)時，會把數(shù)據(jù)附近其他磁盤數(shù)據(jù)也讀寫到內存中;下一次讀取下一條消息時，不需要磁盤IO了，直接從內存中獲取數(shù)據(jù),減少磁盤IO 這種非常慢的讀取次數(shù)，加速取數(shù)過程。

審核編輯：湯梓紅