redis支持RDB和AOF兩種持久化機(jī)制，持久化功能有效地避免因進(jìn)程退出造成的數(shù)據(jù)丟失問題，當(dāng)下次重啟時利用之前持久化的文件即可實(shí)現(xiàn)數(shù)據(jù)恢復(fù)。理解掌握持久化機(jī)制對于Redis運(yùn)維非常重要。

創(chuàng)新互聯(lián)公司專業(yè)為企業(yè)提供稷山網(wǎng)站建設(shè)、稷山做網(wǎng)站、稷山網(wǎng)站設(shè)計(jì)、稷山網(wǎng)站制作等企業(yè)網(wǎng)站建設(shè)、網(wǎng)頁設(shè)計(jì)與制作、稷山企業(yè)網(wǎng)站模板建站服務(wù)，10多年稷山做網(wǎng)站經(jīng)驗(yàn)，不只是建網(wǎng)站，更提供有價值的思路和整體網(wǎng)絡(luò)服務(wù)。

    首先介紹RDB、AOF的配置和運(yùn)行流程，以及控制持久化的相關(guān)命令，如bgsave和bgrewriteaof。

RDB

RDB持久化是把當(dāng)前進(jìn)程數(shù)據(jù)生成快照保存到硬盤的過程，觸發(fā)RDB持久化過程分為手動觸發(fā)和自動觸發(fā)。

觸發(fā)機(jī)制

手動觸發(fā)分別對應(yīng)save和bgsave命令：

save命令：阻塞當(dāng)前Redis服務(wù)器，直到RDB過程完成為止，對于內(nèi)存比較大的實(shí)例會造成長時間阻塞，線上環(huán)境不建議使用。運(yùn)行save命令對應(yīng)的Redis日志如下：

1283:M 04 Apr 21:39:03.035 * DB saved on disk

bgsave命令：Redis進(jìn)程執(zhí)行fork操作創(chuàng)建子進(jìn)程，RDB持久化過程由子進(jìn)程負(fù)責(zé)，完成后自動結(jié)束。阻塞只發(fā)生在fork階段，一般時間很短。運(yùn)行bgsave命令對應(yīng)的Redis日志如下：

1283:M 04 Apr 21:40:33.849 * Background saving started by pid 1429
1429:C 04 Apr 21:40:33.874 * DB saved on disk
1429:C 04 Apr 21:40:33.875 * RDB: 6 MB of memory used by copy-on-write
1283:M 04 Apr 21:40:33.929 * Background saving terminated with success

顯然bgsave命令是針對save阻塞問題做的優(yōu)化。因此Redis內(nèi)部所有的涉及RDB的操作都采用bgsave的方式，而save命令已經(jīng)廢棄。

除了執(zhí)行命令手動觸發(fā)之外，Redis內(nèi)部還存在自動觸發(fā)RDB的持久化機(jī)制，例如以下場景：

1)使用save相關(guān)配置，如"save m n"。表示m秒內(nèi)數(shù)據(jù)集存在n次修改時，自動觸發(fā)bgsave。

2)如果從節(jié)點(diǎn)執(zhí)行全量復(fù)制操作，主節(jié)點(diǎn)自動執(zhí)行bgsave生成RDB文件并發(fā)送給從節(jié)點(diǎn)。

3)執(zhí)行debug reload命令重新加載Redis時，也會自動觸發(fā)save操作。

4)默認(rèn)情況下執(zhí)行shutdown命令時，如果沒有開啟AOF持久化功能則自動執(zhí)行bgsave。

                注：如果想關(guān)閉自動RDB持久化，在配置文件刪除"save m n"的配置

流程說明

bgsave是主流的觸發(fā)RDB持久化方式，下面根據(jù)下圖了解它的運(yùn)作流程。

1)執(zhí)行bgsave命令，Redis父進(jìn)程判斷當(dāng)前是否存在正在執(zhí)行的子進(jìn)程，如RDB/AOF子進(jìn)程，如果存在bgsave命令直接返回。

2)父進(jìn)程執(zhí)行fork操作創(chuàng)建子進(jìn)程，fork操作過程中父進(jìn)程會阻塞，通過info stats命令查看latest_fork_usec選項(xiàng)，可以獲取最近一個ork操作的耗時，單位為微秒。

