張文帥

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

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

中圖分類號：TP391 文獻標識碼：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ù)庫技術的發(fā)展，帶動了NoSQL（非關系數(shù)據(jù)庫）的崛起，其中Redis（REmote DIctionary Server）數(shù)據(jù)庫因其高效性得到廣泛應用。它是一個用C語言編寫的開源的內(nèi)存數(shù)據(jù)庫，支持數(shù)據(jù)持久化。

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

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

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

1.1 關系數(shù)據(jù)庫恢復技術

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

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

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

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

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

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

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

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

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

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

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

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

2.1 RDB

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

Redis數(shù)據(jù)庫會在達到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機制進行寫時復制[9]，父進程fork一個子進程，由子進程進行內(nèi)存遍歷將數(shù)據(jù)寫入臨時文件，父進程仍處理客戶端請求，待子進程執(zhí)行完畢，將臨時文件rename為dump.rdb，因此無論RDB是否成功，dump.rdb都是完整的。

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

2.2 AOF

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

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

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

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

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

3 RDB+AOF的恢復方案

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

3.1 方案簡介

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

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

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é)議將命令記錄到日志文件，在文件大小達到閾值時觸發(fā)重寫，本質(zhì)也是完成一定的命令導致AOF重寫。

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

（2）copy on write機制

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

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

（3）非事務一致性

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

（4）日志的追加性

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

3.3 對照試驗

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

本實驗的實驗環(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ù)恢復速度

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

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

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

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

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

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

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

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

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

4 結(jié)論

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

參考文獻：

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

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

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

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

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

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

[7] Hey！ Linux. Redis持久化實踐及災難恢復模擬[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.