【Java面試】RDB 和 AOF 的實現原理、優缺點

Hi，大家好，我是Mic。

一個工作了5年的粉絲私信我，最近面試碰到很多Redis相關的問題。

其中一個面試官問他Redis裡面的持久化機制，沒有回答得很好。

希望我幫他系統回答一下。

關於Redis裡面的RDB和AOF兩種持久化機制的原理和優缺點這個問題。

下面看看普通人和高手的回答。

普通人：

RDB是一種快照的方式然後AOF是一種就是指令追加的方式。

它們兩個都是Redis裡面的一種資料持久化的一個機制。

RDB它是快照嘛，快照的話它的那個時間間隔它會有一個配置但是這種配置過程中就是有可能會導致說我的資料丟失的一個問題。

但是AOF它是那種就是追加的方式嘛，所以它的一個數據安全性可能會比RDB會好一點。

高手：

好的，關於這個問題，我從幾個點來回答。

首先，Redis本身是一個基於Key-Value結構的記憶體資料庫，為了避免Redis故障導致資料丟失的問題，所以提供了RDB和AOF兩種持久化機制。

RDB是通過快照的方式來實現持久化的，也就是說會根據快照的觸發條件，把記憶體裡面的資料快照寫入到磁碟，

以二進位制的壓縮檔案進行儲存。

RDB快照的觸發方式有很多，比如

• 執行bgsave命令觸發非同步快照，執行save命令觸發同步快照，同步快照會阻塞客戶端的執行指令。
• 根據redis.conf檔案裡面的配置，自動觸發bgsave
• 主從複製的時候觸發

AOF持久化，它是一種近乎實時的方式，把Redis Server執行的事務命令進行追加儲存。簡單來說，

就是客戶端執行一個數據變更的操作，Redis Server就會把這個命令追加到aof緩衝區的末尾，

然後再把緩衝區的資料寫入到磁碟的AOF檔案裡面，至於最終什麼時候真正持久化到磁碟，是根據刷盤的策略來決定的。

另外，因為AOF這種指令追加的方式，會造成AOF檔案過大，帶來明顯的IO效能問題，所以Redis針對這種情況提供了

AOF重寫機制，也就是說當AOF檔案的大小達到某個閾值的時候，就會把這個檔案裡面相同的指令進行壓縮。

因此，基於對RDB和AOF的工作原理的理解，我認為RDB和AOF的優缺點有兩個。

• RDB是每隔一段時間觸發持久化，因此資料安全性低，AOF可以做到實時持久化，資料安全性較高
• RDB檔案預設採用壓縮的方式持久化，AOF儲存的是執行指令，所以RDB在資料恢復的時候效能比AOF要好

在我看來，所謂優缺點，本質上其實是哪種方案更適合當前的應用場景而已。

以上就是我對這個問題的理解！

總結

這個問題的實際意義在於，求職者要知道在什麼場景下選擇什麼樣的持久化策略。

因此如果能夠對AOF和RDB這兩種持久化方式有比較深入的理解，

那自然也就能夠在實際開發中合理的進行應用了。

喜歡我作品的小夥伴，記得點贊收藏加關注。

版權宣告：本部落格所有文章除特別宣告外，均採用 CC BY-NC-SA 4.0 許可協議。轉載請註明來自 Mic帶你學架構 ！

如果本篇文章對您有幫助，還請幫忙點個關注和贊，您的堅持是我不斷創作的動力。歡迎關注「跟著Mic學架構」公眾號公眾號獲取更多技術乾貨！