3)父進(jìn)程fork完成后，bgsave命令返回"Background saving started"信息并不再阻塞父進(jìn)程，可以繼續(xù)響應(yīng)其他命令。

4)子進(jìn)程創(chuàng)建RDB文件，根據(jù)父進(jìn)程內(nèi)存生成臨時快照文件，完成對原有文件執(zhí)行原子替換。執(zhí)行l(wèi)astsave命令可以獲取最后一次生成RDB的時間，對應(yīng)info統(tǒng)計(jì)的rdb_last_save_time選項(xiàng)。

5)進(jìn)程發(fā)送信號給父進(jìn)程表示完成，父進(jìn)程更新統(tǒng)計(jì)信息，具體見info Persistence下的rdb_*相關(guān)選項(xiàng)。

RDB文件的處理

保存:RDB文件保存在dir配置指定的目錄下，文件名通過dbfilename配置指定?？梢酝ㄟ^執(zhí)行config set dir {newDir}和config set dbfilename {newFileName}運(yùn)行期動態(tài)執(zhí)行，當(dāng)下次運(yùn)行時RDB會保存到新目錄。

當(dāng)遇到壞盤或磁盤寫滿等待情況時，可以通過config set dir {newDir}在線修改文件路徑到可用的磁盤路徑，之后執(zhí)行bgsave進(jìn)行bgsave進(jìn)程磁盤切換，同樣適用于AOF持久化文件。

壓縮：Redis默認(rèn)采用LZF算法對生成的RDB文件做壓縮處理，壓縮后的文件遠(yuǎn)遠(yuǎn)小于內(nèi)存大小，默認(rèn)開啟，可以通過config set rdbcompression {yes|no}動態(tài)修改。

雖然壓縮RDB會消耗CPU，但可大幅降低文件的體積，方便保存到硬盤或通過網(wǎng)絡(luò)發(fā)送給從節(jié)點(diǎn)，因此線上建議開啟。

校驗(yàn)：如果Redis加載損壞的RDB文件時拒絕啟動，并打印如下日志：

2740:M 04 Apr 22:06:42.835 # Short read or OOM loading DB. Unrecoverable error, aborting now.
2740:M 04 Apr 22:06:42.835 # Internal error in RDB reading function at rdb.c:1666 -> Unexpected EOF reading RDB file

可以使用Redis提供的redis-check-rdb工具檢測RDB文件并獲取對應(yīng)用的錯誤報(bào)告。

[redis@rhel7 ~]$ redis-check-rdb dump.rdb 
[offset 0] Checking RDB file dump.rdb
[offset 27] AUX FIELD redis-ver = '4.0.13'
[offset 41] AUX FIELD redis-bits = '64'
[offset 53] AUX FIELD ctime = '1554386780'
[offset 68] AUX FIELD used-mem = '570072'
[offset 84] AUX FIELD aof-preamble = '0'
[offset 86] Selecting DB ID 0
--- RDB ERROR DETECTED ---
[offset 109] Invalid object type: 209
[additional info] While doing: read-type
[info] 2 keys read
[info] 0 expires
[info] 0 already expired

RDB的優(yōu)缺點(diǎn)

優(yōu)點(diǎn)：RDB是一個緊湊壓縮的二進(jìn)程文件，代表Redis在某個時間點(diǎn)上的數(shù)據(jù)快照。非常適用于備份，全量復(fù)制等場景。比如第6小時執(zhí)行bgsave備份，并把RDB文件拷貝到遠(yuǎn)程機(jī)器或者文件系統(tǒng)中(如hdfs)，用于災(zāi)難恢復(fù)。Redis加載RDB恢復(fù)數(shù)據(jù)遠(yuǎn)遠(yuǎn)快于AOF的方式。

缺點(diǎn)：RDB方式數(shù)據(jù)沒辦法做到實(shí)時持久化/秒級持久化。因?yàn)閎gsave每次運(yùn)行都要執(zhí)行fork操作創(chuàng)建子進(jìn)程，屬于重量級操作，頻繁執(zhí)行成本過高。RDB文件使用特定二進(jìn)程格式保存，Redis版本演進(jìn)過程中有多個格式的RDB版本，存在老版本Redis服務(wù)無法兼容新版RDB格式的問題。

