Redis持久化機制比對

RDB

1.按特定的時間間隔來為數據集做快照

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

3.每次寫入時先將數據寫入臨時文件再替換掉原來的rdb文件

優點：

1.RDB是一個單獨的文件，方便備份以及災難恢復

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

3.在數據比較大的情況下，啟動速度比AOF快

缺點：

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

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

AOF

1.服務端為每個寫操作記錄日誌；

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

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

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

優點：

1.可以設置各種fsync策略：從不刷數據、每秒同步一次(默認)、每次查詢時同步,使用默認策略時可能會丟失最近一秒數據；當配置從不刷數據是由主線程在當前進程沒有在刷數據時儘可能的來同步數據到文件，默認策略時會啟動一個後檯子線程來同步數據到文件

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

3.當日誌文件過大時，redis會自動重寫日誌文件(新的文件只保留創建當前數據集需要用到的命令)；在重寫的過程中同時還會往老的日誌文件寫入，一旦新的文件處理完成，redis會切換至新的文件

4.日誌文件內容簡單清晰，方便人工干預。例如我們調用flushall來刷新保存所有數據失敗，如果此時日誌文件沒有其他命令寫入，我們可以停掉server，刪掉日誌中最後一條錯誤，然後重新啟動來恢複數據

缺點：

1.相同數據集下，AOF模式對應文件通常比RDB對應文件大

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

3.有些命令可能在AOF下有問題，如BRPOPLPUSH命令在AOF下重新載入時重放失敗

說明：

在同一個實例中可以同時使用RDB和AOF持久化機制；但是在服務啟動時使用AOF機制來重建數據集(因為AOF最大程度的保留了數據的完整性)

選擇：

1.如果要嚴格保證數據完整性，則RDB與AOF同時使用

2.如果可以容忍少量數據丟失，則使用RDB

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

參考：

https://redis.io/topics/persistence

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！