如何在Redis中實現持久化

如何在Redis中實現持久化？針對這個問題，這篇文章詳細介紹了相對應的分析和解答，希望可以幫助更多想解決這個問題的小伙伴找到更簡單易行的方法。

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）。

關于如何在Redis中實現持久化問題的解答就分享到這里了，希望以上內容可以對大家有一定的幫助，如果你還有很多疑惑沒有解開，可以關注億速云行業資訊頻道了解更多相關知識。