針對RDB不短途實(shí)時持久化的問題，Redis提供了AOF持久化方式來解決。

AOF

AOF(append only file)持久化：以獨(dú)立日志的方式記錄每次寫命令，重啟時再重新執(zhí)行AOF文件中的命令達(dá)到恢復(fù)數(shù)據(jù)的目的。AOF的主要作用是解決了數(shù)據(jù)持久化的實(shí)時性，目前已經(jīng)是Redis持久化的主流方式。理解掌握好AOF持久化機(jī)制對我們兼顧數(shù)據(jù)安全性和性能非常有幫助。

使用AOF

開啟AOF功能需要設(shè)置參數(shù):appendonly yes，默認(rèn)不開啟。AOF文件名通過appendfilename參數(shù)設(shè)置，默認(rèn)文件名是appendonly.aof。保存路徑同RDB持久化方式一致，通過dir配置指定。AOF的工作流程操作：命令寫入(append)、文件同步(sync)、文件重寫(rewrite)、重啟加載(load)，如下圖：

流程如下：

1)所有的寫入命令會追加到aof_buf(緩沖區(qū))中。

2)AOF緩沖區(qū)根據(jù)對應(yīng)的策略向硬盤做同步操作。

3)隨著AOF文件越來越大，需要定期對AOF文件進(jìn)行重寫，達(dá)到壓縮的目的。

4)當(dāng)Redis服務(wù)器重啟時，可以加載AOF文件進(jìn)行數(shù)據(jù)恢復(fù)。

了解AOF工作流程之后，下面針對每個步驟做詳細(xì)介紹。

命令寫入

AOF命令寫入的內(nèi)容直接是文本協(xié)議格式。例如set hello world這條命令，在AOF緩沖區(qū)會追加如下文本

*3
$3
set
$5
hello
$5
world

關(guān)于AOF的兩個疑惑：

1)AOF為什么直接采用文本協(xié)議格式？可能的理由如下：

文本協(xié)議具有很好的兼容性。

開啟AOF后，所有寫入命令都包含追加操作，直接采用協(xié)議格式，避免了二次處理開銷。

文本協(xié)議具有可讀性，方便直接修改和處理。

2)AOF為什么把命令追加到aof_buf中？Redis使用單線程響應(yīng)命令，如果每次寫AOF文件命令都直接追加到硬盤，那么性能完全取決于當(dāng)前硬盤負(fù)載。先寫入緩沖區(qū)aof_buf中，還有另一個好處，Redis可以提供多種緩沖區(qū)同步硬盤的策略，在性能和安全性方面做出平衡。

文件同步

Redis提供了多種AOF緩沖區(qū)同步文件策略，由參數(shù)appendfsync控制，不同的含義如下：

always：命令寫入aof_buf后調(diào)用系統(tǒng)fsync操作同步到AOF文件，fsync完成后線程返回

everysec：命令寫入aof_buf后調(diào)用系統(tǒng)write操作，write完成后線程返回。fsync同步文件操作由專門線程每秒調(diào)用一次

no：命令寫入aof_buf后調(diào)用系統(tǒng)write操作，不對AOF文件做fsync同步，同步硬盤操作由操作系統(tǒng)負(fù)責(zé)，通常同步周期最長30秒

系統(tǒng)調(diào)用write和fsync說明：

write操作會觸發(fā)延遲寫(delayed write)機(jī)制。Linux在內(nèi)核操作頁緩沖區(qū)用來提高硬盤IO性能。write操作在寫入系統(tǒng)緩沖區(qū)后直接返回。同步硬盤操作依賴于系統(tǒng)調(diào)度機(jī)制，例如：緩沖區(qū)頁空間寫滿或達(dá)到特定時間周期。同步文件之前，如果此時系統(tǒng)故障宕機(jī)，緩沖區(qū)內(nèi)數(shù)據(jù)將丟失。

fsync針對單個文件操作(比如AOF文件)，做強(qiáng)制硬盤同步，fsync將阻塞直到寫入硬盤完成后返回，保證了數(shù)據(jù)持久化。

除了write、fsync、Linux還提供了sync、fdatasync操作。

配置為always時，每次寫入都要同步AOF文件，在一般的SATA硬盤上，Redis只能支持大約幾百TPS寫入，顯然跟Redis高性能特性背道而馳，不建議配置。

