如何在Redis中實現(xiàn)持久化

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

1、概述

Redis 是內存數(shù)據庫，如果不能將內存中的數(shù)據保存到磁盤中，那么一旦服務器進程退出，服務器的數(shù)據庫數(shù)據也會消失，所以Redis提供了持久化的功能,redis分為兩種持久化方式：RDB和AOF。有以下幾個特點：

1.RDB持久化方式能夠在指定的時間間隔能對你的數(shù)據進行快照存儲。

2.AOF持久化方式記錄每次對服務器寫的操作，當服務器重啟的時候會重新執(zhí)行這些命令來恢復原始的數(shù)據，AOF命令以redis協(xié)議追加保存每次寫的操作到文件末尾。Redis還能對AOF文件后臺重寫，使得AOF文件的體積不至于過大。

3.如果你只希望你的數(shù)據在服務器運行的時候存在，你也可以不使用任何持久化的方式。

4.你也可以同時開啟兩種持久化方式，在這種情況下，當redis重啟的時候會優(yōu)先載入AOF文件來恢復原始的數(shù)據。因為在通常情況下AOF文件保存的數(shù)據集要比RDB文件保存的數(shù)據集要完整。

2、RDB

1、概念

在指定的時間間隔內將內存中的數(shù)據集快照寫入磁盤中，它恢復的時候是將快照中的文件直接讀取到內存中。

2、持久化機制-BGSAVE

通常，會立即返回ok,Redis進程會執(zhí)行fork操作創(chuàng)建子進程，Redis在fork時，父進程會繼續(xù)為客戶端提供服務，子進程會將數(shù)據持久化到硬盤上，然后退出。如果已經在后臺執(zhí)行保存或者正在運行另一個非后臺保存的進程，特別是正在進行AOF寫入時，則會返回錯誤。如果使用了bgsave任務，而正在進行AOF寫入時，該命令將立即返回ok,并計劃在下一次機會運行后臺保存。阻塞只會在fork階段。
客戶端可以使用lastsave命令檢查操作是否成功。

3、持久化機制-SAVE

不會接受客戶端執(zhí)行的操作命令，等持久化工作完成之后，會將新的文件替換舊的文件。

4、持久化機制-自動觸發(fā)

在redis.conf中可以配置，讓用戶自定義save屬性，讓服務器每一段時間內執(zhí)行一次bgsave操作。

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

5、恢復數(shù)據機制

只需要將rdb文件放在我們redis啟動目錄就可以了，redis啟動的時候會自動檢查文件并恢復其中的數(shù)據。

6、優(yōu)點

• RDB是一個非常緊湊的文件，它保存了某個時間點得數(shù)據集，非常適用于數(shù)據集的備份，比如你可以在每個小時報保存一下過去24小時內的數(shù)據，同時每天保存過去30天的數(shù)據，這樣即使出了問題你也可以根據需求恢復到不同版本的數(shù)據集。

• RDB是一個緊湊的單一文件，很方便傳送到另一個遠端數(shù)據中心或者亞馬遜的S3（可能加密），非常適用于災難恢復。

• RDB在保存RDB文件時父進程唯一需要做的就是fork出一個子進程，接下來的工作全部由子進程來做，父進程不需要再做其他IO操作，所以RDB持久化方式可以最大化redis的性能。

• 與AOF相比，在恢復大的數(shù)據集的時候，RDB方式會更快一些。

7、缺點

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

• RDB 需要經常fork子進程來保存數(shù)據集到硬盤上，當數(shù)據集比較大的時候，fork的過程是非常耗時的，可能會導致Redis在一些毫秒級內不能響應客戶端的請求。如果數(shù)據集巨大并且CPU性能不是很好的情況下，這種情況會持續(xù)1秒，AOF也需要fork，但是你可以調節(jié)重寫日志文件的頻率來提高數(shù)據集的耐久度。

3、AOF

1、概念

以日志的形式來記錄每個寫操作，將Redis執(zhí)行過的所有指令記錄下來（讀操作不記錄），只許追加文件但不可以改寫文件，Redis啟動之初會讀取該文件重新構建數(shù)據，換言之，Redis重啟的話就會根據日志文件的內容將寫的指令從前到后執(zhí)行一次以完成數(shù)據的恢復工作。

2、持久化原理

所有操作的命令會追加在文件中。

3、開啟AOF持久化

# 開啟aof持久化方式，默認no
 appendonly no
 
# aof 持久化生成的文件名稱
appendfilename "appendonly.aof"
 
# 三種持久化機制
# appendfsync always
appendfsync everysec
# appendfsync no

4、三種觸發(fā)持久化機制

• always

同步持久化，每次發(fā)生數(shù)據變更會被立即持久化到硬盤中，性能比較差，但是數(shù)據完整性好。

• everysec

異步操作，每秒持久化數(shù)據到硬盤一次，可能會丟失一秒的數(shù)據。

• no

從不持久化到硬盤。

5、AOF文件損壞

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

5、優(yōu)點

• 根據配置不同的策略，讓你選擇持久化的方式。

• AOF文件是一個只進行追加的日志文件，所以不需要寫入seek，即使由于某些原因(磁盤空間已滿，寫的過程中宕機等等)未執(zhí)行完整的寫入命令，你也也可使用redis-check-aof工具修復這些問題。

• Redis 可以在 AOF 文件體積變得過大時，自動地在后臺對 AOF 進行重寫： 重寫后的新 AOF 文件包含了恢復當前數(shù)據集所需的最小命令集合。 整個重寫操作是絕對安全的，因為 Redis 在創(chuàng)建新 AOF 文件的過程中，會繼續(xù)將命令追加到現(xiàn)有的 AOF 文件里面，即使重寫過程中發(fā)生停機，現(xiàn)有的 AOF 文件也不會丟失。 而一旦新 AOF 文件創(chuàng)建完畢，Redis 就會從舊 AOF 文件切換到新 AOF 文件，并開始對新 AOF 文件進行追加操作。

• AOF 文件有序地保存了對數(shù)據庫執(zhí)行的所有寫入操作，這些寫入操作以 Redis 協(xié)議的格式保存， 因此 AOF 文件的內容非常容易被人讀懂，對文件進行分析（parse）也很輕松。導出（export）AOF文件也非常簡單：舉個例子， 如果你不小心執(zhí)行了 FLUSHALL 命令， 但只要 AOF 文件未被重寫，那么只要停止服務器，移除 AOF 文件末尾的 FLUSHALL 命令，并重啟 Redis，就可以將數(shù)據集恢復到 FLUSHALL 執(zhí)行之前的狀態(tài)。

6、缺點

• 對于相同的數(shù)據集來說，AOF 文件的體積通常要大于 RDB 文件的體積。

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

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