[轉]Redis持久化存儲(AOF與RDB兩種模式)

Redis中數據存儲模式有2種：cache-only,persistence;

cache-only即只做為“緩存”服務，不持久數據，數據在服務終止后將消失，此模式下也將不存在“數據恢復”的手段，是一種安全性低/效率高/容易擴展的方式；
persistence即為內存中的數據持久備份到磁盤文件，在服務重啟后可以恢復，此模式下數據相對安全。

對于persistence持久化存儲，Redis提供了兩種持久化方法：

Redis DataBase(簡稱RDB)
Append-only file (簡稱AOF)

除了這兩種方法，Redis在早起的版本還存在虛擬內存的方法，現在已經被廢棄。

一、RDB概述

RDB是在某個時間點將數據寫入一個臨時文件，持久化結束后，用這個臨時文件替換上次持久化的文件，達到數據恢復。
優點：使用單獨子進程來進行持久化，主進程不會進行任何IO操作，保證了redis的高性能
缺點：RDB是間隔一段時間進行持久化，如果持久化之間redis發生故障，會發生數據丟失。所以這種方式更適合數據要求不嚴謹的時候

這里說的這個執行數據寫入到臨時文件的時間點是可以通過配置來自己確定的，通過配置redis在n秒內如果超過m個key被修改這執行一次RDB操作。這個操作就類似于在這個時間點來保存一次Redis的所有數據，一次快照數據。所有這個持久化方法也通常叫做snapshots。

RDB默認開啟，redis.conf中的具體配置參數如下；

#dbfilename：持久化數據存儲在本地的文件
dbfilename dump.rdb
#dir：持久化數據存儲在本地的路徑，如果是在/redis/redis-3.0.6/src下啟動的redis-cli，則數據會存儲在當前src目錄下
dir ./
##snapshot觸發的時機，save <seconds> <changes>  
##如下為900秒后，至少有一個變更操作，才會snapshot  
##對于此值的設置，需要謹慎，評估系統的變更操作密集程度  
##可以通過“save “””來關閉snapshot功能  
#save時間，以下分別表示更改了1個key時間隔900s進行持久化存儲；更改了10個key300s進行存儲；更改10000個key60s進行存儲。
save 900 1
save 300 10
save 60 10000
##當snapshot時出現錯誤無法繼續時，是否阻塞客戶端“變更操作”，“錯誤”可能因為磁盤已滿/磁盤故障/OS級別異常等  
stop-writes-on-bgsave-error yes  
##是否啟用rdb文件壓縮，默認為“yes”，壓縮往往意味著“額外的cpu消耗”，同時也意味這較小的文件尺寸以及較短的網絡傳輸時間  
rdbcompression yes

snapshot觸發的時機，是有“間隔時間”和“變更次數”共同決定，同時符合2個條件才會觸發snapshot,否則“變更次數”會被繼續累加到下一個“間隔時間”上。snapshot過程中并不阻塞客戶端請求。snapshot首先將數據寫入臨時文件，當成功結束后，將臨時文件重名為dump.rdb。

使用RDB恢復數據：
RDB文件的載入工作是在服務器啟動時自動執行的，并沒有專門的命令。但是由于AOF的優先級更高，因此當AOF開啟時，Redis會優先載入AOF文件來恢復數據；只有當AOF關閉時，才會在Redis服務器啟動時檢測RDB文件，并自動載入。服務器載入RDB文件期間處于阻塞狀態，直到載入完成為止。

Redis載入RDB文件時，會對RDB文件進行校驗，如果文件損壞，則日志中會打印錯誤，Redis啟動失敗。

客戶端使用命令進行手動持久化save存儲：

./redis-cli -h ip -p port save
./redis-cli -h ip -p port bgsave

一個是在前臺進行存儲，一個是在后臺進行存儲。我的client就在server這臺服務器上，所以不需要連其他機器，直接./redis-cli bgsave。由于redis是用一個主線程來處理所有 client的請求，這種方式會阻塞所有client請求。所以不推薦使用。另一點需要注意的是，每次快照持久化都是將內存數據完整寫入到磁盤一次，并不是增量的只同步臟數據。如果數據量大的話，而且寫操作比較多，必然會引起大量的磁盤io操作，可能會嚴重影響性能。

其他自動觸發機制:

除了save m n 以外和手動調用命令外，還有一些其他情況會觸發bgsave：

在主從復制場景下，如果從節點執行全量復制操作，則主節點會執行bgsave命令，并將rdb文件發送給從節點
執行shutdown命令時，自動執行rdb持久化

save m n的實現原理

Redis的save m n，是通過serverCron函數、dirty計數器、和lastsave時間戳來實現的。

serverCron是Redis服務器的周期性操作函數，默認每隔100ms執行一次；該函數對服務器的狀態進行維護，其中一項工作就是檢查 save m n 配置的條件是否滿足，如果滿足就執行bgsave。

dirty計數器是Redis服務器維持的一個狀態，記錄了上一次執行bgsave/save命令后，服務器狀態進行了多少次修改(包括增刪改)；而當save/bgsave執行完成后，會將dirty重新置為0。

