這個標題或許會讓你想起《黑客帝國》裡經典的臺詞，你要選擇藍色藥丸，還是紅色藥丸？

Redis 是我們重度使用的一個開源軟體，對它的持久化配置做一番相對深入的總結，是值得的。目前它有兩種主流的持久化儲存方式 SnapShot 以及 AOF 。

什麼是 Snapshot

Snapshot 將記憶體中資料以結構化的方式序列化到 rdb 檔案中，是預設的持久化方式，便於解析引擎快速解析和記憶體實施。快照得由間隔時間，變更次數同時符合才會觸發， 該過程中並不阻塞客戶端請求，copy-on-write 方式也意味著極端情況下可能會導致實際資料2倍記憶體的使用量。它首先將資料寫入臨時檔案，結束後，將臨時檔案重名為 dump.rdb。可以使用 redis-check-dump

只有快照結束後才會將舊的檔案替換成新的，因此任何時候 RDB 檔案都是完整的。如果在觸發 snapshot 之前，server 失效。會導致上一個時間點之後的資料未能序列化到 rdb 檔案，安全性上稍弱。

我們可手動執行 save 或 bgsave 命令讓 redis 執行快照。兩個命令的區別在於:

• save 是由主程序進行快照操作，會阻塞其它請求;
• bgsave 會通過 fork 子程序進行快照操作;

RDB 檔案預設是經過壓縮的二進位制檔案，佔用的空間會小於記憶體中的資料，更加利於傳輸。設定如下，可以關閉快照功能

1

save ""

相關配置

1
 

2
3
4
5
6
7
8

# snapshot觸發的時機，save <seconds> <changes>， 比如600秒有2個操作
save 600 2
# 當snapshot 時出現錯誤無法繼續時，是否阻塞客戶端變更操作 
stop-writes-on-bgsave-error yes 
# 是否啟用rdb檔案壓縮，預設為 yes cpu消耗，快速傳輸  
rdbcompression yes  
# rdb檔名稱  
dbfilename dump.rdb  

什麼是 AOF

Append-only file，將 操作 + 資料 以格式化指令的方式追加到操作日誌檔案的尾部，在 append 操作返回後， 已經寫入到檔案或者即將寫入，才進行實際的資料變更，日誌檔案儲存了歷史的操作過程；當 server 需要資料恢復時，可以直接回放此日誌檔案，即可還原所有的操作過程。 如果你期望資料更少的丟失，那麼可以採用 AOF 模式。可以用 redis-check-aof 檢測檔案是否完整。

AOF 就是日誌會記錄變更操(例如：set/del等)，會導致AOF檔案非常的龐大，意味著server失效後，資料恢復的過程將會很長；事實上，一條資料經過多次變更，將會產生多條AOF記錄，其實只要儲存當前的狀態，歷史的操作記錄是可以拋棄的， 由此催生了 AOF ReWrite。

什麼是 AOF Rewrite

其實是壓縮 AOF 檔案的過程，Redis 採取了類似 Snapshot 的方式：基於 copy-on-write，全量遍歷記憶體中資料，然後逐個序列到 aof 檔案中。因此 AOF Rewrite 能夠正確反應當前記憶體資料的狀態， Rewrite 過程中，新的變更操作將仍然被寫入到原 AOF 檔案中，同時這些新的變更操作也會被收集起來， 並不阻塞客戶端請求。

相關配置

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

##只有在yes下，aof重寫/檔案同步等特性才會生效  
appendonly no  
##指定aof檔名稱  
appendfilename appendonly.aof  
##指定aof操作中檔案同步策略，有三個合法值：always everysec no，預設為everysec  
appendfsync everysec  
##在aof-rewrite期間，appendfsync 是否暫緩檔案同步，no 表示不暫緩，yes 表示暫緩，預設為no  
no-appendfsync-on-rewrite no  
##aof檔案rewrite觸發的最小檔案尺寸 只有大於此aof檔案大於此尺寸是才會觸發rewrite，預設64mb，建議512mb  
auto-aof-rewrite-min-size 64mb  
##相對於上一次rewrite，本次rewrite觸發時aof檔案應該增長的百分比
auto-aof-rewrite-percentage 100  

appendfsync 方式：

• always：每一條 aof 記錄都立即同步到檔案，這是最安全的方式，但是更多的磁碟操作和阻塞延遲，IO 開支較大。
• everysec：每秒同步一次，效能和安全也是redis推薦的方式。如果伺服器故障，有可能導致最近一秒內aof記錄丟失。
• no：redis並不直接呼叫檔案同步，而是交給作業系統來處理，作業系統可以根據buffer填充情況等擇機觸發同步；效能較好，在物理伺服器故障時，資料丟失量會因OS配置有關。

選擇哪種藥丸

• AOF更安全，可將資料及時同步到檔案中，但需要較多的磁碟IO，AOF檔案尺寸較大，檔案內容恢復相對較慢， 也更完整。
• Snapshot，安全性較差，它是正常時期資料備份及 master-slave 資料同步的最佳手段，檔案尺寸較小，恢復數度較快。

主從架構的環境下的選擇

• 通常 master 使用AOF，slave 使用 Snapshot，master 需要確保資料完整性，slave 提供只讀服務.
• 如果你的網路穩定性差， 物理環境糟糕情況下，那麼 master， slave均採取 AOF，這個在 master， slave角色切換時，可以減少時間成本；