什么是Redis持久化

本篇內容介紹了“什么是Redis持久化”的有關知識，在實際案例的操作過程中，不少人都會遇到這樣的困境，接下來就讓小編帶領大家學習一下如何處理這些情況吧！希望大家仔細閱讀，能夠學有所成！

• RDB：快照形式是直接把內存中的數據保存到一個 dump 文件中，恢復時是將快照文件直接讀到內存里。

• AOF：把所有的對Redis的服務器進行修改的命令都存到一個文件里，命令的集合。

Redis默認是快照RDB的持久化方式

RDB

RDB 有兩種觸發方式，分別是自動觸發和手動觸發

• 自動觸發

  在 redis.conf 配置文件中的 SNAPSHOTTING 下，加上如下配置：

  save 900 1：表示900 秒內如果至少有 1 個 key 的值變化，則保存
  save 300 10：表示300 秒內如果至少有 10 個 key 的值變化，則保存
  save 60 10000：表示60 秒內如果至少有 10000 個 key 的值變化，則保存

  
  

  當然如果你只是用Redis的緩存功能，不需要持久化，那么你可以注釋掉所有的 save 行來停用保存功能，也可以使用`redis-cli config set save ""命令

• 手動觸發

  手動觸發Redis進行RDB持久化的命令有兩種：

1. save

   該命令會阻塞當前Redis服務器，執行save命令期間，Redis不能處理其他命令，直到RDB過程完成為止

2. bgsave

   執行該命令時，Redis會在后臺異步進行快照操作，快照同時還可以響應客戶端請求。具體操作是Redis進程執行fork操作創建子進程，RDB持久化過程由子進程負責，完成后自動結束。阻塞只發生在fork階段，一般時間很短

基本上 Redis 內部所有的RDB操作都是采用 bgsave 命令

恢復數據

將備份文件 (dump.rdb) 移動到 redis 安裝目錄并啟動服務即可，redis就會自動加載文件數據至內存了。Redis 服務器在載入 RDB 文件期間，會一直處于阻塞狀態，直到載入工作完成為止。

獲取 redis 的安裝目錄可以使用 config get dir 命令

RDB優勢與劣勢

優勢：

• RDB是一個非常緊湊(compact)的文件，它保存了redis 在某個時間點上的數據集。這種文件非常適合用于進行備份和災難恢復

• 生成RDB文件的時候，redis主進程會fork()一個子進程來處理所有保存工作，主進程不需要進行任何磁盤IO操作

• RDB 在恢復大數據集時的速度比 AOF 的恢復速度要快

劣勢：

• RDB方式數據沒辦法做到實時持久化/秒級持久化。因為bgsave每次運行都要執行fork操作創建子進程，屬于重量級操作(內存中的數據被克隆了一份，大致2倍的膨脹性需要考慮)，頻繁執行成本過高(影響性能)

• RDB文件使用特定二進制格式保存，Redis版本演進過程中有多個格式的RDB版本，存在老版本Redis服務無法兼容新版RDB格式的問題(版本不兼容)

• 在一定間隔時間做一次備份，所以如果redis意外down掉的話，就會丟失最后一次快照后的所有修改(數據有丟失)

AOF

AOF配置

在 redis.conf 配置文件的 APPEND ONLY MODE 下：

• appendonly no 默認配置，表示不開啟AOF持久化

• appendfilename “appendonly.aof” AOF日志文件名

• appendfsync： aof持久化策略的配置；

• no表示不執行fsync，由操作系統保證數據同步到磁盤，速度最快，但是不太安全；

• always表示每次寫入都執行fsync，以保證數據同步到磁盤，效率很低；

• everysec表示每秒執行一次fsync，可能會導致丟失這1s數據。通常選擇 everysec ，兼顧安全性和效率

AOF文件恢復

重啟 Redis 之后就會進行 AOF 文件的載入

AOF重寫

AOF文件不斷變大，Redis為了解決這種情況，在文件大小達到一定閾值后，進行AOF重寫，對AOF文件進行壓縮，只保留可以恢復數據的最小指令集

舉個例子：

sadd key "A" "B" "C"

如果不重寫會保留三條sadd指令，但是重寫只會保留一條

• 執行AOF重寫的時候，會直接讀取服務器內存的所有鍵值對，不是對之前的AOF文件進行整理

• 子進程進行 AOF 重寫期間，服務器進程（父進程）可以繼續處理其他命令

• 子進程帶有父進程的數據副本，使用子進程而不是線程，可以在避免使用鎖的情況下，保證數據的安全性

主進程和子進程之前可能會產生數據不一致，解決方案：

Redis 服務器設置了一個 AOF 重寫緩沖區，這個緩沖區是在創建子進程后開始使用，當Redis服務器執行一個寫命令之后，就會將這個寫命令也發送到 AOF 重寫緩沖區。當子進程完成 AOF 重寫之后，就會給父進程發送一個信號，父進程接收此信號后，就會調用函數將 AOF 重寫緩沖區的內容都寫到新的 AOF 文件中

AOF優缺點

優點：

• AOF 持久化的方法提供了多種的同步頻率，即使使用默認的同步頻率每秒同步一次，Redis 最多也就丟失 1 秒的數據而已

• AOF 文件使用 Redis 命令追加的形式來構造，因此，即使 Redis 只能向 AOF 文件寫入命令的片斷，使用 redis-check-aof 工具也很容易修正 AOF 文件

• AOF 文件的格式可讀性較強，這也為使用者提供了更靈活的處理方式。例如，如果我們不小心錯用了 FLUSHALL 命令，在重寫還沒進行時，我們可以手工將最后的 FLUSHALL 命令去掉，然后再使用 AOF 來恢復數據。

缺點：

• 對于具有相同數據的的 Redis，AOF 文件通常會比 RDF 文件體積更大

• 在 Redis 的負載較高時，RDB 比 AOF 具好更好的性能保證

• AOF可能存在bug

“什么是Redis持久化”的內容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業相關的知識可以關注億速云網站，小編將為大家輸出更多高質量的實用文章！