配置為no，由于操作系統(tǒng)每次同步AOF文件的周期不可控，而且會加大每次同步硬盤的數(shù)據(jù)量，雖然提升了性能，但數(shù)據(jù)安全性無法保證。

配置為everysec，是建議的同步策略，也是默認(rèn)配置，做到兼顧性能和數(shù)據(jù)安全性。理論上只有在系統(tǒng)突然宕機(jī)的情況下丟失1秒的數(shù)據(jù)。(嚴(yán)格來說最多丟失1it數(shù)據(jù)是不準(zhǔn)確的)。

重寫機(jī)制

隨著命令不斷寫入AOF，文件會越來越大，為了解決這個問題，Redis引入AOF重寫機(jī)制壓縮文件體積。AOF文件重寫是把Redis進(jìn)程內(nèi)的數(shù)據(jù)轉(zhuǎn)化為寫命令同步到新AOF文件的過程。

重寫后的AOF文件為什么可以變??？有如下原因：

1)進(jìn)程內(nèi)已經(jīng)超時的數(shù)據(jù)不再寫入文件

2)舊的AOF文件含有有效命令，如del key1、hdel key2、srem keys、set a111、set a222等。重寫使用進(jìn)程內(nèi)數(shù)據(jù)直接生成，這樣新的AOF文件只保留最終數(shù)據(jù)的寫入命令。

3)多條寫命令可以合并為一下，如：lpush list a、lpush list b、lpush list c可以轉(zhuǎn)化為:lpush list a b c。為了防止單條命令過大造成客戶端緩沖區(qū)溢出，對于list、set、hash、zset等類型操作，以64個元素為界拆分為多條。

AOF重寫降低了文件占用空間，除此之外，另一個目的是：更小的AOF文件可以更快被Redis加載。

AOF重寫過程可以手動觸發(fā)和自動觸發(fā)：

手動觸發(fā)：直接調(diào)用bgrewriteaof命令

自動觸發(fā)：根據(jù)auto-aof-rewrite-min-size和auto-aof-rewrite-percentage參數(shù)確定自動觸發(fā)時機(jī)。

auto-aof-rewrite-min-size：表示運(yùn)行AOF重寫時文件最小體積，默認(rèn)為64M。

auto-aof-rewrite-percentage：代表當(dāng)前AOF文件空間(aof_current_size)和上一次重寫后AOF文件(aof_base_size)的比值。

自動觸發(fā)時間=aof_current_size>auto-aof-rewrite-min-size && (aof_current_size-aof_base_size)/aof_base_size>=auto-aof-rewrite-percentage

其中aof_current_size和aof_base_size可以在info Persistence統(tǒng)計(jì)信息中查看。

        自動觸發(fā)AOF重寫，會輸出如下日志：

18827:M 04 Apr 23:30:49.519 * Starting automatic rewriting of AOF on 1054% growth
18827:M 04 Apr 23:30:49.520 * Background append only file rewriting started by pid 21365
18827:M 04 Apr 23:30:50.617 * AOF rewrite child asks to stop sending diffs.
21365:C 04 Apr 23:30:50.618 * Parent agreed to stop sending diffs. Finalizing AOF...
21365:C 04 Apr 23:30:50.618 * Concatenating 0.03 MB of AOF diff received from parent.
21365:C 04 Apr 23:30:50.631 * SYNC append only file rewrite performed
21365:C 04 Apr 23:30:50.632 * AOF rewrite: 7 MB of memory used by copy-on-write
18827:M 04 Apr 23:30:50.641 * Background AOF rewrite terminated with success
18827:M 04 Apr 23:30:50.641 * Residual parent diff successfully flushed to the rewritten AOF (0.00 MB)
18827:M 04 Apr 23:30:50.641 * Background AOF rewrite finished successfully

當(dāng)觸發(fā)AOF重寫時，內(nèi)存做了哪些事呢？結(jié)合下圖介紹運(yùn)行流程

流程說明：

1)執(zhí)行AOF重寫請示

如果當(dāng)前進(jìn)程正在執(zhí)行AOF重寫，請求不執(zhí)行并返回如下響應(yīng)：

(error) ERR Background append only file rewriting already in progress

