redis 之 持久化

zero_vic發表於2020-07-27
Redis持久化

Redis支援RDB和AOF兩種持久化機制，持久化功能有效地避免因程式退出造成的資料丟失問題，當下次重啟時利用之前持久化的檔案即可實現資料恢復。

1、RDB持久化

RDB持久化是指在指定的時間間隔內將記憶體中的資料集快照寫入磁碟。也是預設的持久化方式，這種方式是就是將記憶體中資料以快照的方式寫入到二進位制檔案中,預設的檔名為dump.rdb。

1.1、觸發機制

對RDB來說，提供了三種觸發機制：save、bgsave、自動化。

1.1.1、save

該命令會阻塞當前Redis伺服器，執行save命令期間，Redis不能處理其他命令，直到RDB過程完成為止。具體流程如下：

 

 執行完成時候如果存在老的RDB檔案，就把新的替代掉舊的。我們的客戶端可能都是幾萬或者是幾十萬，這種方式顯然不可取。

1.1.2、bgsave

執行該命令時，Redis會在後臺非同步進行快照操作，快照同時還可以響應客戶端請求。具體流程如下：

具體操作是Redis程式執行fork操作建立子程式，RDB持久化過程由子程式負責，完成後自動結束。阻塞只發生在fork階段，一般時間很短。基本上 Redis 內部所有的RDB操作都是採用 bgsave 命令。

1.1.3、自動觸發

自動觸發是由我們的配置檔案來完成的。在redis.conf配置檔案中，裡面有如下配置：

# redis是基於記憶體的資料庫，可以通過設定該值定期寫入磁碟。
# 註釋掉“save”這一行配置項就可以讓儲存資料庫功能失效 
# 900秒（15分鐘）內至少1個key值改變（則進行資料庫儲存--持久化） 
# 300秒（5分鐘）內至少10個key值改變（則進行資料庫儲存--持久化） 
# 60秒（1分鐘）內至少10000個key值改變（則進行資料庫儲存--持久化）
save 900 1
save 300 10
save 60 10000

#當RDB持久化出現錯誤後，是否依然進行繼續進行工作，yes：不能進行工作，no：可以繼續進行工作，可以通過info中的rdb_last_bgsave_status瞭解RDB持久化是否有錯誤
stop-writes-on-bgsave-error yes

#使用壓縮rdb檔案，rdb檔案壓縮使用LZF壓縮演算法，yes：壓縮，但是需要一些cpu的消耗。no：不壓縮，需要更多的磁碟空間
rdbcompression yes

#是否校驗rdb檔案。從rdb格式的第五個版本開始，在rdb檔案的末尾會帶上CRC64的校驗和。這跟有利於檔案的容錯性，但是在儲存rdb檔案的時候，會有大概10%的效能損耗，所以如果你追求高效能，可以關閉該配置。
rdbchecksum yes

#rdb檔案的名稱
dbfilename dump.rdb

#資料目錄，資料庫的寫入會在這個目錄。rdb、aof檔案也會寫在這個目錄
dir /data

1.2、RDB的優勢和劣勢

優勢

  1. RDB 在恢復大資料集時的速度比 AOF 的恢復速度要快。
  2. dump.db是一個二進位制檔案，檔案佔用空間小。
  3. 生成RDB檔案的時候，redis主程式會fork()一個子程式來處理所有儲存工作，主程式不需要進行任何磁碟IO操作

劣勢

  1. 當出現異常退出時，會丟失最後一次快照後的資料
  2. 當fork的時候，記憶體的中的資料會被克隆一份，大致兩倍的膨脹需要考慮。而且，當資料過大時，fork操作佔用過多的系統資源，造成主伺服器程式假死
  3. RDB方式資料沒辦法做到實時持久化/秒級持久化。因為bgsave每次運 行都要執行fork操作建立子程式，屬於重量級操作，頻繁執行成本過高。

1.3、使用場景

  1. 資料備份
  2. 可容忍部分資料丟失
  3. 跨資料中心的容災備份

2、AOF持久化

以日誌的形式來記錄每個寫操作，將Redis執行過的所有寫指令記錄下來（讀操作不記錄），只許追加檔案但不可以改寫檔案，redis啟動之初會讀取改檔案重新構建資料。儲存的是appendonly.aof檔案。

2.1、使用AOF

AOF預設是不開啟的，需要手動在配置檔案中配置。

appendonly yes

可以在redis.conf中配置檔名稱，預設為appendonly.aof

 

2.2、AOF持久化策略

#aof持久化策略的配置
#no表示不執行fsync，由作業系統保證資料同步到磁碟，速度最快。
#always表示每次寫入都執行fsync，以保證資料同步到磁碟。
#everysec表示每秒執行一次fsync，可能會導致丟失這1s資料。
appendfsync everysec

2.3、AOF重寫

AOF採用檔案追加方式，檔案會越來越大為避免出現此種情況，新增了重寫機制,當AOF檔案的大小超過所設定的閾值時，Redis就會啟動AOF檔案的內容壓縮，只保留可以恢復資料的最小指令集.可以使用命令bgrewriteaof。

2.3.1、如何實現重寫的？

AOF檔案持續增長而過大時，會fork出一條新程式來將檔案重寫(也是先寫臨時檔案最後再rename)，遍歷新程式的記憶體中資料，每條記錄有一條的Set語句。重寫aof檔案的操作，並沒有讀取舊的aof檔案，而是將整個記憶體中的資料庫內容用命令的方式重寫了一個新的aof檔案，這點和快照有點類似。

2.3.2、AOF重寫觸發機制

AOF重寫過程可以手動觸發和自動觸發：

手動觸發：直接呼叫bgrewriteaof命令。

自動觸發：根據auto-aof-rewrite-min-size和auto-aof-rewrite-percentage引數確定自動觸發時機

auto-aof-rewrite-min-size：表示執行AOF重寫時檔案最小體積，預設 為64MB。

auto-aof-rewrite-percentage：代表當前AOF檔案空間 （aof_current_size）和上一次重寫後AOF檔案空間（aof_base_size）的比值。

自動觸發時機=aof_current_size>auto-aof-rewrite-minsize&&（aof_current_size-aof_base_size）/aof_base_size>=auto-aof-rewritepercentage

其中aof_current_size和aof_base_size可以在info Persistence統計資訊中檢視

2.4、AOF的優勢和劣勢

AOF的優勢：

  1. 備份機制更穩健，丟失資料概率更低
  2. 可讀的日誌文字，通過操作AOF穩健，可以處理誤操作。
  3. AOF日誌檔案沒有任何磁碟定址的開銷，寫入效能非常高，檔案不容易破損。

AOF的劣勢：

  1. 比起RDB更佔用磁碟空間。
  2. 回覆備份的速度慢。
  3. 每次讀寫同步的話，有一定的效能壓力。
  4. 存在BUG，可能不能完全恢復一摸一樣的資料。

3、AOF和RDB同時開啟，Redis聽誰的？

同時開啟Redis執行AOF。具體流程如下：

 

 

 

相關文章