Redis-第七章節-持久化

Tsing發表於2021-02-06
Redis持久化

目錄

  • 概述
  • RDB
  • AOF
  • 如何選擇持久化機制

1、概述

Redis 是記憶體資料庫，如果不能將記憶體中的資料儲存到磁碟中，那麼一旦伺服器程式退出，伺服器的資料庫資料也會消失，所以Redis提供了持久化的功能,redis分為兩種持久化方式：RDB和AOF。有以下幾個特點：

  • 1.RDB持久化方式能夠在指定的時間間隔能對你的資料進行快照儲存。

  • 2.AOF持久化方式記錄每次對伺服器寫的操作，當伺服器重啟的時候會重新執行這些命令來恢復原始的資料，AOF命令以redis協議追加儲存每次寫的操作到檔案末尾。Redis還能對AOF檔案後臺重寫，使得AOF檔案的體積不至於過大。

  • 3.如果你只希望你的資料在伺服器執行的時候存在，你也可以不使用任何持久化的方式。

  • 4.你也可以同時開啟兩種持久化方式，在這種情況下，當redis重啟的時候會優先載入AOF檔案來恢復原始的資料。因為在通常情況下AOF檔案儲存的資料集要比RDB檔案儲存的資料集要完整。

2、RDB

1、概念

在指定的時間間隔內將記憶體中的資料集快照寫入磁碟中，它恢復的時候是將快照中的檔案直接讀取到記憶體中。

2、持久化機制-BGSAVE


通常，會立即返回ok,Redis程式會執行fork操作建立子程式，Redis在fork時，父程式會繼續為客戶端提供服務，子程式會將資料持久化到硬碟上，然後退出。如果已經在後臺執行儲存或者正在執行另一個非後臺儲存的程式，特別是正在進行AOF寫入時，則會返回錯誤。如果使用了bgsave任務，而正在進行AOF寫入時，該命令將立即返回ok,並計劃在下一次機會執行後臺儲存。阻塞只會在fork階段。
客戶端可以使用lastsave命令檢查操作是否成功。

3、持久化機制-SAVE


不會接受客戶端執行的操作命令，等持久化工作完成之後，會將新的檔案替換舊的檔案。

4、持久化機制-自動觸發

在redis.conf中可以配置，讓使用者自定義save屬性，讓伺服器每一段時間內執行一次bgsave操作。

  # 伺服器在900秒內，對資料庫進行了至少1次修改
  save 900 1
  
  # 伺服器在300秒內，對資料庫進行了至少10次修改
  save 300 10
  
  # 伺服器在60秒內，對資料庫進行了至少10000次修改
  save 60 10000
  
  # bgsave發生錯誤時是否停止寫入，一般為yes
  stop-writes-on-bgsave-error yes
  
  # 持久化時是否使用LZF壓縮字串物件?
  rdbcompression yes
  
  # 是否對rdb檔案進行校驗和檢驗，通常為yes
  rdbchecksum yes
  
  # RDB持久化檔名
  dbfilename dump.rdb
  
  # 持久化檔案儲存目錄
  dir ./

5、恢復資料機制

只需要將rdb檔案放在我們redis啟動目錄就可以了，redis啟動的時候會自動檢查檔案並恢復其中的資料。

6、優點

  • RDB是一個非常緊湊的檔案，它儲存了某個時間點得資料集，非常適用於資料集的備份，比如你可以在每個小時報儲存一下過去24小時內的資料，同時每天儲存過去30天的資料，這樣即使出了問題你也可以根據需求恢復到不同版本的資料集。
  • RDB是一個緊湊的單一檔案，很方便傳送到另一個遠端資料中心或者亞馬遜的S3（可能加密），非常適用於災難恢復。
  • RDB在儲存RDB檔案時父程式唯一需要做的就是fork出一個子程式，接下來的工作全部由子程式來做，父程式不需要再做其他IO操作，所以RDB持久化方式可以最大化redis的效能。
  • 與AOF相比，在恢復大的資料集的時候，RDB方式會更快一些。

