技術標籤：redis

持久化之RDB與AOF

RDB（Redis DataBase）

在指定的時間間隔內生成記憶體中整個資料集的持久化快照。快照檔案預設被儲存在當前資料夾中，名稱為dump.rdb，可以通過dir和dbfilename引數來修改預設值。(在指定的時間間隔內將記憶體記憶體中的資料集快照寫入磁碟)（Snapshot快照）

Redis會單獨建立（fork）一個子程序來進行持久化，會先將資料寫入到一個臨時檔案中，待持久化過程都結束了，再用這個臨時檔案替換上次持久化好的檔案。 整個過程中，主程序是不進行任何的IO操作的，這就確保了極高的效能。

Fork就是複製一個當前程序一樣的程序，新程序的所有資料數值和原程序一致，並作為原程序的子程序

配置檔案

# redis是基於記憶體的資料庫，可以通過設定該值定期寫入磁碟。
# 註釋掉“save”這一行配置項就可以讓儲存資料庫功能失效
# 900秒（15分鐘）內至少1個key值改變（則進行資料庫儲存--持久化） 
# 120秒（2分鐘）內至少10個key值改變（則進行資料庫儲存--持久化） 
# 60秒（1分鐘）內至少10000個key值改變（則進行資料庫儲存--持久化）
# 滿足任意一條就可以形成dump.rdb檔案
save 900 1
save 120 10
save 60 10000
 
#當RDB持久化出現錯誤後，是否依然進行繼續進行工作，yes：不能進行工作，no：可以繼續進行工作，可以通過info中的rdb_last_bgsave_status瞭解RDB持久化是否有錯誤
stop-
 
writes-on-bgsave-error yes
 
#使用壓縮rdb檔案，rdb檔案壓縮使用LZF壓縮演算法，yes：壓縮，但是需要一些cpu的消耗。no：不壓縮，需要更多的磁碟空間
rdbcompression yes
 
#是否校驗rdb檔案。從rdb格式的第五個版本開始，在rdb檔案的末尾會帶上CRC64的校驗和。這跟有利於檔案的容錯性，但是在儲存rdb檔案的時候，會有大概10%的效能損耗，所以如果你追求高效能，可以關閉該配置。
rdbchecksum yes
 
#rdb檔案的名稱
dbfilename dump.rdb
 
#資料目錄，資料庫的寫入會在這個目錄。rdb、aof檔案也會寫在這個目錄
dir /
 
data

觸發時機

1、配置檔案預設的快照配置（多少秒內至少多少個key改變）

2、利用命令save、bgsave，快速的形成dump.rdb檔案

save：save只管儲存，其他不管， 全部阻塞
bgsave：Redis會在後臺非同步進行快照操作，快照同時還可以響應客戶端請求，可以通過lastsave命名獲取最好一次成功執行快照的時間

3、執行flushall命令，會觸發產生dump.rdb檔案，但是這時裡面會為空。

4、通過shutdown命令，安全退出，也會生成快照檔案（和異常退出形成對比，比如：kill殺死程序的方式）
****當執行shutdown的時候，就會執行將記憶體的資料形成dump.rdb。當重新啟動redis的時候，會自定將dump.rdb中的資料寫入記憶體。（若在shutdown執行之前，呼叫了flushAll，那麼dump.rdb檔案也會為空了）
****若很急速的想將一些資料進行寫入dump.rdb檔案，可以直接輸入save命令

如何恢復

1、將備份檔案（dump.rdb）移動到redis安裝的目錄並啟動服務即可

appendonly 設定成no，redis啟動時會把/var/lib/redis 目錄下的dump.rdb 中的資料恢復。dir 和dbfilename 都可以設定。我測試時appendonly 設定成yes 時候不會將dump.rdb檔案中的資料恢復。

優勢

1、恢復資料的速度很快，適合大規模的資料恢復，而又對部分資料不敏感的情況
2、dump.db檔案是一個壓縮的二進位制檔案，檔案暫用空間小

劣勢

1、當出現異常退出時，會丟失最後一次快照後的資料
2、當fork的時候，記憶體的中的資料會被克隆一份，大致兩倍的膨脹需要考慮。而且，當資料過大時，fork操作佔用過多的系統資源，造成主伺服器程序假死。

AOF（Append Only File）

以日誌的形式來記錄每個寫操作，將Redis執行過的所有寫指令記錄下來（讀操作補不可記錄），只許追加檔案但不可以改寫檔案，redis啟動之初會讀取改檔案重新構建資料。
儲存的是appendonly.aof檔案

配置檔案

