1.RDB

（1） 定義

RBD：snapshotting（快照）是預設方式，將記憶體中資料以快照的方式寫入到二進位制檔案中，預設檔名為dump.rdb

（2）觸發rdbSave過程的方式

• save命令：阻塞Redis伺服器程序，直到RDB檔案建立完畢為止。
• bgsave命令：派生出一個子程序，然後由子程序負責建立RDB檔案，父程序繼續處理命令請求。
• master接收到slave發來的sync命令
• 定時save(配置檔案中制定）

注：

• fork的作用是複製一個與當前程序一樣的程序。新程序的所有資料（變數、環境變數、程式計數器等）,值都和原程序一致，但是是一個全新的程序，並作為原程序的子程序

• 執行flushall命令（清空所有資料庫），也會產生dump.rdb檔案，但裡面是空的，無意義

• 命令bgsave與bgrewriteaof不能同時執行，若bgsave正在執行，則bgrewriteaof延遲到bgsave執行完再執行。若bgrewriteaof正在執行，則伺服器拒絕執行bgsave命令。

（2） 配置:

• 預設條件

  • save 900 //900秒內如果超過1個key被修改，則發起快照儲存
  • save 300 10 //300秒內如果超過10個key被修改，則發起快照儲存
  • save 60 10000 //60秒內如果超過10000個key被修改，則發起快照儲存

• 伺服器狀態

  • saveparams屬性：記錄了儲存條件的陣列
  • dirty計數器：記錄距離上一次save/bgsave命令之後，伺服器對資料庫狀態修改了多少次
  • lastsave屬性：是一個Unix時間戳，記錄了上一次成功執行save/bgsave命令的時間。

（3）RDB檔案結構

• RDB檔案結構

  • REDIS長度為5個位元組，程式在載入檔案時，可以快速檢查所載入的檔案是否是RDB檔案。
  • db_version長度為4個位元組，一個字串表示的整數，記錄了RDB檔案的版本號。
  • database包含零個或任意多個數據庫，以及鍵值對的資料
  • EOF常量的長度為1個位元組，標誌著RDB檔案正文內容的結束。
  • check_sum是一個8位元組長的無符號整數，儲存著一個校驗和，由前面四部分計算得出的。

• database部分
  

  • SELECTDB常量的長度為1位元組，接下來讀入的將是一個數據庫號碼
  • db_number儲存著一個數據庫號碼。
  • key_value_pairs 儲存了資料庫中的所有鍵值對資料，由TYPE、key、value組成

• 完整的檔案結構圖
  

（4）記憶體中資料與磁碟互動

（5）優點

• 適合大規模的資料恢復，對資料完整性和一致性要求不高

（6）缺點

• 由於快照方式是在一定間隔時間做一次的，若redis出現宕機，就會丟失最後一次快照後的所有修改。

• fork的時候，記憶體中的資料被克隆了一份，大致2倍的膨脹性需要考慮如何停止

2.AOF

（1） 定義

AOF（appendonly file）:通過儲存Redis伺服器所執行的寫命令來記錄資料庫狀態。

（2）優點

redis將每一個收到的寫命令都通過write函式追加到檔案中，當redis重啟時會通過重新執行檔案中儲存的寫命令來在記憶體中重建整個資料庫的內容

（3）缺點

• 由於os會在核心中快取write做的修改，所以可能不是立即寫到磁碟上，可能會丟失部分資料修改。

• 相同資料集的資料而言aof檔案要遠大於rdb檔案，恢復速度慢於rdb，aof執行效率要慢於rdb,每秒同步策略效率較好，不同步效率和rdb相同

（4） 解決方法：通過配置檔案進行修改

• Appendonly yes //啟用AOF持久化方式
• Appendfsync always //收到寫命令就立即寫入磁碟（最慢）但是保證完全的持久化
• Appendfsync everysec //每秒寫入磁碟一次，在效能和持久化方面做了很好的折中（預設）

• Appendfsync no //完全依賴os,效能最好，持久化沒有保證。

• 修復：如果aof檔案被破壞， redis-check-aof–fix進行修復，在flushAppendOnlyFile函式中，若出現斷電等情況，就將寫出錯的情況記錄到日誌裡，之後會處理錯誤。

• 恢復：重啟redis然後重新載入，如果aof和rdb兩種持久化工具都開啟，AOF優先。因為在通常情況下AOF檔案儲存的資料集要比RDB檔案儲存的資料集要完整.

（5）AOF的步驟

• 命令追加：將命令追加到AOF緩衝區
• 檔案寫入
• 檔案同步

（6）AOF重寫（bgrewriteaof）

• 出現原因
  隨著伺服器執行時間的流逝，AOF檔案的內容會越來越多，為了解決AOF檔案體積膨脹的問題，Redis提供了AOF檔案重寫。

• AOF重寫的實現原理
  fork出一條新程序來將檔案重寫(也是先寫臨時檔案最後再rename)，遍歷新程序的記憶體中資料，每條記錄有一條的Set語句。重寫aof檔案的操作，並沒有讀取舊的aof檔案，而是將整個記憶體中的資料庫內容用命令的方式重寫了一個新的aof檔案，

• 重寫觸發機制
  Redis會記錄上次重寫時的AOF大小，預設配置是當AOF檔案大小是上次rewrite後大小的一倍且檔案大於64M時觸發（預設）

• AOF後臺重寫

  • AOF重寫程式放到子程序中執行，為了解決子程序下資料不一致的問題，Redis伺服器設定了一個AOF重寫緩衝區，在伺服器建立子程序之後使用，
  • 當Redis執行完一個命令後，它會同時將這個寫命令傳送給AOF緩衝區和AOF重寫緩衝區，這樣就可以保證現有AOF檔案的處理工作照常進行，而伺服器的所有寫命令都會被記錄到AOF重寫緩衝區裡。

（7）AOF圖解

3.虛擬記憶體方式：

虛擬記憶體方式是Redis來進行使用者空間的資料換入換出的一個策略，此種方式在實現的效果上比較差，主要問題是程式碼複雜，重啟慢，複製慢等等，目前已經被作者放棄。

4.diskstore方式：

diskstore方式是作者放棄了虛擬記憶體方式後選擇的一種新的實現方式，也就是傳統的B-tree的方式。

本人才疏學淺，若有錯，請指出，謝謝！