張文帥

摘要：該文針對Redis數(shù)據(jù)庫中兩個問題，RDB（Snapshot）恢復(fù)數(shù)據(jù)不完整和AOF（Append Only File）恢復(fù)速度慢，提出了RDB+AOF的數(shù)據(jù)恢復(fù)方案。該方案借鑒檢查點思想，依賴RDB和AOF兩種方法，不但具有AOF恢復(fù)數(shù)據(jù)全面的特點，又兼具RDB恢復(fù)速度快的優(yōu)勢。按照此方案修改Redis源碼并作對照實驗，結(jié)果證明該方案可行且有效。

關(guān)鍵詞：Redis；數(shù)據(jù)恢復(fù)；檢查點；RDB+AOF

中圖分類號：TP391 文獻(xiàn)標(biāo)識碼：A 文章編號：1009-3044（2016）14-0007-04

Research on a Data Recovery Strategy Based on RDB and AOF in Redis

ZHANG Wen-shuai

（School of Mechanical Electronic and Information， China University of Ming and Technology（Beijing）， Beijing 100083， China）

Abstract： This paper in order to solve two problems in Redis database，one is that the restored data is not complete through RDB（Snapshot），the orther is the speed is slow through AOF（Append Only File），put forword a data recovery method which combined RDB with AOF.The scheme， which is used checkpoint for reference， depends on the two methods of RDB and AOF， which not only has the characteristics of comprehensive recovery like AOF， but also has the advantage of rapid recovery like RDB.In accordance with this program to modify the Redis' source code and do a control experiment， the results show that the program is feasible and effective.

Key words： Redis； data recovery； checkpoint； RDB+AOF

數(shù)據(jù)庫技術(shù)的發(fā)展，帶動了NoSQL（非關(guān)系數(shù)據(jù)庫）的崛起，其中Redis（REmote DIctionary Server）數(shù)據(jù)庫因其高效性得到廣泛應(yīng)用。它是一個用C語言編寫的開源的內(nèi)存數(shù)據(jù)庫，支持?jǐn)?shù)據(jù)持久化。

持久化是內(nèi)存數(shù)據(jù)庫數(shù)據(jù)恢復(fù)的前提。Redis支持兩種數(shù)據(jù)持久化方法：一種是RDB，能周期性地對數(shù)據(jù)庫做快照并寫入磁盤。RDB恢復(fù)速度較快，但兩次快照期間的數(shù)據(jù)都會丟失；另一種是AOF，將每次寫操作都記錄日志，并定期寫入磁盤。AOF恢復(fù)速度較慢，但能恢復(fù)全部數(shù)據(jù)，不會造成數(shù)據(jù)丟失的現(xiàn)象。

本文通過分析RDB和AOF的原理和特點，結(jié)合多種數(shù)據(jù)庫在數(shù)據(jù)恢復(fù)技術(shù)方面的方法和經(jīng)驗，提出了一種RDB+AOF相結(jié)合的方案，該方案將解決RDB恢復(fù)數(shù)據(jù)不完整和AOF恢復(fù)速度慢的缺點，對于Redis能夠完整快速恢復(fù)數(shù)據(jù)具有很重要的實用意義。

1 數(shù)據(jù)庫恢復(fù)技術(shù)概述

1.1 關(guān)系數(shù)據(jù)庫恢復(fù)技術(shù)

關(guān)系數(shù)據(jù)庫恢復(fù)技術(shù)主要有數(shù)據(jù)轉(zhuǎn)儲和登錄日志文件兩種，為了維護(hù)事務(wù)的特性，必須使用日志方式，以便數(shù)據(jù)恢復(fù)時可以進(jìn)行相應(yīng)的redo（重做）和undo（撤銷）操作，維持事務(wù)一致性。為了解決日志恢復(fù)速度慢的缺陷，關(guān)系數(shù)據(jù)庫在日志基礎(chǔ)上發(fā)展了檢查點技術(shù)。

