我們已經知道對於一個企業級的redis架構來說，持久化是不可減少的

企業級redis叢集架構：海量資料、高併發、高可用
持久化主要是做災難恢復，資料恢復，也可以歸類到高可用的一個環節裡面去，比如你redis整個掛了，然後redis就不可用了，你要做的事情是讓redis變得可用，儘快變得可用。此時你需要重啟redis，儘快讓它對外提供服務，但是如果你沒做資料備份，這個時候redis啟動了，裡面也是沒有資料的所以一樣也用不了，也沒辦法向外提供服務。所以當此刻有大量的請求過來，快取全部無法命中，在redis里根本找不到資料，這個時候系統，快取雪崩問題，所有請求，沒有在redis命中，就會去mysql資料庫這種資料來源頭中去找，一下子mysql承接高併發，然後就掛了。mysql掛掉，你都沒法去找資料恢復到redis裡面去，redis的資料從哪兒來？從mysql來。具體的完整的快取雪崩的場景，還有企業級的解決方案，會在後面的文章中解釋。

如果你把redis的持久化做好，備份和恢復方案做到企業級的程度，那麼即使你的redis故障了，也可以通過備份資料，快速恢復，一旦恢復立即對外提供服務。

1、RDB和AOF兩種持久化機制的介紹

redis持久化：RDB，AOF

1）、RDB持久化機制，對redis中的資料進行週期性的持久化。

2）、AOF機制對每條寫入命令作為日誌，以append-only的模式寫入一個日誌檔案中，在redis重啟的時候，可以通過回放AOF日誌中的寫入指令來重新構建整個資料集。

3）、通過RDB或AOF，都可以將redis記憶體中的資料給持久化到磁碟上，然後可以將這些資料備份到別的地方，比如說阿里雲，華為雲等雲服務。此時如果redis掛了，伺服器上的記憶體和磁碟上的資料都丟了，可以從雲服務上拷貝回來之前的資料，放到指定的目錄中，然後重新啟動redis，redis就會自動根據持久化資料檔案中的資料，去恢復記憶體中的資料，繼續對外提供服務。

注意 1、：如果同時使用RDB和AOF兩種持久化機制，那麼在redis重啟的時候，會使用AOF來重新構建資料，因為AOF中的資料更加完整（優先載入）

注意 2、：如果我們想要redis僅僅作為純記憶體的快取來用，那麼可以禁止RDB和AOF的持久化機制

2、RDB持久化機制的優點

1）、RDB會生成多個數據檔案，每個資料檔案都代表了某一個時刻中redis的資料，這種多個數據檔案的方式，非常適合做冷備，可以將這種完整的資料檔案傳送到一些遠端的安全儲存上去，比如華為雲、阿里雲等雲端儲存上，按照制定好的備份策略來定期備份redis中的資料。

2）、RDB這種持久化機制對redis對外提供的讀寫服務，影響非常小，可以讓redis保持高效能，因為redis主程序只需要fork一個子程序，讓子程序執行磁碟IO操作來進行RDB持久化即可。

3）、相對於AOF持久化機制來說，直接基於RDB這種持久化機制生成的資料檔案來重啟和恢復redis程序更加快速，因為不像AOF那樣需要一步一步的回放之前的操作指令之後，再進行恢復。（容易發生問題，難免出錯）

3、RDB持久化機制的缺點

1）、如果想要在redis發生故障時，儘可能少的丟失資料，那麼RDB持久化機制沒有AOF持久化機制好。通常情況下，RDB持久化機制產生的資料快照檔案，都是每隔5分鐘，或者更長時間生成一次，如果這個時候就redis程序宕機的話，那麼就難免會丟失最近5分鐘的資料。

2）、RDB這種持久化機制每次在fork子程序來執行RDB快照資料檔案生成的時候，如果需要備份的資料檔案特別大的話，可能會導致redis對客戶端提供的服務暫停數毫秒，或者甚至數秒，造成不好的使用者體驗。

4、AOF持久化機制的優點

1）、相比RDB的這種持久化機制來說AOF可以更好的保護資料的完整性，一般AOF持久化機制會每隔1秒，通過一個後臺執行緒執行一次fsync操作，所以redis出現問題最多會丟失1秒鐘的資料。

2）、AOF持久化機制生成的日誌檔案是以append-only模式寫入，所以沒有任何磁碟定址的開銷，寫入效能非常高，而且檔案不容易破損，即使檔案尾部破損，也很容易修復。

3）、AOF日誌檔案即使過大的時候，出現後臺重寫操作，也不會影響客戶端的讀寫。因為在rewrite log的時候，會對其中的指令進行壓縮，創建出一份需要恢復資料的最小日誌出來。在建立新日誌檔案的時候，老的日誌檔案還是照常寫入。當新的merge後的日誌檔案ready的時候，再交換新老日誌檔案即可。（就是把當前老的日誌資料壓縮一下，生成新的日誌，新來的資料還是繼續往老的日誌檔案寫，之後等新的資料壓縮完之後，把老日誌中新寫入的資料寫入再新的日誌，之後新的日誌檔案替換掉老的日誌檔案即可）。

4）、AOF日誌檔案的命令通過非常可讀的方式進行記錄，這個特性非常適合做災難性的誤刪除的緊急恢復。比如不小心用flushall命令清空了所有資料，只要這個時候後臺rewrite還沒有發生，那麼就可以立即拷貝AOF檔案，將最後一條flushall命令給刪了，然後再將該AOF檔案放回去，就可以通過恢復機制，自動恢復所有資料。

5、AOF持久化機制的缺點

1）、對於同一份資料來說，AOF日誌檔案通常比RDB資料快照檔案更大。

2）、當AOF開啟後，支援的寫QPS會比RDB支援的寫QPS低，因為AOF一般會配置成每秒fsync一次日誌檔案，當然，每秒一次fsync，效能也還是很高的。（QPS只每秒支援的訪問請求）。

3）、如果AOF發生bug，就是通過AOF記錄的日誌，進行資料恢復的時候，沒有恢復一模一樣的資料出來。所以說，類似AOF這種較為複雜的基於命令日誌merge回放的方式，比基於RDB每次持久化一份完整的資料快照檔案的方式，更加脆弱一些，容易出現bug。不過AOF就是為了避免rewrite過程導致的bug，因此每次rewrite並不是基於舊的指令日誌進行merge的，而是基於當時記憶體中的資料進行指令的重新構建，這樣健壯性會好很多。

6、RDB和AOF到底該如何選擇

1）、不要僅僅使用RDB的持久化機制，因為那樣會導致你丟失很多資料。

2）、也不要僅僅使用AOF的持久化機制，因為那樣有兩個問題：

第一、你通過AOF做冷備，沒有RDB做冷備來的恢復速度更快; 

第二、RDB每次簡單粗暴生成資料快照，更加健壯，可以避免AOF這種複雜的備份和恢復機制的bug；

3）、綜合使用AOF和RDB兩種持久化機制：

第一、用AOF來保證資料不丟失（資料丟失相對較少），作為資料恢復的第一選擇; 用RDB來做不同程度的冷備；

第二、在AOF檔案都丟失或損壞不可用的時候，還可以使用RDB來進行快速的資料恢復

幫忙關注一下 微信公眾號一起學習 ：chengxuyuan95（不一樣的程式設計師）

相關推薦