#預設redis使用的是rdb方式持久化，這種方式在許多應用中已經足夠用了。
#但是redis如果中途宕機，會導致可能有幾分鐘的資料丟失，根據save來策略進行持久化，Append Only File是另一種持久化方式，可以提供更好的持久化特性。
#Redis會把每次寫入的資料在接收後都寫入 appendonly.aof 檔案，每次啟動時Redis都會先把這個檔案的資料讀入記憶體裡，先忽略RDB檔案。
# no是啟動rdb，yes是啟動aof,先忽略RDB檔案
appendonly no

  
#aof檔名
appendfilename "appendonly.aof"

 
#aof持久化策略的配置
#no表示不執行fsync，由作業系統保證資料同步到磁碟，速度最快。
#always表示每次寫入都執行fsync，以保證資料同步到磁碟。
#everysec表示每秒執行一次fsync，可能會導致丟失這1s資料。
appendfsync everysec


 
# 在aof重寫或者寫入rdb檔案的時候，會執行大量IO，
# 此時對於everysec和always的aof模式來說，執行fsync會造成阻塞過長時間，
# no-appendfsync-on-rewrite欄位設定為預設設定為no，是最安全的方式，不會丟失資料，但是要忍受阻塞的問題。如果對延遲要求很高的應用
# 這個欄位可以設定為yes，，設定為yes表示rewrite期間對新寫操作不fsync,暫時存在記憶體中,不會造成阻塞的問題（因為沒有磁碟競爭），等rewrite完成後再寫入，這個時候redis會丟失資料。Linux的預設fsync策略是30秒。可能丟失30秒資料。因此，如果應用系統無法忍受延遲，而可以容忍少量的資料丟失，則設定為yes。如果應用系統無法忍受資料丟失，則設定為no。
no-appendfsync-on-rewrite no
 
 
#aof自動重寫配置。當目前aof檔案大小超過上一次重寫的aof檔案大小的百分之多少進行重寫，即當aof檔案增長到一定大小的時候Redis能夠呼叫bgrewriteaof對日誌檔案進行重寫。當前AOF檔案大小是上次日誌重寫得到AOF檔案大小的二倍（設定為100）時，自動啟動新的日誌重寫過程。
auto-aof-rewrite-percentage 100
#設定允許重寫的最小aof檔案大小，避免了達到約定百分比但尺寸仍然很小的情況還要重寫
auto-aof-rewrite-min-size 64mb
 
 
#aof檔案可能在尾部是不完整的，當redis啟動的時候，aof檔案的資料被載入記憶體。重啟可能發生在redis所在的主機作業系統宕機後，尤其在ext4檔案系統沒有加上data=ordered選項（redis宕機或者異常終止不會造成尾部不完整現象。）出現這種現象，可以選擇讓redis退出，或者匯入儘可能多的資料。如果選擇的是yes，當截斷的aof檔案被匯入的時候，會自動釋出一個log給客戶端然後load。如果是no，使用者必須手動redis-check-aof修復AOF檔案才可以。
aof-load-truncated yes

如何恢復

正常恢復（前提appendonly yes）

   將檔案放到dir指定的資料夾下，當redis啟動的時候會自動載入資料，

注意：aof檔案的優先順序比dump大。

異常恢復

有些操作可以直接到appendonly.aof檔案裡去修改。
（使用了flushall這個命令，此刻持久化檔案中就會有這麼一條命令記錄，把它刪掉就可以了）
寫壞的檔案可以通過 redis-check-aof --fix appendonly.aof進行修復

優勢

1、根據不同的策略，可以實現每秒，每一次修改操作的同步持久化，就算在最惡劣的情況下只會丟失不會超過兩秒資料。
2、當檔案太大時，會觸發重寫機制，確保檔案不會太大。
3、檔案可以簡單的讀懂

劣勢

1、aof檔案的大小太大，就算有重寫機制，但重寫所造成的阻塞問題是不可避免的
2、aof檔案恢復速度慢

總結

如果你只希望你的資料在伺服器執行的時候存在，可以不使用任何的持久化方式

一般建議同時開啟兩種持久化方式。AOF進行資料的持久化，確保資料不會丟失太多，而RDB更適合用於備份資料庫，留著一個做萬一的手段。

效能建議：

因為RDB檔案只用做後備用途，建議只在slave上持久化RDB檔案，而且只要在15分鐘備份一次就夠了，只保留900 1這條規則。

如果Enalbe AOF,好處是在最惡劣情況下也只會丟失不超過兩秒資料，啟動指令碼較簡單隻load自己的AOF檔案就可以了。代價：1、帶來了持續的IO；2、AOF rewrite的最後將rewrite過程中產生的新資料寫到新檔案造成的阻塞幾乎是不可避免的。只要硬碟許可，應該儘量減少AOF rewrite的頻率，AOF重寫的基礎大小預設值64M太小了，可以設到5G以上。預設超過原大小100%大小時重寫可以改到適當的數值。

如果不Enable AOF,僅靠Master-Slave Replication 實現高可用性也可以。能省掉一大筆IO也減少了rewrite時帶來的系統波動。代價是如果Master/Slave同時宕掉，會丟失10幾分鐘的資料，啟動指令碼也要比較兩個Master/Slave中的RDB檔案，載入較新的那個。新浪微博就選用了這種架構。