如果當(dāng)前進(jìn)程正在執(zhí)行bgsave操作，重寫命令延遲到bgsave完成之后再執(zhí)行，返回如下響應(yīng)：

Background append only file rewriting scheduled

2) 父進(jìn)程進(jìn)程fork創(chuàng)建子進(jìn)程，開銷等同于bgsave過程。

3.1) 主進(jìn)程fork操作完成后，繼續(xù)響應(yīng)其他命令。所有修改命令依然寫入AOF緩沖區(qū)并根據(jù)appendfsync策略同步到硬盤，保證原有AOF機(jī)制正確性。

3.2)由于fork操作運(yùn)用寫時復(fù)制技術(shù)，子進(jìn)程只能共享fork操作時的內(nèi)存數(shù)據(jù)。由于父進(jìn)程依然響應(yīng)命令，Redis使用"AOF重寫緩沖區(qū)"保存這部分新數(shù)據(jù)，防止新AOF文件生成期間丟失這部分?jǐn)?shù)據(jù)。

4)子進(jìn)程根據(jù)內(nèi)存快照，執(zhí)照命令合并規(guī)則寫入到新的AOF文件。每次批量寫入硬盤數(shù)據(jù)量由配置aof-rewrite-incremental-fsync控制，默認(rèn)為32MB，防止單次刷盤數(shù)據(jù)過多造成硬盤阻塞。

5.1)新AOF文件寫入完成后，子進(jìn)程發(fā)送信號給父進(jìn)程，父進(jìn)程更新統(tǒng)計(jì)信息，具體見info persistence下的aof_*相關(guān)統(tǒng)計(jì)。

5.2)父進(jìn)程把AOF重寫緩沖區(qū)的數(shù)據(jù)寫入到新的AOF文件。

5.3)使用新AOF文件替換老文件，完成AOF重寫。

重啟加載

AOF和RDB文件都可以用于服務(wù)器重啟時的數(shù)據(jù)恢復(fù)。如下圖所示，表示Redis持久化文件加載流程。

流程說明：

1)AOF持久化開啟且存在AOF文件時，優(yōu)先加載AOF文件，打印如下日志

18827:M 04 Apr 23:21:01.257 * DB loaded from append only file: 1.207 seconds

2)AOF關(guān)閉或AOF文件不存在時，加載RDB文件，打印如下日志：

7792:M 01 Apr 22:33:58.418 * DB loaded from disk: 0.003 seconds

3)加載AOF/RDB文件成功后，Redis啟動成功

4)AOF/RDB文件存在錯誤時，Redistribute啟動失敗并打印錯誤信息。

文件校驗(yàn)

加載損壞的AOF文件時會拒絕啟動，并打印如下日志：

Bad file format reading the append only file: make a backup of your AOF file,then use ./redis-check-aof --fix <filename>

對于錯誤格式的AOF文件，先進(jìn)行備份，然后采用redis-check-aof --fix命令進(jìn)行修復(fù)，修復(fù)后使用diff -u對比數(shù)據(jù)的差異，找出丟失的數(shù)據(jù)，有些可以人工修改補(bǔ)全。

AOF文件可能存在結(jié)尾不完整的情況，比如機(jī)器突然掉電導(dǎo)致AOF尾部命令寫入不全。Redis為我們提供了aof-load-truncated配置來兼容這種情況，默認(rèn)開啟。加載AOF時，當(dāng)遇到此問題時會忽略并繼續(xù)啟動，同時打印如下警告日志：

27752:M 04 Apr 23:47:34.655 # !!! Warning: short read while loading the AOF file !!!
27752:M 04 Apr 23:47:34.655 # !!! Truncating the AOF at offset 1377811 !!!
27752:M 04 Apr 23:47:34.655 # AOF loaded anyway because aof-load-truncated is enabled

博文內(nèi)容摘自《Redis開發(fā)與運(yùn)維》一書。

文章名稱：學(xué)習(xí)Redis持久化
文章路徑：http://jinyejixie.com/article18/psiidp.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供標(biāo)簽優(yōu)化、網(wǎng)站改版、Google、網(wǎng)站設(shè)計(jì)公司、營銷型網(wǎng)站建設(shè)、全網(wǎng)營銷推廣

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)