分布式系統(tǒng)原理

日志技術(shù)

日志技術(shù)是宕機(jī)恢復(fù)的主要技術(shù)之一[3]。日志技術(shù)最初使用在數(shù)據(jù)庫(kù)系統(tǒng)中。嚴(yán)格來(lái)說(shuō)日志技術(shù)不是一種分布式系統(tǒng)的技術(shù)，但在分布式系統(tǒng)的實(shí)踐中，卻廣泛使用了日志技術(shù)做宕機(jī)恢復(fù)，甚至如 BigTable 等系統(tǒng)將日志保存到一個(gè)分布式系統(tǒng)中進(jìn)一步增強(qiáng)了系統(tǒng)容錯(cuò)能力。

本章首先簡(jiǎn)單介紹數(shù)據(jù)庫(kù)系統(tǒng)中的日志技術(shù)，進(jìn)而抽象簡(jiǎn)化問(wèn)題模型，在簡(jiǎn)化模型的基礎(chǔ)上介紹兩種實(shí)用的日志技術(shù) Redo Log 與 No Redo/No undo Log。

1. 數(shù)據(jù)庫(kù)系統(tǒng)日志技術(shù)簡(jiǎn)述

在數(shù)據(jù)庫(kù)系統(tǒng)中實(shí)現(xiàn)宕機(jī)恢復(fù)，其難點(diǎn)在于數(shù)據(jù)庫(kù)操作需要滿足 ACID，尤其在支持事務(wù)（transaction）的數(shù)據(jù)庫(kù)系統(tǒng)中宕機(jī)往往發(fā)生在某些事務(wù)只執(zhí)行了部分操作的時(shí)候。此時(shí)宕機(jī)恢復(fù)的主要目標(biāo)就是數(shù)據(jù)庫(kù)系統(tǒng)恢復(fù)到一個(gè)穩(wěn)定可靠狀態(tài)，消除未完成的事務(wù)對(duì)數(shù)據(jù)庫(kù)狀態(tài)的影響。

數(shù)據(jù)庫(kù)的日志主要分為 Undo Log、Redo Log、Redo/Undo Log 與 No Redo/No Undo Log。這四類日志的區(qū)別在更新日志文件和數(shù)據(jù)文件的時(shí)間點(diǎn)要求不同，從而造成性能和效率也不相同。本文不就數(shù)據(jù)庫(kù)中的這四類日志技術(shù)做深入討論，相關(guān)信息可以參考有關(guān)數(shù)據(jù)庫(kù)系統(tǒng)方面的資料。

2. Redo Log 與 Check point

2.1 問(wèn)題模型

首先簡(jiǎn)化原數(shù)據(jù)庫(kù)系統(tǒng)中的問(wèn)題模型為一個(gè)較為簡(jiǎn)單的模型：假設(shè)需要設(shè)計(jì)一個(gè)高速的單機(jī)查詢系統(tǒng)，將數(shù)據(jù)全部存放在內(nèi)存中以實(shí)現(xiàn)高速的數(shù)據(jù)查詢，每次更新操作更新一小部分?jǐn)?shù)據(jù)（例如key-value 中的某一個(gè) key）。現(xiàn)在問(wèn)題為利用日志技術(shù)實(shí)現(xiàn)該內(nèi)存查詢系統(tǒng)的宕機(jī)恢復(fù)。與數(shù)據(jù)庫(kù)的事務(wù)不同的是，這個(gè)問(wèn)題模型中的每個(gè)成功的更新操作都會(huì)生效。這也等效為數(shù)據(jù)庫(kù)的每個(gè)事務(wù)只有一個(gè)更新操作，且每次更新操作都可以也必須立即提交（Auto commit）。

2.2 Redo Log

Redo Log 是一種非常簡(jiǎn)單實(shí)用的日志技術(shù)。在上節(jié)的問(wèn)題模型中，只需按如下流程更新既可以實(shí)用 Redo Log。

流程 2.5.1：Redo Log 更新流程 1. 將更新操作的結(jié)果（例如 Set K1=1，則記錄 K1=1）以追加寫(xiě)（append）的方式寫(xiě)入磁盤的日志文件 2. 按更新操作修改內(nèi)存中的數(shù)據(jù) 3. 返回更新成功

