Redis 持久化政策 : RDB持久化、AOF持久化、混合持久化

文章目錄

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

什麼是持久化

由于記憶體具有易失性，無法進行斷電存儲，是以在重新開機之後資料就會丢失，但是硬碟具有永久存儲的特性，是以持久化就是将資料從記憶體中儲存到硬碟的過程，目的就是為了防止資料的丢失。

同時持久化也是Redis比起Memcached的優勢，Memcached并不支援持久化

Redis的持久化分為以下三種

1. RDB（Redis DataBase）持久化
2. AOF（Append Only File）持久化
3. 混合持久化

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的過程給分割開

伺服器流程

1. 執行用戶端發送來的新指令
2. 将執行後的寫指令追加到AOF緩沖區中
3. 将執行後的寫指令追加到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檔案就不能使用在之前的版本