Redis持久化整理

1 介紹

Redis支援RDB和AOF兩種持久化機制，持久化有效避免因進程退出資料丟失問題，重啟時利用之前持久化的檔案即可實現數
據恢複。 2 RDB

RDB持久化把當前進程資料產生快照儲存到硬碟，代表Redis在某個時間點上的資料快照，RDB有手動和自動觸發。
- 手動觸發
- save：阻塞伺服器，直到RDB完成,已棄用；
- bgsave：Redis進程fork出子進程，RDB持久化過程由子進程負責，完成後自動結束。Redis內部的RDB都採用bgsave。
- 自動觸發
內部自動觸發RDB持久化有：①save m n配置(m秒記憶體在n次修改，自動觸發bgsave);②從節點執行全量複製，主節點自動執行bgsave，組建檔案發往從節點;③debug reload自動觸發’save’;④預設下shutdown，若沒開啟AOF，自動執行bgsave。 2.1 bgsave是主流的觸發RDB持久化方式

流程如下：
bgsave->父進程->fork->子進程->產生RDB檔案->父進程 執行bgsave，Redis父進程判斷是否有正在執行的子進程(eg.RDB/AOF子進程)，存在則直接返回； 父進程fork建立子進程，fork過程中父進程會阻塞(info stats查看latest_fork_usec，最近一個fork操作耗時-微秒）； fork完成後，bgsave返回“Background saving started”,不再阻塞父進程，可繼續響應其他命令； 子進程建立RDB檔案，根據父進程記憶體 產生 臨時快照檔案，完成後對原有檔案進行原子替換(lastsave的rdb_last_save_time,最後一次產生RDB的時間)； 訊號通知父進程，以更新統計資料。

設定檔的dir：RDB檔案儲存目錄，dbfilename：其檔案名稱。

壞盤或磁碟寫滿時，線上修改config set dir{newDir}到新的可用的磁碟路徑,然後bgsave磁碟切換(RDB、AOF都適用)。
同理，可線上config set dbfilename{newFileName}。
Redis預設採用LZF演算法壓縮RDB檔案，遠遠小於記憶體資料，消耗CPU但大幅↓檔案體積，方便儲存或網路傳輸，線上建議開啟（預設開）。(config set rdbcompression{yes|no}) 2.2 優缺點

優： ①緊湊壓縮的二進位檔案，可每X小時執行bgsave備份，災難恢複；②載入RDB恢複資料遠遠快於AOF。
缺： ①無法即時持久化（bgsave每次都要fork建子進程，重量級操作）；②特定二進位格式，新舊版不相容。 3 AOF

AOF（append only file）持久化，日誌 記錄每次寫命令，重啟時再重新執行AOF檔案中的命令，恢複資料。它解決了資料持久化的即時性。理解掌握好其機制，↑兼顧資料安全性和效能。

開啟AOF：appendonly yes(預設不開啟)
AOF檔案名稱：appendfilename(預設檔案名稱appendonly.aof)
儲存路徑：dir(同RDB) 3.1 AOF是Redis持久化的主流方式

AOF工作流程：
命令寫入（append）->AOF緩衝->檔案同步（sync）->AOF檔案->檔案重寫（rewrite）<-重啟載入（load）

所有的寫入命令會追加到aof_buf（緩衝區）; AOF緩衝區根據對應的策略向硬碟做同步操作; 隨著AOF檔案越來越大，需定期對AOF檔案進行重寫，達到壓縮目的; 當Redis伺服器重啟時，可載入AOF檔案進行資料恢複。
命令寫入
AOF直接採用文本協議格式

①文本協議相容性很好；②開啟AOF後，所有寫入命令都包含追加操作，直接採用協議格式，避免了二次處理開銷；③可讀性，方便直接修改和處理。
AOF為何把命令追加到aof_buf（緩衝區）。
①Redis單線程響應命令，直接追加到硬碟，效能完全取決於當前硬碟負載；②可提供多種緩衝區同步硬碟的策略，在效能和安全性做平衡。
- 檔案同步
Redis提供了多種AOF緩衝區同步檔案策略，由參數appendfsync控制。
always:不建議配置。每次寫入都要同步，代價高；
no:效能↑，但資料安全性無法保證；
everysec: 建議配置，預設配置。兼顧效能和資料安全性。理論上系統突然宕機會丟失1秒資料。
- 重寫機制
隨著命令不斷寫入,AOF檔案越來越大,重寫機制可壓縮檔體積。重寫把進程內資料->寫命令，同步->新AOF檔案。

重寫後體積變小，可更快被Redis載入

①已逾時不寫入；②新AOF檔案只保留最終資料的寫入命令；③多條寫命令合并為一個(eg.lpush list a、lpush list b…->lpush list a b …)，防用戶端緩衝區溢位。

手動觸發：bgrewriteaof
自動觸發：auto-aof-rewrite-min-size、auto-aof-rewrite-percentage

bgrewriteaof->父進程->fork->（aof_buf->舊AOF檔案，aof_rewrite_buf->新AOF檔案，子進程->訊號通知父進程->新AOF檔案

1.執行AOF重寫請求，若正在執行bgsave，重寫命令延遲到bgsave完成之後；
2.父進程fork子進程；
3.1 fork後，繼續響應，寫入AOF緩衝區+appendfsync策略同步硬碟，保證正確性； 3.2 fork(寫時複製技術)，子進程只能共用fork操作時的記憶體資料。用AOF重寫緩衝區儲存新資料；
4.子進程根據記憶體快照，按照命令合并規則寫入新AOF檔案；
5.1寫到新檔案後，通知父進程；
5.2父進程把AOF重寫緩衝區的資料寫入到新AOF檔案；
5.3替換老檔案，完成重寫。
- 重啟載入
持久化檔案載入流程：

1.AOF持久化開啟且存在AOF檔案時，優先載入AOF檔案;2.AOF關閉或者AOF檔案不存在時，載入RDB檔案; 3. 載入成功後，Redis啟動否則列印失敗日誌。
- 檔案校正
載入損壞的AOF檔案時會拒絕啟動。此時，先備份，然後後redis-check-aof--fix修複，最後diff-u對比差異，人工修改補全(不完整)。當突然掉電，AOF尾部不全時，aof-load-truncated(預設開啟)可忽略並繼續啟動redis。 3.2 問題定位最佳化

fork

fork會複製父進程的空間記憶體頁表，eg.10GB的Redis，需複製約20MB記憶體頁表，fork耗時跟進程總記憶體量成正比。
改善：
①優先物理機；②控制Redis執行個體最大可用記憶體(單一實例10G以內)；③合理配置Linux記憶體配置策略；④降低fork頻率，↓全量複製。 子進程開銷
子進程負責AOF|RDB檔案的重寫，主要涉及CPU、記憶體、硬碟消耗。
CPU：
多個redis執行個體，保證同一時刻只有一個子進程重寫。因為redis本身是CPU密集型服務，子進程又負責進程內資料分批寫入檔案，非常消耗CPU，單核CPU會和父進程產生資源競爭。
記憶體：
多個Redis執行個體盡量保證同一時刻只有一個子進程在工作；大量寫入時避免子進程重寫操作。
硬碟：
不部署在高負載的硬碟；AOF重寫期間不做fsync操作(預設關閉)。 AOF追加阻塞
主線程->AOF緩衝區->同步線程->同步磁碟,AOF緩衝區->對比上次fsync時間->小於2秒通過，大於2秒阻塞
最佳化AOF追加阻塞問題主要是最佳化系統硬碟負載。 總結

產生RDB開銷較大,一般用於資料冷備和複製傳輸；
AOF檔案體積逐漸層大，定期執行重寫操作降低檔案體積；
AOF重寫:auto-aof-rewrite-min-size,auto-aofrewritepercentage參數自動觸發，bgrewriteaof手動觸發;
子進程執行期間，copy-on-write與父進程共用記憶體，防記憶體消耗翻倍。AOF重寫期間，維護重寫緩衝區，儲存新的寫入命令避免資料丟失；
持久化阻塞主線程：fork阻塞時間跟記憶體量和系統有關，AOF追加阻塞說明硬碟資源緊張；
單機多執行個體，防多個子進程重寫，做隔離控制。

參考：
《redis開發與營運》