上述更新流程中第 2 步?jīng)]有考慮修改內(nèi)存數(shù)據(jù)需要多線程互斥等問(wèn)題，但對(duì)于說(shuō)明 Redo Log的原理沒(méi)有影響。

從Redo Log的流程可以看出，Redo寫(xiě)入日志的是更新操作完成后的結(jié)果（雖然本文不討論UndoLog，這點(diǎn)是與 Undo Log的區(qū)別之一），且由于是順序追加寫(xiě)日志文件，在磁盤等對(duì)順序?qū)懹辛Φ拇鎯?chǔ)設(shè)備上效率較高。

用 Redo Log 進(jìn)行宕機(jī)恢復(fù)非常簡(jiǎn)單，只需要“回放”日志即可。

流程 2.5.2：Redo Log 的宕機(jī)恢復(fù) 1. 從頭讀取日志文件中的每次更新操作的結(jié)果，用這些結(jié)果修改內(nèi)存中的數(shù)據(jù)。

從 Redo Log 的宕機(jī)恢復(fù)流程也可以看出，只有寫(xiě)入日志文件的更新結(jié)果才能在宕機(jī)后恢復(fù)。這也是為什么在 Redo Log 流程中需要先更新日志文件再更新內(nèi)存中的數(shù)據(jù)的原因。假如先更新內(nèi)存中的數(shù)據(jù)，那么用戶立刻就能讀到更新后的數(shù)據(jù)，一旦在完成內(nèi)存修改與寫(xiě)入日志之間發(fā)生宕機(jī)，那么最后一次更新操作無(wú)法恢復(fù)，但之前用戶可能已經(jīng)讀取到了更新后的數(shù)據(jù)，從而引起不一致的問(wèn)題。

2.3 Check point

宕機(jī)恢復(fù)流量的缺點(diǎn)是需要回放所有 redo 日志，效率較低，假如需要恢復(fù)的操作非常多，那么這個(gè)宕機(jī)恢復(fù)過(guò)程將非常漫長(zhǎng)。解決這一問(wèn)題的方法即引入 check point 技術(shù)。在簡(jiǎn)化的模型下，checkpoint 技術(shù)的過(guò)程即將內(nèi)存中的數(shù)據(jù)以某種易于重新加載的數(shù)據(jù)組織方式完整的 dump 到磁盤，從而減少宕機(jī)恢復(fù)時(shí)需要回放的日志數(shù)據(jù)。

流程 2.5.3：check point 1. 向日志文件中記錄“Begin Check Point” 2. 將內(nèi)存中的數(shù)據(jù)以某種易于重新加載的數(shù)據(jù)組織方式 dump 到磁盤上 3. 向日志文件中記錄“End Check Point”

在 check point 流程中，數(shù)據(jù)可以繼續(xù)按照流程 2.5.1 被更新，這段過(guò)程中新更新的數(shù)據(jù)可以 dump到磁盤也可以不 dump 到磁盤，具體取決于實(shí)現(xiàn)。例如，check point 開(kāi)始時(shí) k1=v1，check point 過(guò)程中某次更新為 k1 = v2，那么 dump 到磁盤上的 k1 的值可以是 v1 也可以是 v2。

流程 2.5.4：基于 check point 的宕機(jī)恢復(fù)流程 1. 將 dump 到磁盤的數(shù)據(jù)加載到內(nèi)存。 2. 從后向前掃描日志文件，尋找最后一個(gè)“End Check Point”日志。 3. 從最后一個(gè)“End Check Point”日志向前找到最近的一個(gè)“Begin Check Point”日志，并回放該日志之后的所有更新操作日志。

3. No Undo/No Redo log

本節(jié)介紹另一種特殊的日志技術(shù)“No Undo/No Redo log”，這種技術(shù)也稱之為“0/1 目錄”(0/1directory)。

本節(jié)介紹這種技術(shù)并不再使用上節(jié)的問(wèn)題場(chǎng)景，而假設(shè)另一種問(wèn)題場(chǎng)景：若數(shù)據(jù)維護(hù)在磁盤中，某批更新由若干個(gè)更新操作組成，這些更新操作需要原子生效，即要么同時(shí)生效，要么都不生效。

