本筆記參考《Redis設計與實現》 P118 ~ P150

RDB文件

1、RDB文件用于保存和還原Redis服務器所有數據庫中的所有鍵值對數據
2、SAVE命令由服務器進程直接執行保存操作，該命令會阻塞服務器
3、BGSAVE命令由子進程執行保存操作，不會阻塞服務器
注意此時服務器的狀態：在處理BGSAVE命令時，服務器處理SAVE、BGSAVE、BGREWRITEAOF三個命令方式與平時不同。

• 客戶端發送的SAVE命令會被服務器拒絕，服務器禁止SAVE命令與BGSAVE同時執行，是為了避免父進程與子進程同時執行rdbSave調用，產生競爭條件。
• 客戶端發送的BGSAVE命令也會被服務器拒絕，因為同時執行兩個BGSAVE也會產生競爭條件。
• 最后：BGSAVE和BGREWRITEAOF不能同時執行：因為兩個命令實際工作都是由子進程執行，所以兩個命令在操作方面沒有沖突，但是并發出兩個子進程，并且兩個子進程都是同時執行大量的磁盤寫入操作的話不是個好主意。

4、服務器狀態中會保存所有用save選項設置的保存條件，當任意一個保存條件被滿足，服務器自動執行BGSAVE
5、RDB文件時一個經過壓縮的二進制文件，由多個部分組成
6、對于不同類型的鍵值對，RDB文件會使用不同方式保存

AOF文件

1、APF文件通過保存所有修改數據庫的寫命令請求來記錄服務器的數據庫狀態
2、AOF文件中的所有命令都是以Redis命令請求協議的格式保存的
3、命令請求會先保存到AOF緩沖區中，之后再定期寫入并同步到AOF文件
4、appendfsync選項的不同值對于AOF持久化功能的安全性以及Redis服務器的性能有很大影響

• 當appendfsync的值為always時，服務器在每個事件循環都要將aof_buf緩沖區中的所有內容寫到AOF文件中，并且同步AOF文件，所以always的效率最慢，但安全性最強，出現故障，AOF持久化也只會丟失一個事件循環中所產生的命令數據
• 當appendfsync的值為everysec時，服務器在每個事件循環都要將aof_buf緩沖區中的所有內容寫入到AOF文件，并且每隔一秒就要在子線程中對AOF文件進行一次同步。效率足夠快，出現故障也只會丟失一秒鐘的命令數據
• 當appendfsync的值為no時，服務器在每個事件循環都要將aof_buf緩沖區中的所有內容寫入到AOF文件中，何是同步由操作系統控制。該模式下的AOF文件寫入速度最快，因為緩存了足夠多的數據，但是出現故障會丟失上次同步AOF之后的所有寫命令數據

5、服務器只要載入并重新執行保存在AOF文件中的命令，就可以還原數據庫本來的狀態（通過創建一個不帶網絡連接的偽客戶端）
6、AOF重寫可以產生一個新的AOF文件，新文件與原有文件所保存的數據庫狀態一樣，但是體積更小
7、AOF重寫的功能時通過讀取數據庫中的鍵值對來實現的，程序無須對現有AOF文件進行任何讀入、分析或者寫入操作
8、執行BGREWRITEAOF命令時，Redis服務器會維護一個AOF重寫緩沖區，該緩沖區會在子進程創建新AOF文件期間，記錄服務器執行的所有寫命令。當子進程完成創建新AOF文件的工作之后，服務器會將重寫緩沖區中的所有內容追加到新AOF文件的末尾，使得新舊兩個AOF文件所保存的數據庫狀態一致。最后，服務器用新的AOF文件替換掉舊AOF文件，完成文件重寫操作