?

上節內容講到log文件在LevelDb中的主要作用是系統故障恢復時，能夠保證不會丟失數據。因為在將記錄寫入內存的Memtable之前，會先寫入Log文件，這樣即使系統發生故障，Memtable中的數據沒有來得及Dump到磁盤的SSTable文件，LevelDB也可以根據log文件恢復內存的Memtable數據結構內容，不會造成系統丟失數據，在這點上LevelDb和Bigtable是一致的。

下面我們帶大家看看log文件的具體物理和邏輯布局是怎樣的，LevelDb對于一個log文件，會把它切割成以32K為單位的物理Block，每次讀取的單位以一個Block作為基本讀取單位，下圖展示的log文件由3個Block構成，所以從物理布局來講，一個log文件就是由連續的32K大小Block構成的。

圖3.1log文件布局

在應用的視野里是看不到這些Block的，應用看到的是一系列的Key:Value對，在LevelDb內部，會將一個Key:Value對看做一條記錄的數據，另外在這個數據前增加一個記錄頭，用來記載一些管理信息，以方便內部處理，圖3.2顯示了一個記錄在LevelDb內部是如何表示的。

圖3.2記錄結構

記錄頭包含三個字段，ChechSum是對“類型”和“數據”字段的校驗碼，為了避免處理不完整或者是被破壞的數據，當LevelDb讀取記錄數據時候會對數據進行校驗，如果發現和存儲的CheckSum相同，說明數據完整無破壞，可以繼續后續流程。“記錄長度”記載了數據的大小，“數據”則是上面講的Key:Value數值對，“類型”字段則指出了每條記錄的邏輯結構和log文件物理分塊結構之間的關系，具體而言，主要有以下四種類型：FULL/FIRST/MIDDLE/LAST。

如果記錄類型是FULL，代表了當前記錄內容完整地存儲在一個物理Block里，沒有被不同的物理Block切割開；如果記錄被相鄰的物理Block切割開，則類型會是其他三種類型中的一種。我們以圖3.1所示的例子來具體說明。

假設目前存在三條記錄，Record A，Record B和Record C，其中Record A大小為10K，Record B 大小為80K，Record C大小為12K，那么其在log文件中的邏輯布局會如圖3.1所示。Record A是圖中藍色區域所示，因為大小為10K<32K，能夠放在一個物理Block中，所以其類型為FULL；Record B 大小為80K，而Block 1因為放入了Record A，所以還剩下22K，不足以放下Record B，所以在Block 1的剩余部分放入Record B的開頭一部分，類型標識為FIRST，代表了是一個記錄的起始部分；Record B還有58K沒有存儲，這些只能依次放在后續的物理Block里面，因為Block 2大小只有32K，仍然放不下Record B的剩余部分，所以Block 2全部用來放Record B，且標識類型為MIDDLE，意思是這是Record B中間一段數據；Record B剩下的部分可以完全放在Block 3中，類型標識為LAST，代表了這是Record B的末尾數據；圖中黃色的Record C因為大小為12K，Block 3剩下的空間足以全部放下它，所以其類型標識為FULL。

從這個小例子可以看出邏輯記錄和物理Block之間的關系，LevelDb一次物理讀取為一個Block，然后根據類型情況拼接出邏輯記錄，供后續流程處理。

LevelDB系列之Log文件