Redis持久化之RDB & AOF

1. 爲何須要持久化？

Redis的讀寫和響應速度爲何如此之快？不一樣於傳統的關係型數據庫，Redis的數據庫是所有加載在實時內存中的，讀寫操做可以直接在內存中進行，省去了大量IO操做，所以性能很是優越。但一切依託於內存的服務都有個最大的軟肋，那即是在設備出現故障(如斷點)時，內存中全部的實時數據都將會丟失。爲了解決這個問題，Redis中提供了兩種持久化方案：RDB和AOF，其機制實際上都是設法將內存中的數據以文件的形式備份到磁盤上，從而解決斷電等機器故障致使數據丟失的問題。

2. RDB (Redis DataBase)

實現機制：Redis會單首創建(fork)一個子進程來進行持久化，會先將數據寫入到一個臨時文件中，待持久化過程結束後，再用這個臨時文件替換上次持久化好的文件(dump.rdb)。整個過程當中，主進程不會進行任何IO操做的，這樣就可以保證Redis主進程持續的高性能。在恢復數據時，重啓後會Redis會自動加載工做目錄下的dump.rdb文件恢復數據到內存

相關參數：

## 設置觸發RDB dump的條件，在<seconds>時間至少發生了<changes>次數據的操做，則<seconds>時間到了就將數據寫到磁盤中，爲dump.rdb  Redis默認設置了三個條件，知足之一便可觸發。移除全部條件或者設置 save 後加空字符串爲禁用RDB功能
save <seconds> <changes>
save 900 1          ## for 低頻寫入    
save 300 10          ## for 中頻寫入
save 60 10000              ## for 高頻寫入

## 設置當RDB進程出現故障時，Redis是否中止寫操做,默認爲yes
stop-writes-on-bgsave-error yes

## 設置RDB時是否使用LZF壓縮算法對dump.rdb文件進行壓縮，默認yes
rdbcompression yes

## 設置是否對dump.rdb文件進行校驗，默認CRC64校驗算法，會消耗RDB進程的CPU資源的10%，默認開
rdbchecksum yes

## 設置輸出文件名， 默認dump.rdb
dbfilename dump.rdb

## 設置dump.rdb文件輸出路徑，默認爲當前啓動工做目錄
dir ./

優點：

• 不管是持久化過程仍是數據恢復過程，RDB的速度都很是快
• 用戶可以手動設置參數以控制持久化的頻率，應用場景更加靈活
• 適合大規模且對數據的完整性和一致性要求不高的數據恢復，

劣勢：

• RDB的持久化須要fork一條子線程，且子線程將會copy主線程全部數據，至關於設備的內存使用臨時翻了一倍，在數據量特別大的狀況下使用RDB可能有內存溢出風險
• 最後一次持久化的數據可能丟失，所以對數據完整性比較敏感的業務不建議使用RDB進行持久化

PLUS：爲何最後一次持久化的數據可能丟失？

RDB經過設置save <seconds> <changes>條件來觸發dump，其機制爲知足任一save條件後再該條件的<seconds>後進行刷寫，但實際上可能最後一次dump時雖然達到修改次數<changes>要求，但在時間還未到達時redis進程停止，則這一階段的數據就丟失了。 好比save 300 10這一條件，Redis在300s內的修改操做次數超過了10次，所以觸發持久化條件，系統將會在300s到期後進行刷寫，可是可能在到期前幾秒，設備異常關機，那麼這300s內產生的數據修改信息將會所有丟失

3. AOF(Append Only File)

實現機制：與RDB直接寫原數據不一樣，AOF記錄的是Redis自啓動期間全部的寫操做，相似於日誌，且寫入的方式只容許在末尾追加，不容許修改以前寫入的內容，默認保存爲appendonly.aof文件。恢復數據時，Redis將AOF加載到內存並執行其中的每一條數據進行數據的恢復。

相關參數：

## 啓動開關  --  默認關閉
appendonly no 

## 文件名
appendfilename "appendonly.aof"

## 刷寫頻率
appendfsync always       ## 同步持久化，每當有數據變動就當即記錄到磁盤，性能較差但數據完整性好
appendfsync everysec    ## 出廠默認配置，異步操做，每秒記錄，若是一秒內宕機，則會有數據丟失
append no        ## 不設置刷寫頻率，當Redis本身觸發刷寫條件時才進行刷寫

優點：

• 默認的刷寫頻率爲每秒一次，所以可以最大程度地保證數據的完整性
• AOF只是記錄運行時的寫操做，並不會複製全部主線程數據，所以發生內存溢出的風險較小

劣勢：

• 只支持追加形式寫入，所以造成的appendonly.aof文件會愈來愈大，會影響Redia恢復數據的性能
• 恢復數據時須要Redis執行appendonly.aof記錄的每條指令，恢復速度較慢
• 實際上操做指令有很大的整合空間，好比10000條自增1語句能夠歸併爲一條自增10000語句，AOF在這方面仍然有較大可優化空間

Rewrite機制：爲解決appendonly.aof文件會愈來愈大的隱患，AOF設置了Rewrite機制，默認當appendonly.aof文件大小達到了上次Rewrite後appendonly.aof文件的大小時而且文件的大小超過64M，AOF將會啓動Rewrite，fork出一條新進程建立一個臨時文件，而後遍歷整個數據庫，將每一個key、value對以Redis命令的格式輸出到臨時文件。這一過程會將多個鍵值對集合起來用一條命令表達以減少最終文件的大小。在rewrite期間的寫操做會保存在內存的rewrite buffer中，rewrite成功後這些操做也會append到臨時文件中，rewrite完成後該臨時文件便會代替appendonly.aof文件

## 觸發Rewrite條件 -- and -- 

auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

## 發生重寫時是否支持appendfsync刷寫？ 默認爲no，保證數據安全
no-appendfsync-on-rewrite no

4. 小結

使用場景：

• RDB適合數據流大、數據恢復快但對數據完整性依賴不高的業務，好比用戶行爲分析等
• AOF則適合對數據完整性有很高限制的業務，好比銀行金融類業務

共存性：
官方雖然默認關閉AOF功能，但實質上RDB和AOF是能夠共存的，當Redis同時開啓了AOF和RDB持久化，Redis重啓時會優先讀取AOF文件進行數據恢復，由於AOF比RDB更能保證數據完整性。此外，因爲Redis數據的恢復須要讀取AOF文件或者RDB文件，所以，爲了防止這兩個文件出現損毀或者被惡意修改，Redis提供了兩個修復腳本專門修復這兩個文件

## 修復AOF文件
redis-check-aof  --fix appendonly.aof

## 修復RDB文件
redis-check-dump --fix dump.rdb

安全性拓展：
實際生產時，不管是AOF仍是RDB，都須要將生成的appendonly.aof和dump.rdb文件進行異地備份，這樣才能避免單機完全損壞形成的數據不可恢復問題