文章目錄

• 什么是持久化
• RDB持久化
• • SAVA與BGSAVA
  • RDB持久化的優缺點
• AOF持久化
• • AOF重寫
  • AOF持久化的優缺點
• 混合持久化
• • 混合持久化的優缺點

---

什么是持久化

由于內存具有易失性，無法進行斷電存儲，所以在重啟之后數據就會丟失，但是硬盤具有永久存儲的特性，所以持久化就是將數據從內存中保存到硬盤的過程，目的就是為了防止數據的丟失。
同時持久化也是Redis比起Memcached的優勢，Memcached并不支持持久化

Redis的持久化分為以下三種

RDB（Redis DataBase）持久化

AOF（Append Only File）持久化

混合持久化

---

RDB持久化

RDB持久化其實就是以快照的方式進行持久化的存儲。

對于一個Redis服務器來說，它的所有非空數據庫以及數據庫中的所有鍵值對就是當前數據庫的狀態。所以只需要將數據庫的狀態保存在硬盤當中，即使服務器停機或者斷電，只要硬盤中存儲的狀態還在，就可以通過它來還原數據庫原來的狀態。

為了保證文件的安全以及容量更小，RDB持續化所生成的RDB文件是一個經過壓縮的二進制文件，通過這個文件就可以還原數據庫的狀態。

---

SAVA與BGSAVA

RDB持久化根據執行持久化的對象不同又分為SAVA和BGSAVA兩種方式

SAVA即讓Redis服務進程來執行持久化，所以直到RDB持久化結束之前，Redis服務進程會一直處于阻塞狀態，無法處理任何命令。

BGSAVE則會通過fork()來創建一個子進程，然后讓子進程來接管RDB持久化，而父進程繼續處理命令請求

由于SAVA的會導致主進程的阻塞，所以使用時基本不會考慮，所以通常我們都會默認使用BGSAVA來進行，下面我指的也都是BGSAVA

---

RDB持久化的優缺點

優點：

• RDB文件是經過壓縮的二進制文件，占用內存更小更緊湊，適合作為備份文件
• RDB容災恢復更有用，因為其更加緊湊，可以更快的傳輸到遠程服務器進行數據恢復。
• RDB可以提高Redis的運行速度，因為使用BGSAVA持久化時會fork出子進程進行持久化的I/O操作，主進程不會受到干擾。
• 比起AOF格式的文件，RDB文件這種直接恢復狀態的重啟更快
  缺點：
• 由于RDB是以快照形式進行保存的，并且快照之間存在一定的時間間隔，如果Redis服務被終止，則會導致丟失一段時間的數據
• RDB的BGSAVA需要fork()出子進程來進行持久化，但是如果CPU性能不佳且數據量很大的時候，fork()的時間就會增加，導致Redis可能會停止服務一段時間。

---

AOF持久化

AOF持久化其實就是保存Redis服務器所執行的命令來保存數據庫的狀態，將命令追加到AOF文件的末尾（Append Only File），AOF的核心其實就是將所有執行過的命令重新執行，來恢復狀態

什么意思呢？例如我們執行了幾條命令，此時AOF持久化會將這些命令以請求協議格式追加到AOF文件末尾

當服務器啟動時，就會讀取AOF文件中的所有命令，將其在服務器上重新執行一次，來恢復服務器的狀態。

---

AOF重寫

隨著服務器存儲的數據越來越多，此時AOF保存的命令也越來越多，文件的體積就會變得非常大，這樣就可能導致對Redis服務器以及宿主機造成影響，并且隨著文件的增大，使用AOF來進行數據還原需要的時間也就更多。

并且還存在一個問題，就是命令中存在著大量冗余和多余的命令。

127.0.0.1:6379> lpush list2 5 2 1 3 4 (integer) 5 127.0.0.1:6379> lpop list2 "4" 127.0.0.1:6379> rpop list2 "5"