傳統(tǒng)日志恢復(fù)方法需要遍歷整個日志文件，且要重新執(zhí)行所有操作，這將造成很多時間浪費，為此發(fā)展了檢查點技術(shù)。該技術(shù)在日志文件中增加檢查點，檢查點是這個時刻數(shù)據(jù)庫的一致性備份，再增加一個重新開始文件，用于記錄檢查點在日志文件中的地址，數(shù)據(jù)恢復(fù)時從重新開始文件找到某個檢查點在日志文件中的地址，并從日志中找到這個檢查點開始數(shù)據(jù)恢復(fù)，節(jié)省了遍歷日志和重復(fù)操作的時間和資源。

檢查點技術(shù)對事務(wù)的恢復(fù)工作可分為以下三種情況[1]：

（1）在檢查點之前完成的事務(wù)，更新已經(jīng)寫到數(shù)據(jù)庫中，不需要再重做；

（2）檢查點之后、故障點之前完成的事務(wù)，雖然事務(wù)已結(jié)束，但它們對數(shù)據(jù)庫的修改可能還未來得及寫到磁盤上，必須要重做；

（3）故障點時刻尚未結(jié)束的事務(wù)，它們的操作是不完整的，需要撤銷。

1.2 內(nèi)存數(shù)據(jù)庫恢復(fù)技術(shù)

內(nèi)存數(shù)據(jù)庫（MMDB）由于內(nèi)存的易失性，需要將數(shù)據(jù)持久化到磁盤，不同于普通外存數(shù)據(jù)庫，MMDB需要一次性將數(shù)據(jù)全部加載到內(nèi)存，因此日志文件的大小是限制MMDB數(shù)據(jù)恢復(fù)的一個重要因素。

MMDB依然沿用了檢查點技術(shù)，并在此基礎(chǔ)上，結(jié)合了影子內(nèi)存技術(shù)、模糊檢查點技術(shù)、多版本控制技術(shù)等[2，3]，這些方法的共同點都是減少undo日志的記錄。它們將MMDB的操作在影子頁上執(zhí)行，如果事務(wù)提交，則記錄redo日志，將影子頁的操作反映到MMDB，若事務(wù)撤銷，則只需放棄影子頁即可。這樣便可以不記錄undo日志，且雙版本可以提供數(shù)據(jù)庫的動態(tài)轉(zhuǎn)儲。

對于內(nèi)存數(shù)據(jù)庫，數(shù)據(jù)持久化也是重要一環(huán)。梁智興通過添加非易失性內(nèi)存作為備份緩沖區(qū)，提出兩步備份機(jī)制[4]；周曉云利用高速局域網(wǎng)充當(dāng)內(nèi)存緩沖區(qū)，提出了利用網(wǎng)絡(luò)工作站內(nèi)存加速內(nèi)存數(shù)據(jù)庫日志記錄持久化的技術(shù)方案[5]。這些都是對數(shù)據(jù)持久化的改進(jìn)。

2 Redis數(shù)據(jù)庫恢復(fù)技術(shù)概述

Redis數(shù)據(jù)庫是一種高效的內(nèi)存數(shù)據(jù)庫，它的數(shù)據(jù)恢復(fù)包括兩個步驟：數(shù)據(jù)持久化和數(shù)據(jù)恢復(fù)。Redis數(shù)據(jù)庫提供兩種持久化方式， RDB和AOF[6]。數(shù)據(jù)持久化生成的文件用于Redis數(shù)據(jù)庫重啟時的數(shù)據(jù)恢復(fù)。

2.1 RDB

RDB就是Snapshot快照存儲，是默認(rèn)的持久化方式。它按照一定的策略周期性的將數(shù)據(jù)存儲到磁盤，生成名為dump.rdb的文件，RDB的執(zhí)行周期可以通過配置文件中的save來配置[7]。

Redis數(shù)據(jù)庫會在達(dá)到RDB配置周期或接收到客戶端的save和bgsave命令時觸發(fā)RDB操作[8]。其中save觸發(fā)RDB操作時，Redis阻塞客戶端新的請求，是為靜態(tài)轉(zhuǎn)儲；而對于bgsave命令，Redis可以繼續(xù)接收處理新命令，是為動態(tài)轉(zhuǎn)儲。