0/1 目錄技術(shù)中有兩個(gè)目錄結(jié)構(gòu)，稱為目錄 0(Directory 0)和目錄 1(Directory 1)。另有一個(gè)結(jié)構(gòu)稱為主記錄（Master record）記錄當(dāng)前正在使用的目錄稱為活動(dòng)目錄。主記錄中要么記錄使用目錄 0，要么記錄使用目錄 1。目錄 0 或目錄 1 中記錄了各個(gè)數(shù)據(jù)的在日志文件中的位置。

0/1 目錄的數(shù)據(jù)更新過(guò)程始終在非活動(dòng)目錄上進(jìn)行，只是在數(shù)據(jù)生效前，將主記錄中的 0、1 值反轉(zhuǎn)，從而切換主記錄。

流程 2.5.5：0/1 目錄數(shù)據(jù)更新流程 1. 將活動(dòng)目錄完整拷貝到非活動(dòng)目錄。 2. 對(duì)于每個(gè)更新操作，新建一個(gè)日志項(xiàng)紀(jì)錄操作后的值，并在非活動(dòng)目錄中將相應(yīng)數(shù)據(jù)的位置 修改為新建的日志項(xiàng)的位置。 3. 原子性修改主記錄：反轉(zhuǎn)主記錄中的值，使得非活動(dòng)目錄生效。

0/1 目錄的更新流程非常簡(jiǎn)單，通過(guò) 0、1 目錄的主記錄切換使得一批修改的生效是原子的。

0/1 目錄將批量事務(wù)操作的原子性通過(guò)目錄手段歸結(jié)到主記錄的原子切換。由于多條記錄的原子修改一般較難實(shí)現(xiàn)而單條記錄的原子修改往往可以實(shí)現(xiàn)，從而降低了問(wèn)題實(shí)現(xiàn)的難度。在工程中0/1 目錄的思想運(yùn)用非常廣泛，其形式也不局限在上述流程中，可以是內(nèi)存中的兩個(gè)數(shù)據(jù)結(jié)構(gòu)來(lái)回切換，也可以是磁盤上的兩個(gè)文件目錄來(lái)回生效切換。

4. 工程投影

日志技術(shù)的使用非常廣泛，在 zookeeper 系統(tǒng)中，為了實(shí)現(xiàn)高效的數(shù)據(jù)訪問(wèn)，數(shù)據(jù)完全保存在內(nèi)存中，但更新操作的日志不斷持久化到磁盤，另一方面，為了實(shí)現(xiàn)較快速度的宕機(jī)恢復(fù)，zookeeper周期性的將內(nèi)存數(shù)據(jù)以 checkpoint 的方式 dump 到磁盤。

MySQL 的主從庫(kù)設(shè)計(jì)也是基于日志。從庫(kù)只需通過(guò)回放主庫(kù)的日志，就可以實(shí)現(xiàn)與主庫(kù)的同步。由于從庫(kù)同步的速度與主庫(kù)更新的速度沒(méi)有強(qiáng)約束，這種方式只能實(shí)現(xiàn)最終一致性。

Mola與 Armor系統(tǒng)支持多種不同的存儲(chǔ)引擎，對(duì)于接受到的更新操作，這兩個(gè)系統(tǒng)將操作日志（redo log）保存到磁盤，引擎可以通過(guò)回放日志實(shí)現(xiàn)副本數(shù)據(jù)的同步。在 mola中，由于不需要強(qiáng)一致性，日志與數(shù)據(jù)分離，且日志也保存多個(gè)副本，當(dāng)日志副本更新滿足 quorum 要求后就返回用戶更新成功。引擎通過(guò)回放日志的方式實(shí)現(xiàn)數(shù)據(jù)更新，由于回放速度不一致，mola 提供最終一致性保證。同時(shí)，由于返回用戶更新成功時(shí)只保證日志更新成功，此時(shí)讀取引擎數(shù)據(jù)未必可以讀到最新更新的數(shù)據(jù)。Armor*中更新了這一設(shè)計(jì)，日志與數(shù)據(jù)不分離，更新日志的同時(shí)也更新引擎數(shù)據(jù)，從而可以立刻讀取到成功更新的數(shù)據(jù)。

參考：《分布式系統(tǒng)原理介紹》 - 劉杰

總結(jié)

以上是生活随笔為你收集整理的分布式系统原理 之5 日志技术的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。