數據持久化策略
快照
- redis在進行數據持久化的過程中，會先將數據寫入到一個臨時文件中，待持久化過程都結束了，纔會用這個臨時文件替換上次持久化好的文件。正是這種特性，讓我們可以隨時來進行備份，因爲快照文件總是完整可用的。
- 對於RDB方式，redis會單獨創建（fork）一個子進程來進行持久化，而主進程是不會進行任何IO操作的，這樣就確保了redis極高的性能。
- 如果需要進行大規模數據的恢復，且對於數據恢復的完整性不是非常敏感，那RDB方式要比AOF方式更加的高效。
AOF方式
AOF方式是將執行過的寫指令記錄下來，在數據恢復時按照叢前到後的順序再將指令執行一遍。
AOF命令以redis協議追加保存每次寫的操作到文件末尾.Redis還能對AOF文件進行後臺重寫,使得AOF文件的體積不至於過大.默認的AOF持久化策略是每秒鐘fsync一次（fsync是指把緩存中的寫指令記錄到磁盤中），因爲在這種情況下，redis仍然可以保持很好的處理性能，即使redis故障，也只會丟失最近1秒鐘的數據。
-
AOF命令以redis協議追加保存每次寫的操作到文件末尾.Redis還能對AOF文件進行後臺重寫,使得AOF文件的體積不至於過大.默認的AOF持久化策略是每秒鐘fsync一次（fsync是指把緩存中的寫指令記錄到磁盤中），因爲在這種情況下，redis仍然可以保持很好的處理性能，即使redis故障，也只會丟失最近1秒鐘的數據。
-
如果在追加日誌時，恰好遇到磁盤空間滿、inode滿或斷電等情況導致日誌寫入不完整，也沒有關係，redis提供了redis-check-aof工具，可以用來進行日誌修復。
- 因爲採用了追加方式，如果不做任何處理的話，AOF文件會變得越來越大，爲此，redis提供了AOF文件重寫（rewrite）機制，即當AOF文件的大小超過所設定的閾值時，redis就會啓動AOF文件的內容壓縮，只保留可以恢復數據的最小指令集。舉個例子或許更形象，假如我們調用了100次INCR指令，在AOF文件中就要存儲100條指令，但這明顯是很低效的，完全可以把這100條指令合併成一條SET指令，這就是重寫機制的原理。
- 重寫問題：在進行AOF重寫時，仍然是採用先寫臨時文件，全部完成後再替換的流程，所以斷電、磁盤滿等問題都不會影響AOF文件的可用性。