RDB操作借用copy on write機(jī)制進(jìn)行寫時復(fù)制[9]，父進(jìn)程fork一個子進(jìn)程，由子進(jìn)程進(jìn)行內(nèi)存遍歷將數(shù)據(jù)寫入臨時文件，父進(jìn)程仍處理客戶端請求，待子進(jìn)程執(zhí)行完畢，將臨時文件rename為dump.rdb，因此無論RDB是否成功，dump.rdb都是完整的。

dump.rdb是一種緊湊的二進(jìn)制文件，文件很小利于備份，也常用于主從復(fù)制。RDB方式恢復(fù)速度快，但周期性的特點注定不能恢復(fù)兩個周期之間的數(shù)據(jù)。

2.2 AOF

AOF是一種追加性日志文件，Redis數(shù)據(jù)庫會將收到的所有寫命令按AOF文件協(xié)議順序追加到AOF文件中，因此AOF比RDB方式有更好的持久化性。在數(shù)據(jù)恢復(fù)時，Redis數(shù)據(jù)庫通過重新執(zhí)行AOF文件中保存的寫命令，在內(nèi)存中重建整個數(shù)據(jù)庫的內(nèi)容。

AOF可以通過在配置文件中設(shè)置appendonly為yes/no來開啟或關(guān)閉，還可以設(shè)置fsync為no/everysec/always來改變同步策略為關(guān)閉或每秒同步或每個寫操作同步。

AOF操作生成appendonly.aof，這是一種文本文件，按AOF協(xié)議記錄所有寫操作[10]。日志不斷追加，文件會越來越大，Redis提供了AOF重寫機(jī)制。AOF重寫在appendonly.aof增長到設(shè)定值或接收到bgrewriteaof命令時觸發(fā)。

AOF重寫由父進(jìn)程fork一個子進(jìn)程，子進(jìn)程遍歷數(shù)據(jù)庫內(nèi)存并將數(shù)據(jù)記錄到臨時文件，父進(jìn)程繼續(xù)接收客戶端請求，將后續(xù)寫操作追加到appendonly.aof和AOF重寫緩存，待子進(jìn)程執(zhí)行完畢，將緩存內(nèi)容追加到臨時文件，并rename為appendonly.aof完成重寫操作[11]。

AOF可以記錄所有寫操作，恢復(fù)時可以恢復(fù)全部數(shù)據(jù)，但日志文件體積較大，且恢復(fù)時需模擬客戶端重新執(zhí)行日志所記錄的操作，恢復(fù)速度較慢。

3 RDB+AOF的恢復(fù)方案

RDB恢復(fù)數(shù)據(jù)不完整，AOF恢復(fù)速度慢，為了解決這兩大問題，本文提出了RDB+AOF的方案。

3.1 方案簡介

RDB+AOF組合方案是指Redis同時開啟RDB和AOF選項，以AOF為主記錄日志，當(dāng)日志文件達(dá)到閾值觸發(fā)AOF重寫時，不再使用原有的重寫機(jī)制，而讓Redis服務(wù)fork一個子進(jìn)程執(zhí)行RDB操作，生成一個臨時RDB文件，主進(jìn)程依然接受客戶端請求，并將命令寫入AOF文件和一個臨時AOF文件中，待子進(jìn)程結(jié)束，將新生成的RDB臨時文件rename為dump.rdb，而將臨時AOF文件rename為appendonlyfile.aof，至此一次RDB+AOF組合的持久化就完成了。

持久化生成的RDB和AOF文件都將用來進(jìn)行數(shù)據(jù)恢復(fù)，恢復(fù)策略是首先Redis數(shù)據(jù)庫加載RDB文件，將數(shù)據(jù)庫恢復(fù)到最新一次快照時的狀態(tài)，然后模擬客戶端，將AOF文件中的命令執(zhí)行一遍，使數(shù)據(jù)庫恢復(fù)到上次關(guān)機(jī)或故障時的狀態(tài)，這樣數(shù)據(jù)庫的恢復(fù)就完成了。

RDB+AOF方案的具體執(zhí)行流程如圖1：

3.2 方案原理

要結(jié)合RDB和AOF兩種方案，需要分析一下RDB+AOF的可行性。

（1）基于命令執(zhí)行的數(shù)量觸發(fā)

