更多內容，歡迎關注微信公眾號：全菜工程師小輝~

Redis提供了將資料定期自動持久化至硬碟的能力，包括RDB和AOF兩種方案，兩種方案分別有其長處和短板，可以配合起來同時執行，確保資料的穩定性。

RDB

儲存資料快照至一個RDB檔案中，用於持久化。RDB操作和Mysql Dump相似。

執行方式

• save。同步操作，會阻塞Redis。
• bgsave。呼叫linux的fork()，然後使用新的執行緒執行復制。但是fork期間也會阻塞Redis，但是阻塞時間通常很短。
• 自動儲存。Redis配置檔案中設定了自動儲存的觸發機制，可以自定義修改，執行原理同bgsave。

save和bgsave的對比

注意：

• 如果機器上執行多個Redis，需要配置RDB檔名稱，否則多個Redis的RDB檔案會相互覆蓋。

除了上述三種執行方式，以下情況也會生成RDB檔案：

• 主從的全量複製時，主機會生成RDB檔案。
• Redis中的debug reload提供debug級別的重啟，不清空記憶體的一種重啟，這種方式也會觸發RDB檔案的生成。
• 執行shutdown時，會觸發RDB檔案的生成。

RDB的缺點

• 全量資料儲存，耗時。
• 雖然fork()採用copy-on-write策略，但仍消耗記憶體
• 寫RDB檔案消耗大量IO效能。

AOF

採用AOF持久方式時，Redis會把每一個寫請求都記錄在一個日誌檔案裡，AOF操作和Mysql Binlog相似。通過AOF重寫機制減少AOF檔案的體積，從而減少恢復時間。

執行方式

• always。Redis的每條寫命令都寫入到系統緩衝區，然後每條寫命令都使用fsync“寫入”硬碟。
• everysec。過程與always相同，只是fsync的頻率為1秒鐘一次。這個是Redis預設配置，如果系統宕機，會丟失一秒左右的資料
• no。由作業系統決定什麼時候從系統緩衝區重新整理到硬碟。

AOF重寫

為了解決AOF檔案體積膨脹的問題，Redis提供了AOF重寫功能：Redis伺服器可以建立一個新的AOF檔案來替代現有的AOF檔案，新舊兩個檔案所儲存的資料庫狀態是相同的，但是新的AOF檔案不會包含任何浪費空間的冗餘命令，通常體積會較舊AOF檔案小很多。

AOF重寫方式

• bgrewriteaof（流程與bgsave相似）
  
• AOF重寫配置（與RDB自動儲存相似）

AOF重寫並不需要對原有AOF檔案進行任何的讀取，寫入，分析等操作，這個功能是通過讀取伺服器當前的資料庫狀態來實現的。

RDB vs AOF

Redis啟動時的資料載入

Redis啟動資料載入流程：

1. AOF持久化開啟且存在AOF檔案時，優先載入AOF檔案。
2. AOF關閉或者AOF檔案不存在時，載入RDB檔案。
3. 載入AOF/RDB檔案成功後，Redis啟動成功。
4. AOF/RDB檔案存在錯誤時，Redis啟動失敗並列印錯誤資訊。

開發運維中常見的問題

fork操作

fork()的實際開銷就是複製父程序的頁表以及給子程序建立一個程序描述符，所以速度一般比較快

記憶體量越大，耗時越長；物理機相對較快，虛擬機器相對較慢。

優化方法

1. 優先使用物理機或者高效支援fork操作的虛擬化技術
2. 控制Redis例項最大可用記憶體maxmemory
3. 合理配置Linux記憶體分配策略：vm.overcommit_memory=1。預設值為0，會使Linux在記憶體分配時，發現不夠記憶體不足時，不會進行分配，進而造成fork阻塞
4. 降低fork頻率。例如放寬AOF重寫自動觸發時機或者減少不必要的主從全量複製

程序外開銷

• CPU。RDB和AOF檔案生成，屬於CPU密集型。不要將Redis程序繫結在某個CPU上,防止單核過載；同時Redis不和CPU密集型應用一起部署。
  
• 記憶體。fork記憶體開銷，copy-on-write。
  
• 硬碟。AOF和RDB檔案的寫入。可以結合iostat和iotop進行分析。

優化方法

1. 不要和高硬碟負載服務部署在一起：儲存服務、訊息佇列等
2. 配置no-appendfsync-on-rewrite=yes。這樣在AOF重寫的期間，不要進行AOF追加操作（主執行緒只將資料寫入緩衝區），可以減少記憶體的開銷。

但如果AOF重寫期間，Redis宕機的話，在Linux的系統預設配置下，最多會丟失30s的資料。如果無法忍受資料丟失，no-appendfsync-on-rewrite配置no；如果應用系統無法忍受延遲，而可以容忍少量的資料丟失，則設定為yes。

1. 根據寫入量決定磁碟型別：例如ssd
2. 單機多例項持久化檔案目錄可以考慮分盤，或者使用類似cgroups機制進行硬碟資源的合理分配

AOF追加阻塞

例如在AOF的everysec策略中，主執行緒會對比上次fsync的時間，如果距離上次fsync時間超過兩秒，就會造成主執行緒阻塞（等待同步執行緒同步完成）。

日常開發可以使用info persistence命令，檢視歷史發生AOF阻塞的次數；然而需要了解AOF追加阻塞的發生時間則需要檢視Redis日誌。

傳送AOF追加阻塞的時候，日誌如下：

Asynchronous AOF fsync is taking too long (disk is busy?). Writing the AOF buffer without waiting for fsync to complete, this may slow down Redis.

優化方法（參考其他方面的優化點）

更多內容，歡迎關注微信公眾號：全菜工程師小輝~

相關推薦