Redis持久化機制比對

[size=large][b]rdb[/b][/size]

1.[color=red]按特定的時間間隔來為資料集做快照[/color]

2.每次持久化都是將全量資料寫入，而不是增量

3.每次寫入時先將資料寫入臨時檔案再替換掉原來的rdb檔案

[b]優點：[/b]

1.rdb是乙個單獨的檔案，方便備份以及災難恢復

2.寫資料的模式為parent程序fork出乙個子程序來進行磁碟io操作，而parent程序則不需要參與io操作

3.在資料比較大的情況下，啟動速度比aof快

[b]缺點：[/b]

1.該模式下如果redis崩潰或者斷電情況下可能有資料丟失；因為rdb是按照固定策略(如10秒刷入一次或者5分鐘內寫入100條資料則刷入磁碟等)來持久化的，那麼則斷電或者服務崩潰的情況下可能會丟失某乙個時間段的資料

2.rdb在程序持久化時需要fork子程序來做磁碟操作，當資料集比較大時fork操作非常耗時，而且在fork過程中server是不能對client服務的；aof雖然也需要fork但是我們可以設定多久重寫一次日誌

[size=large][b]aof[/b][/size]

1.[color=red]服務端為每個寫操作記錄日誌；[/color]

2.如果服務重啟，則根據所記錄的log來進行重放來重建整個資料集。

3.日誌的記錄使用的是redis自己的協議，以追加的模式記錄。

4.如果日誌過大，redis可以在後台重寫日誌檔案

[b]優點：[/b]

1.可以設定各種fsync策略：從不刷資料、每秒同步一次(預設)、每次查詢時同步,使用預設策略時可能會丟失最近一秒資料；當配置從不刷資料是由主線程在當前程序沒有在刷資料時盡可能的來同步資料到檔案，預設策略時會啟動乙個後台子執行緒來同步資料到檔案

2.日誌檔案是追加模式，在斷點後不牽扯到檔案指標查詢以及資料丟失問題；就算是因為某些原因(如磁碟寫滿等)導致日誌檔案最後一條只寫入了一半也可以通過redis-check-aof工具來修復

3.當日誌檔案過大時，redis會自動重寫日誌檔案([color=red]新的檔案只保留建立當前資料集需要用到的命令[/color])；在重寫的過程中同時還會往老的日誌檔案寫入，一旦新的檔案處理完成，redis會切換至新的檔案

4.日誌檔案內容簡單清晰，方便人工干預。例如我們呼叫flushall來重新整理儲存所有資料失敗，如果此時日誌檔案沒有其他命令寫入，我們可以停掉server，刪掉日誌中最後一條錯誤，然後重新啟動來恢復資料

[b]缺點：[/b]

1.相同資料集下，aof模式對應檔案通常比rdb對應檔案大

2.aof在某些策略下比rdb模式慢。比如，將fsync設定為每秒一次時，效能仍然很高；將fsync禁用時，效能和rdb接近

說明：在同乙個例項中可以同時使用rdb和aof持久化機制；但是在服務啟動時使用aof機制來重建資料集(因為aof最大程度的保留了資料的完整性)

選擇：1.如果要嚴格保證資料完整性，則rdb與aof同時使用

2.如果可以容忍少量資料丟失，則使用rdb

3.不建議單獨使用aof(因為rdb備份更方便，重新啟動相對較快；aof可能有bug)

參考：