例如，如果Redis執行了set mykey helloworld，則dirty值會+1；如果執行了sadd myset v1 v2 v3，則dirty值會+3；注意dirty記錄的是服務器進行了多少次修改，而不是客戶端執行了多少修改數據的命令。

lastsave時間戳也是Redis服務器維持的一個狀態，記錄的是上一次成功執行save/bgsave的時間。

save m n的原理如下：每隔100ms，執行serverCron函數；在serverCron函數中，遍歷save m n配置的保存條件，只要有一個條件滿足，就進行bgsave。對于每一個save m n條件，只有下面兩條同時滿足時才算滿足：

當前時間-lastsave > m
dirty >= n

snapshot執行流程

在這里插入圖片描述

Redis父進程首先判斷：當前是否在執行save，或bgsave/bgrewriteaof（后面會詳細介紹該命令）的子進程，如果在執行則bgsave命令直接返回。bgsave/bgrewriteaof 的子進程不能同時執行，主要是基于性能方面的考慮：兩個并發的子進程同時執行大量的磁盤寫操作，可能引起嚴重的性能問題。

父進程執行fork操作創建子進程，這個過程中父進程是阻塞的，Redis不能執行來自客戶端的任何命令

父進程fork后，bgsave命令返回”Background saving started”信息并不再阻塞父進程，并可以響應其他命令

子進程創建RDB文件，根據父進程內存快照生成臨時快照文件，完成后對原有文件進行原子替換

子進程發送信號給父進程表示完成，父進程更新統計信息

RDB常用配置總結

下面是RDB常用的配置項，以及默認值:

save m n：bgsave自動觸發的條件；如果沒有save m n配置，相當于自動的RDB持久化關閉，不過此時仍可以通過其他方式觸發

stop-writes-on-bgsave-error yes：當bgsave出現錯誤時，Redis是否停止執行寫命令；設置為yes，則當硬盤出現問題時，可以及時發現，避免數據的大量丟失；設置為no，則Redis無視bgsave的錯誤繼續執行寫命令，當對Redis服務器的系統(尤其是硬盤)使用了監控時，該選項考慮設置為no

rdbcompression yes：是否開啟RDB文件壓縮。Redis默認采用LZF算法對RDB文件進行壓縮。雖然壓縮耗時，但是可以大大減小RDB文件的體積，因此壓縮默認開啟；可以通過命令關閉

rdbchecksum yes：是否開啟RDB文件的校驗，在寫入文件和讀取文件時都起作用；關閉checksum在寫入文件和啟動文件時大約能帶來10%的性能提升，但是數據損壞時無法發現

dbfilename dump.rdb：RDB文件名

dir ./：RDB文件和AOF文件所在目錄

二、AOF概述

Append-only file，將“操作 + 數據”以格式化指令的方式追加到操作日志文件的尾部，在append操作返回后(已經寫入到文件或者即將寫入)，才進行實際的數據變更，“日志文件”保存了歷史所有的操作過程；當server需要數據恢復時，可以直接replay此日志文件，即可還原所有的操作過程。AOF相對可靠，它和mysql中bin.log、apache.log、zookeeper中txn-log簡直異曲同工。AOF文件內容是字符串，非常容易閱讀和解析。

優點：可以保持更高的數據完整性，如果設置追加file的時間是1s，如果redis發生故障，最多會丟失1s的數據；且如果日志寫入不完整支持redis-check-aof來進行日志修復；AOF文件沒被rewrite之前（文件過大時會對命令進行合并重寫），可以刪除其中的某些命令（比如誤操作的flushall）。

缺點：AOF文件比RDB文件大，且恢復速度慢。

我們可以簡單的認為AOF就是日志文件，此文件只會記錄“變更操作”(例如：set/del等)，如果server中持續的大量變更操作，將會導致AOF文件非常的龐大，意味著server失效后，數據恢復的過程將會很長；事實上，一條數據經過多次變更，將會產生多條AOF記錄，其實只要保存當前的狀態，歷史的操作記錄是可以拋棄的；因為AOF持久化模式還伴生了“AOF rewrite”。
AOF的特性決定了它相對比較安全，如果你期望數據更少的丟失，那么可以采用AOF模式。如果AOF文件正在被寫入時突然server失效，有可能導致文件的最后一次記錄是不完整，你可以通過手工或者程序的方式去檢測并修正不完整的記錄，以便通過aof文件恢復能夠正常；同時需要提醒，如果你的redis持久化手段中有aof，那么在server故障失效后再次啟動前，需要檢測aof文件的完整性。

AOF默認關閉，開啟方法，修改配置文件reds.conf： appendonly yes