例如上面這些命令，我存儲了5 2 1 3 4五個數據，之后我又刪除了4和5，所以最終剩下的只有1 2 3。
但是如果將所有的命令都保存進去，在恢復狀態的時候又會重新模擬一次中間的刪除流程，這些步驟是不需要的，我們只需要最終的結果。

所以AOF引入了重寫的機制，即只保存能夠獲取最終結果的命令
重寫的流程很簡單，就是去直接讀取當前數據庫中的鍵值狀態，然后構造出對應的命令來進行保存
例如上面那個，就直接進行一次lpush 1 2 3，就可以直接省去了中間的操作。

并且和RDB的BGSAVA一樣，為了不阻塞主進程，所有的重寫操作都會通過創建子進程來進行，并且由于子進程創建時會通過寫時拷貝機制帶有服務器數據的副本，所以也不需要對數據進行加鎖就可以保證安全，提高了效率

此時子進程進行AOF的重寫，父進程則繼續處理接受的請求。
但是這時又引入了一個問題，如果父進程接受了新的命令，這些命令可能就會對數據庫的狀態進行修改，這樣就會導致重寫后的AOF文件所保存的狀態和當前的數據庫狀態不一致。

為了解決這個問題，服務器新增了一個AOF重寫緩沖區，將兩個AOF的過程給分割開
服務器流程

執行客戶端發送來的新命令

將執行后的寫命令追加到AOF緩沖區中

將執行后的寫命令追加到AOF重寫緩沖區中

這樣AOF緩沖區的數據會被定期寫入和同步到AOF文件中，不會影響整個AOF的流程。
而在執行重寫后所執行的命令也都會保存到AOF重寫緩沖區中。

所以在子進程重寫結束后，其會通過信號的方式來通知父進程，此時服務器就會進行以下的操作來完成重寫的AOF文件的更換

• 將當前AOF重寫緩沖區中的命令保存到一個新的AOF文件中，此時的新AOF文件的狀態與當前數據庫保存一致，并且比起舊的AOF更加簡潔
• 此時對新的AOF文件進行改名，原子性的覆蓋掉原先的AOF文件，完成AOF重寫文件與舊文件的更替

---

AOF持久化的優缺點

優點

• AOF持久化保存的數據更加完整，其設定了三種保存策略：每次操作保存、每秒鐘保存、跟隨系統的持久化策略保存，其中每秒保存一次為AOF的默認策略。通過這種方法，使得即使發生了意外情況，最多也只會丟失1秒的數據，而不像RDB會丟失一段時間的數據
• AOF如其名，采用了命令追加的方式寫入到文件中，所以不會出現文件損壞的問題
• AOF持久化將命令以協議格式寫入文件，非常容易理解和解析，即使不小心使用flushall進行刪庫，并且狀態被保存了下來。也可以通過刪除AOF文件中的flushall命令來消除那次操作。（RDB快照則沒辦法避免）

缺點

• 在數據量相同的時候，AOF文件要大于RDB文件
• 在Redis負載較高的時候，RDB的性能比AOF更好
• RDB使用快照的形式來持久化整個Redis數據，而AOF是將每次執行的命令追加到AOF文件中，所以RDB比AOF更健壯

---

混合持久化

混合持久化是在Redis4.0之后新增的一種方式，混合持久化結合了RDB和AOF的優點，在寫入文件的時候，會先把當前的數據以RDB的形式寫入文件的開頭，再將后續的操作命令以AOF的格式寫入文件中，這樣既能保證Redis重啟時的速度（RDB快照狀態恢復），又能減少數據丟失的風險（AOF丟失時間短）

---

混合持久化的優缺點

優點

• 結合了RDB和AOF的優點，開頭為RDB格式的數據，可以快速啟動（快照），并且之后為AOF格式，減少了大量數據丟失的風險
  缺點
• AOF文件可讀性變差，因為AOF文件前面增加了RDB格式的內容
• 兼容性差，由于混合持久化是在4.0之后才引入的，如果開啟之后則混合持久化AOF文件就不能使用在之前的版本

總結

以上是生活随笔為你收集整理的Redis 持久化策略 : RDB持久化、AOF持久化、混合持久化的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。