RDB依據(jù)配置在一定時間內(nèi)完成一定的命令就會觸發(fā)，例如60秒內(nèi)修改了10000條記錄；而AOF是按AOF協(xié)議將命令記錄到日志文件，在文件大小達(dá)到閾值時觸發(fā)重寫，本質(zhì)也是完成一定的命令導(dǎo)致AOF重寫。

根據(jù)Redis命令的原子性，RDB和AOF重寫都將在完成命令的時刻執(zhí)行，因此執(zhí)行時不會有執(zhí)行一半的命令，保證了文件的完整性，也為RDB+AOF相結(jié)合提供了保障。

（2）copy on write機(jī)制

Copy on write機(jī)制是父子進(jìn)程共享同一物理內(nèi)存，即子進(jìn)程借用父進(jìn)程的內(nèi)存做遍歷操作，若此時父進(jìn)程接收到寫命令，父進(jìn)程會為寫命令影響到的內(nèi)存數(shù)據(jù)開辟新內(nèi)存，寫命令所造成的臟數(shù)據(jù)只會影響到這塊新開辟的內(nèi)存，子進(jìn)程使用的依舊是RDB或AOF重寫開始時的內(nèi)存空間，這種寫時復(fù)制機(jī)制完美解決了動態(tài)復(fù)制的問題。

RDB和AOF重寫都使用copy on write機(jī)制，這為RDB+AOF方案中用RDB代替AOF重寫提供了保障。

（3）非事務(wù)一致性

Redis雖然提供簡單的事務(wù)支持，但并不提供回滾功能，也就是不保證事務(wù)一致性，因此日志并不需要記錄undo日志。因此RDB和AOF文件本質(zhì)都是數(shù)據(jù)的映像，沒有什么區(qū)別，為RDB+AOF方案提供了便利條件。

（4）日志的追加性

日志文件是按時間追加的，在RDB+AOF方案中，檢查點之前的日志對數(shù)據(jù)恢復(fù)已經(jīng)沒有作用，可以刪掉減小文件體積，這就是用AOF臨時文件覆蓋原文件對理論支持。

3.3 對照試驗

本次實驗有三個目標(biāo)：數(shù)據(jù)持久化速度、數(shù)據(jù)恢復(fù)速度和數(shù)據(jù)恢復(fù)完整性。

本實驗的實驗環(huán)境為Mac OS X 10.11.1系統(tǒng)，2.7 GHz Intel Core i5處理器，8G內(nèi)存以及Redis3.0.7。

3.3.1 數(shù)據(jù)持久化速度

數(shù)據(jù)持久化速度以寫入相同數(shù)據(jù)量所用時間來計算。如圖2為分別寫入100、10000、100000、1000000條數(shù)據(jù)時RDB、AOF以及RDB+AOF三種方案的耗時情況。

圖2中AOF方式的同步策略為每秒同步，由圖中可以看出每秒同步的AOF方式與RDB方式在持久化方面性能相差不大，而RDB+AOF方案是以AOF為主要持久化方案，只在AOF重寫時由RDB代替，因而性能接近AOF方式。

3.3.2 數(shù)據(jù)恢復(fù)速度

數(shù)據(jù)恢復(fù)速度以加載相同數(shù)據(jù)量所用時間來表示。對數(shù)據(jù)持久化所得文件進(jìn)行加載，得到三種方式加載時間的對比，如圖3所示：

從圖中可以看出，三種方式數(shù)據(jù)恢復(fù)速度相差很大，AOF方式恢復(fù)速度是RDB方式的2倍左右，而RDB+AOF方式恢復(fù)速度介于兩者之間。

比較RDB和AOF兩種方式對相同數(shù)據(jù)持久化產(chǎn)生的文件大小，如表1所示：

表中所示AOF文件是RDB文件的2倍左右，這也可以解釋為何AOF方式恢復(fù)時間是RDB方式的2倍。

而RDB+AOF方式的恢復(fù)速度介于兩者之間，具體情況如表2所示：