##此選項為aof功能的開關，默認為“no”，可以通過“yes”來開啟aof功能  
##只有在“yes”下，aof重寫/文件同步等特性才會生效  
appendonly yes  ##指定aof文件名稱  
appendfilename appendonly.aof  ##指定aof操作中文件同步策略，有三個合法值：always everysec no,默認為everysec  
appendfsync everysec  
##在aof-rewrite期間，appendfsync是否暫緩文件同步，"no"表示“不暫緩”，“yes”表示“暫緩”，默認為“no”  
no-appendfsync-on-rewrite no  ##aof文件rewrite觸發的最小文件尺寸(mb,gb),只有大于此aof文件大于此尺寸是才會觸發rewrite，默認“64mb”，建議“512mb”  
auto-aof-rewrite-min-size 64mb  ##相對于“上一次”rewrite，本次rewrite觸發時aof文件應該增長的百分比。  
##每一次rewrite之后，redis都會記錄下此時“新aof”文件的大小(例如A)，那么當aof文件增長到A*(1 + p)之后  
##觸發下一次rewrite，每一次aof記錄的添加，都會檢測當前aof文件的尺寸。  
auto-aof-rewrite-percentage 100

AOF是文件操作，對于變更操作比較密集的server，那么必將造成磁盤IO的負荷加重；此外linux對文件操作采取了“延遲寫入”手段，即并非每次write操作都會觸發實際磁盤操作，而是進入了buffer中，當buffer數據達到閥值時觸發實際寫入(也有其他時機)，這是linux對文件系統的優化，但是這卻有可能帶來隱患，如果buffer沒有刷新到磁盤，此時物理機器失效(比如斷電)，那么有可能導致最后一條或者多條aof記錄的丟失。通過上述配置文件，可以得知redis提供了3中aof記錄同步選項：

always：每一條aof記錄都立即同步到文件，這是最安全的方式，也以為更多的磁盤操作和阻塞延遲，是IO開支較大。
everysec：每秒同步一次，性能和安全都比較中庸的方式，也是redis推薦的方式。如果遇到物理服務器故障，有可能導致最近一秒內aof記錄丟失(可能為部分丟失)。
no：redis并不直接調用文件同步，而是交給操作系統來處理，操作系統可以根據buffer填充情況/通道空閑時間等擇機觸發同步；這是一種普通的文件操作方式。性能較好，在物理服務器故障時，數據丟失量會因OS配置有關。

其實，我們可以選擇的太少，everysec是最佳的選擇。如果你非常在意每個數據都極其可靠，建議你選擇一款“關系性數據庫”吧。
AOF文件會不斷增大，它的大小直接影響“故障恢復”的時間,而且AOF文件中歷史操作是可以丟棄的。**AOF rewrite操作就是“壓縮”AOF文件的過程，當然redis并沒有采用“基于原aof文件”來重寫的方式，而是采取了類似snapshot的方式：基于copy-on-write，全量遍歷內存中數據，然后逐個序列到aof文件中。因此AOF rewrite能夠正確反應當前內存數據的狀態，這正是我們所需要的；**rewrite過程中，對于新的變更操作將仍然被寫入到原AOF文件中，同時這些新的變更操作也會被redis收集起來(buffer，copy-on-write方式下，最極端的可能是所有的key都在此期間被修改，將會耗費2倍內存)，當內存數據被全部寫入到新的aof文件之后，收集的新的變更操作也將會一并追加到新的aof文件中，此后將會重命名新的aof文件為appendonly.aof,此后所有的操作都將被寫入新的aof文件。如果在rewrite過程中，出現故障，將不會影響原AOF文件的正常工作，只有當rewrite完成之后才會切換文件，因為rewrite過程是比較可靠的。

觸發rewrite的時機可以通過配置文件來聲明，同時redis中可以通過bgrewriteaof指令人工干預。

redis-cli -h ip -p port bgrewriteaof

因為rewrite操作/aof記錄同步/snapshot都消耗磁盤IO，redis采取了“schedule”策略：無論是“人工干預”還是系統觸發，snapshot和rewrite需要逐個被執行。

AOF rewrite過程并不阻塞客戶端請求。系統會開啟一個子進程來完成。

三.總結：

AOF和RDB各有優缺點，這是有它們各自的特點所決定：

AOF更加安全，可以將數據更加及時的同步到文件中，但是AOF需要較多的磁盤IO開支，AOF文件尺寸較大，文件內容恢復數度相對較慢。
*2) snapshot，安全性較差，它是“正常時期”數據備份以及master-slave數據同步的最佳手段，文件尺寸較小，恢復數度較快。

可以通過配置文件來指定它們中的一種，或者同時使用它們(不建議同時使用)，或者全部禁用，在架構良好的環境中，master通常使用AOF，slave使用snapshot，主要原因是master需要首先確保數據完整性，它作為數據備份的第一選擇；slave提供只讀服務(目前slave只能提供讀取服務)，它的主要目的就是快速響應客戶端read請求；但是如果你的redis運行在網絡穩定性差/物理環境糟糕情況下，建議你master和slave均采取AOF，這個在master和slave角色切換時，可以減少“人工數據備份”/“人工引導數據恢復”的時間成本；如果你的環境一切非常良好，且服務需要接收密集性的write操作，那么建議master采取snapshot，而slave采用AOF。

---------------------
作者：不能說的秘密go
來源：CSDN
原文：https://blog.csdn.net/canot/article/details/52886923
版權聲明：本文為作者原創文章，轉載請附上博文鏈接！
內容解析By：CSDN,CNBLOG博客文章一鍵轉載插件