漫遊Kafka實現篇之訊息和日誌

標籤：blog   http   java   使用   檔案   資料   2014   art   

原文地址：http://blog.csdn.net/honglei915/article/details/37760631

訊息格式

訊息由一個固定長度的頭部和可變長度的位元組數組組成。頭部包括了一個版本和CRC32校正碼。

/**  * 具有N個位元組的訊息的格式例如以下  *  * 假設版本是0 *  * 1. 1個位元組的 "magic" 標記 *  * 2. 4個位元組的CRC32校正碼  *  * 3. N - 5個位元組的詳細資料 *  * 假設版本是1  *  * 1. 1個位元組的 "magic" 標記  *  * 2.1個位元組的參數同意標註一些附加的資訊比方是否壓縮了，解碼類型等 *  * 3.4個位元組的CRC32校正碼 *  * 4. N - 6 個位元組的詳細資料 *  */

日誌

一個叫做“my_topic”且有兩個分區的的topic,它的日誌有兩個目錄組成，my_topic_0和my_topic_1,每一個目錄裡放著詳細的資料檔案，每一個資料檔案都是一系列的日誌實體，每一個日誌實體有一個4個位元組的整數N標註訊息的長度，後邊跟著N個位元組的訊息。每一個訊息都能夠由一個64位的整數offset標註，offset標註了這條訊息在發送到這個分區的訊息流程中的起始位置。每一個記錄檔的名稱都是這個檔案第一條日誌的offset.所以第一個記錄檔的名字就是00000000000.kafka.所以每相鄰的兩個檔案名稱字的差就是一個數字S,S差點兒相同就是設定檔裡指定的記錄檔的最大容量。

訊息的格式都由一個統一的介面維護，所以訊息能夠在producer,broker和consumer之間無縫的傳遞。儲存在硬碟上的訊息格式例如以下所看到的：

訊息長度:     4 bytes (value: 1+4+n) 版本:       1 byteCRC校正碼:    4 bytes詳細的訊息:   n bytes

寫操作

訊息被不斷的追加到最後一個日誌的末尾，當日誌的大小達到一個指定的值時就會產生一個新的檔案。對於寫操作有兩個參數，一個規定了訊息的數量達到這個值時必須將資料重新整理到硬碟上，另外一個規定了重新整理到硬碟的時間間隔，這對資料的持久性是個保證，在系統崩潰的時候僅僅會丟失一定數量的訊息或者一個時間段的訊息。

讀操作

讀操作須要兩個參數：一個64位的offset和一個S位元組的最大讀取量。S通常比單個訊息的大小要大，但在一些個別訊息比較大的情況下，S會小於單個訊息的大小。這樣的情況下讀操作會不斷重試，每次重試都會將讀取量加倍，直到讀取到一個完整的訊息。能夠配置單個訊息的最大值，這樣server就會拒絕大小超過這個值的訊息。也能夠給client指定一個嘗試讀取的最大上限，避免為了讀到一個完整的訊息而無限次的重試。

在實際運行讀取操縱時，首先須要定位元據所在的記錄檔，然後依據offset計算出在這個日誌中的offset(前面的的offset是整個分區的offset),然後在這個offset的位置進行讀取。定位操作是由二分尋找法完畢的，Kafka在記憶體中為每一個檔案維護了offset的範圍。

以下是發送給consumer的結果的格式：

MessageSetSend (fetch result)total length     : 4 byteserror code       : 2 bytesmessage 1        : x bytes...message n        : x bytes

MultiMessageSetSend (multiFetch result)total length       : 4 byteserror code         : 2 bytesmessageSetSend 1...messageSetSend n

刪除

日誌管理器同意定製刪除策略。眼下的策略是刪除改動時間在N天之前的日誌（按時間刪除），也能夠使用另外一個策略：保留最後的N GB資料的策略(按大小刪除)。為了避免在刪除時堵塞讀操作，採用了copy-on-write形式的實現，刪除操作進行時，讀取操作的二分尋找功能實際是在一個靜態快照副本上進行的，這類似於Java的CopyOnWriteArrayList。

可靠性保證

記錄檔有一個可配置的參數M，緩衝超過這個數量的訊息將被強行重新整理到硬碟。一個日誌矯正線程將迴圈檢查最新的記錄檔裡的訊息確認每一個訊息都是合法的。合法的標準為：全部檔案的大小的和最大的offset小於記錄檔的大小，而且訊息的CRC32校正碼與儲存在訊息實體中的校正碼一致。假設在某個offset發現不合法的訊息，從這個offset到下一個合法的offset之間的內容將被移除。

有兩種情況必須考慮：1，當發生崩潰時有些資料區塊未能寫入。2，寫入了一些空白資料區塊。另外一種情況的原因是，對於每一個檔案，作業系統都有一個inode（inode是指在很多“類Unix檔案系統”中的一種資料結構。每一個inode儲存了檔案系統中的一個檔案系統對象,包含檔案、檔案夾、大小、裝置檔案、socket、管道, 等等），但無法保證更新inode和寫入資料的順序，當inode儲存的大小資訊被更新了，但寫入資料時發生了崩潰，就產生了空白資料區塊。CRC校正碼能夠檢查這些塊並移除，當然由於崩潰而未寫入的資料區塊也就丟失了。