Redis備份方式總結

本篇內容主要講解“Redis備份方式總結”，感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷，實用性強。下面就讓小編來帶大家學習“Redis備份方式總結”吧!

一、redis持久化的兩種方式：

RDB: 對內存中數據庫狀態進行快照

AOF: 把每條寫命令都寫入文件

RDB方式：將redis在內存中的數據庫狀態保存到磁盤里面，RDB文件是一個經過壓縮的二進制文件，通過該文件可以還原生成RDB文件的數據狀態。

RDB的生成方式：

指向命令手動生成

通過配置自動生成

1.指向命令手動生成

有兩個redis命令可以生成RDB文件，一個是SAVE，另一個是BGSAVE，SAVE命令會阻塞redis服務器進程，直到RDB文件創建完畢為止，在服務器阻塞期間,服務器不能處理任何的進程,BGSAVE會派出一個子進程，然后由子進程負責創建RDB。文件，服務器進程（父進程）繼續處理命令請求，創建RDB文件結束之前，客戶端發送的 BGSAVE 和 SAVE 命令會被服務器拒絕。

2.通過配置自動生成?

可以設置服務器配置的save選項，讓服務器每隔一段時間自動執行一次BGSAVE命令，可以通過save選項設置多個保存條件，但只要其中任意一個條件被滿足就會執行BGSAGE命令。

例如：

save 900 1

save 300 10

save 60  10000

那么只要滿足以下三個條件中的其中一個，BGSAVE命令就會被執行

服務器在 900 秒之內，對數據庫進行了 1 次修改

服務器在 300 秒之內，對數據庫進行了 10 次修改

服務器在 60 秒之內，對數據庫進行了 10000 次修改

AOF方式：是通過保存redis服務器所執行的寫命令來記錄數據庫狀態的AOF文件刷新方式，有三種：

1.appendfsync always -- 每提交一個修改命令都調用fsync到AOF文件，非常慢，但是很安全；

2.appendfsync everysec -- 每秒都調用fsyns刷新到AOF文件，很快但可能丟失一秒內的數據；

3.appendfsync no -- 依靠OS進行刷新，redis不主動刷新AOF，這樣最快但是安全性差；

默認并且推薦每秒刷新，這樣在速度和安全上都做到了兼顧

二、數據恢復

1.ROB方式

ROB文件的載入工作是在服務器啟動時自動執行的，沒有專門用于載入ROB文件命令，只要redis服務器再啟動時檢測到

ROB文件存在，它就會自動載入ROB的文件，在服務器載入的期間，會一直處于阻塞狀態，直到載入工作完成為止

2.AOF方式

服務器在啟動時，通過載入和執行AOF文件中保存的命令來還原服務器關閉之前的數據，具體過程：

載入AOF文件

創建模擬客戶端

從AOF文件中讀取一條命令

使用模擬客戶端執行命令

循環讀取并執行命令，直到全部完成

如果同時啟動了AOF和ROB方式，AOF優先，啟動時只加載AOF文件恢復數據

三、RDB和AOF對比總結

1、RDB

是在某個時間點將數據寫入一個臨時文件，持久化結束后，用這個臨時文件替換上次持久化的文件，達到數據恢復。 這里說的這個執行數據寫入到臨時文件的時間點是可以通過配置來自己確定的，通過配置redis在n秒內如果超過m個key被修改這執行一次RDB操作。這個操作就類似于在這個時間點來保存一次Redis的所有數據，一次快照數據。所有這個持久化方法也通常叫做snapshots。

2、AOF

Append-only file，將“操作 + 數據”以格式化指令的方式追加到操作日志文件的尾部，在append操作返回后(已經寫入到文件或者即將寫入)，才進行實際的數據變更，“日志文件”保存了歷史所有的操作過程；當server需要數據恢復時，可以直接replay此日志文件，即可還原所有的操作過程。AOF相對可靠，它和mysql中bin.log、apache.log、zookeeper中txn-log簡直異曲同工。AOF文件內容是字符串，非常容易閱讀和解析。

3、兩種備份方案的選擇：

對于RDB持久化，

一方面是bgsave在進行fork操作時redis主進程會阻塞，

另一方面，子進程向硬盤寫數據也會帶來IO壓力，但數據的完整性和一致性受備份條件影響可能較差；而AOF持久化由于持續的寫入IO壓力更大，但數據的一致性和完整性較好。

到此，相信大家對“Redis備份方式總結”有了更深的了解，不妨來實際操作一番吧！這里是億速云網站，更多相關內容可以進入相關頻道進行查詢，關注我們，繼續學習！