7、缺點

  • 如果你希望在redis意外停止工作（例如電源中斷）的情況下丟失的資料最少的話，那麼RDB不適合你。雖然你可以配置不同的save時間點(例如每隔5分鐘並且對資料集有100個寫的操作)，是Redis要完整的儲存整個資料集是一個比較繁重的工作，你通常會每隔5分鐘或者更久做一次完整的儲存，萬一在Redis意外當機，你可能會丟失幾分鐘的資料。

  • RDB 需要經常fork子程式來儲存資料集到硬碟上，當資料集比較大的時候，fork的過程是非常耗時的，可能會導致Redis在一些毫秒級內不能響應客戶端的請求。如果資料集巨大並且CPU效能不是很好的情況下，這種情況會持續1秒，AOF也需要fork，但是你可以調節重寫日誌檔案的頻率來提高資料集的耐久度。

3、AOF

1、概念

以日誌的形式來記錄每個寫操作，將Redis執行過的所有指令記錄下來（讀操作不記錄），只許追加檔案但不可以改寫檔案，Redis啟動之初會讀取該檔案重新構建資料，換言之，Redis重啟的話就會根據日誌檔案的內容將寫的指令從前到後執行一次以完成資料的恢復工作。

2、持久化原理


所有操作的命令會追加在檔案中。

3、開啟AOF持久化

   
   # 開啟aof持久化方式，預設no
   appendonly no
   
   # aof 持久化生成的檔名稱
   appendfilename "appendonly.aof"
   
   # 三種持久化機制
   # appendfsync always
   appendfsync everysec
   # appendfsync no

4、三種觸發持久化機制

  • always
    同步持久化，每次發生資料變更會被立即持久化到硬碟中，效能比較差，但是資料完整性好。

  • everysec
    非同步操作，每秒持久化資料到硬碟一次，可能會丟失一秒的資料。

  • no
    從不持久化到硬碟。

5、AOF檔案損壞

如果 aof 檔案被破壞，redis服務是啟動不了的。redis本身提供了修復了工具。redis-check-aof --fix appendonly.aof

5、優點

  • 根據配置不同的策略，讓你選擇持久化的方式。
  • AOF檔案是一個只進行追加的日誌檔案，所以不需要寫入seek，即使由於某些原因(磁碟空間已滿，寫的過程中當機等等)未執行完整的寫入命令，你也也可使用redis-check-aof工具修復這些問題。
  • Redis 可以在 AOF 檔案體積變得過大時，自動地在後臺對 AOF 進行重寫： 重寫後的新 AOF 檔案包含了恢復當前資料集所需的最小命令集合。 整個重寫操作是絕對安全的，因為 Redis 在建立新 AOF 檔案的過程中，會繼續將命令追加到現有的 AOF 檔案裡面，即使重寫過程中發生停機，現有的 AOF 檔案也不會丟失。 而一旦新 AOF 檔案建立完畢，Redis 就會從舊 AOF 檔案切換到新 AOF 檔案，並開始對新 AOF 檔案進行追加操作。
  • AOF 檔案有序地儲存了對資料庫執行的所有寫入操作，這些寫入操作以 Redis 協議的格式儲存， 因此 AOF 檔案的內容非常容易被人讀懂，對檔案進行分析（parse）也很輕鬆。匯出（export）AOF檔案也非常簡單：舉個例子， 如果你不小心執行了 FLUSHALL 命令， 但只要 AOF 檔案未被重寫，那麼只要停止伺服器，移除 AOF 檔案末尾的 FLUSHALL 命令，並重啟 Redis，就可以將資料集恢復到 FLUSHALL 執行之前的狀態。

6、缺點

  • 對於相同的資料集來說，AOF 檔案的體積通常要大於 RDB 檔案的體積。
  • 根據所使用的 fsync 策略，AOF 的速度可能會慢於 RDB 。 在一般情況下， 每秒 fsync 的效能依然非常高， 而關閉 fsync 可以讓 AOF 的速度和 RDB 一樣快， 即使在高負荷之下也是如此。 不過在處理巨大的寫入載入時，RDB 可以提供更有保證的最大延遲時間（latency）。

4、如何選擇持久化機制

開啟兩種持久化方式，根據自己的業務需求針對redis進行配置的調整。

相關文章