從表2中可以看出，RDB+AOF方式隨著RDB和AOF文件大小的比例在變化，在RDB+AOF方案中，隨著AOF重寫，數(shù)據(jù)不斷從AOF文件轉(zhuǎn)移到RDB文件，它的恢復(fù)時間也從AOF方式向RDB方式的方向不斷減少，理想狀態(tài)下將達(dá)到RDB方式的恢復(fù)速度。

3.3.3 數(shù)據(jù)恢復(fù)完整性

數(shù)據(jù)恢復(fù)完整性以恢復(fù)的數(shù)據(jù)量為準(zhǔn)。對三種方案分別寫入5條新數(shù)據(jù)，然后kill掉Redis服務(wù)，重啟服務(wù)后檢查新數(shù)據(jù)的恢復(fù)情況，如表3所示：

從表中可以看出，RDB+AOF方案完美繼承了AOF恢復(fù)數(shù)據(jù)完整性的優(yōu)點。

4 結(jié)論

本文借鑒檢查點恢復(fù)方法的思想，在Redis數(shù)據(jù)庫中，巧妙地結(jié)合了RDB和AOF兩種方法，利用AOF日志完整記錄數(shù)據(jù)庫操作，又通過RDB代替AOF重寫，利用RDB文件恢復(fù)速度快的特性減少了恢復(fù)時間。RDB+AOF恢復(fù)方案，能夠在完整恢復(fù)數(shù)據(jù)庫的前提下提高恢復(fù)速度，在持久化時，數(shù)據(jù)會隨AOF重寫從AOF文件轉(zhuǎn)移到RDB文件，理想情況下可以達(dá)到RDB的恢復(fù)速度。但重寫本身也是一個耗時操作，數(shù)據(jù)持久化需要和數(shù)據(jù)恢復(fù)達(dá)到平衡，才能達(dá)到最合適的用戶體驗，這將是進(jìn)一步的研究方向。

參考文獻(xiàn)：

[1] 周如意. 基于檢查點的數(shù)據(jù)庫恢復(fù)技術(shù)[J]. 沙洲職業(yè)工學(xué)院學(xué)報， 2006（2）：11-14.

[2] 黃琳， 路京， 林中. 基于影子頁面的MMDB的數(shù)據(jù)恢復(fù)方法[J]. 計算機(jī)工程與設(shè)計， 2008， 29（10）：2470-2473.

[3] 杜曄. 空間實時內(nèi)存數(shù)據(jù)庫恢復(fù)機(jī)制研究與實現(xiàn)[D]. 中國科學(xué)院研究生院， 2012.

[4] 梁智興， 羅軍. 基于兩步備份機(jī)制的內(nèi)存數(shù)據(jù)庫恢復(fù)方法研究[J]. 網(wǎng)絡(luò)安全技術(shù)與應(yīng)用， 2010（1）：24-27.

[5] 周曉云， 覃雄派. 基于網(wǎng)絡(luò)內(nèi)存的內(nèi)存數(shù)據(jù)庫高效恢復(fù)技術(shù)[J]. 系統(tǒng)工程理論與實踐， 2011， 系統(tǒng)工程理論與實踐， 2011， 31（增刊2）：81-87（S2）：81-87.

[6] 馬豫星. Redis數(shù)據(jù)庫特性分析[J]. 物聯(lián)網(wǎng)技術(shù)， 2015（3）：105-106.

[7] Hey！ Linux. Redis持久化實踐及災(zāi)難恢復(fù)模擬[EB/OL]. http：//heylinux.com/archives/1932.html， 2012-09-27.

[8] 常飛夢. 驗證redis的快照和AOF[EB/OL]. http：//blog.csdn.net/lichangzai/article/details/8692103， 2013-03-19.

[9] 婁振林專欄. redis源碼分析（7）——rdb[EB/OL]. http：//blog.csdn.net/chosen0ne/article/details/44650847/， 2015-04-15.

[10] 婁振林專欄. redis源碼分析（5）——aof[EB/OL]. http：//blog.csdn.net/chosen0ne/article/details/44035453/， 2015-03-17.

[11] 婁振林專欄. redis源碼分析（6）——aof rewrite[EB/OL]. http：//blog.csdn.net/chosen0ne/article/details/44461497/， 2015-03-23.