1、概述

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

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

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

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

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

2、RDB

1、概念

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

2、持久化機制-BGSAVE

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

3、持久化機制-SAVE

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

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

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

# 服務器在900秒內，對數(shù)據(jù)庫進行了至少1次修改
save 900 1
 
# 服務器在300秒內，對數(shù)據(jù)庫進行了至少10次修改
save 300 10
 
# 服務器在60秒內，對數(shù)據(jù)庫進行了至少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ù)據(jù)機制

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

6、優(yōu)點

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

7、缺點

• 如果你希望在redis意外停止工作（例如電源中斷）的情況下丟失的數(shù)據(jù)最少的話，那么RDB不適合你。雖然你可以配置不同的save時間點(例如每隔5分鐘并且對數(shù)據(jù)集有100個寫的操作)，是Redis要完整的保存整個數(shù)據(jù)集是一個比較繁重的工作，你通常會每隔5分鐘或者更久做一次完整的保存，萬一在Redis意外宕機，你可能會丟失幾分鐘的數(shù)據(jù)。
• RDB 需要經常fork子進程來保存數(shù)據(jù)集到硬盤上，當數(shù)據(jù)集比較大的時候，fork的過程是非常耗時的，可能會導致Redis在一些毫秒級內不能響應客戶端的請求。如果數(shù)據(jù)集巨大并且CPU性能不是很好的情況下，這種情況會持續(xù)1秒，AOF也需要fork，但是你可以調節(jié)重寫日志文件的頻率來提高數(shù)據(jù)集的耐久度。

3、AOF

1、概念

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

2、持久化原理

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

3、開啟AOF持久化

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

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

• always

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

• everysec

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

• no

從不持久化到硬盤。

5、AOF文件損壞

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

5、優(yōu)點

• 根據(jù)配置不同的策略，讓你選擇持久化的方式。
• AOF文件是一個只進行追加的日志文件，所以不需要寫入seek，即使由于某些原因(磁盤空間已滿，寫的過程中宕機等等)未執(zhí)行完整的寫入命令，你也也可使用redis-check-aof工具修復這些問題。
• Redis 可以在 AOF 文件體積變得過大時，自動地在后臺對 AOF 進行重寫： 重寫后的新 AOF 文件包含了恢復當前數(shù)據(jù)集所需的最小命令集合。 整個重寫操作是絕對安全的，因為 Redis 在創(chuàng)建新 AOF 文件的過程中，會繼續(xù)將命令追加到現(xiàn)有的 AOF 文件里面，即使重寫過程中發(fā)生停機，現(xiàn)有的 AOF 文件也不會丟失。 而一旦新 AOF 文件創(chuàng)建完畢，Redis 就會從舊 AOF 文件切換到新 AOF 文件，并開始對新 AOF 文件進行追加操作。
• AOF 文件有序地保存了對數(shù)據(jù)庫執(zhí)行的所有寫入操作，這些寫入操作以 Redis 協(xié)議的格式保存， 因此 AOF 文件的內容非常容易被人讀懂，對文件進行分析（parse）也很輕松。導出（export）AOF文件也非常簡單：舉個例子， 如果你不小心執(zhí)行了 FLUSHALL 命令， 但只要 AOF 文件未被重寫，那么只要停止服務器，移除 AOF 文件末尾的 FLUSHALL 命令，并重啟 Redis，就可以將數(shù)據(jù)集恢復到 FLUSHALL 執(zhí)行之前的狀態(tài)。

6、缺點

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

4、如何選擇持久化機制

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

到此這篇關于Redis持久化深入詳解的文章就介紹到這了,更多相關Redis持久化內容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關文章希望大家以后多多支持腳本之家！