Redis持久化深入詳解

1、概述

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

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

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

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

4.你也可以同時(shí)開啟兩種持久化方式，在這種情況下，當(dāng)redis重啟的時(shí)候會(huì)優(yōu)先載入AOF文件來恢復(fù)原始的數(shù)據(jù)。因?yàn)樵谕ǔＧ闆r下AOF文件保存的數(shù)據(jù)集要比RDB文件保存的數(shù)據(jù)集要完整。

2、RDB

1、概念

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

2、持久化機(jī)制-BGSAVE

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

3、持久化機(jī)制-SAVE

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

4、持久化機(jī)制-自動(dòng)觸發(fā)

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

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

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

只需要將rdb文件放在我們r(jià)edis啟動(dòng)目錄就可以了，redis啟動(dòng)的時(shí)候會(huì)自動(dòng)檢查文件并恢復(fù)其中的數(shù)據(jù)。

6、優(yōu)點(diǎn)

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

7、缺點(diǎn)

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

3、AOF

1、概念

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

2、持久化原理

所有操作的命令會(huì)追加在文件中。

3、開啟AOF持久化

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

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

• always

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

• everysec

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

• no

從不持久化到硬盤。

5、AOF文件損壞

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

5、優(yōu)點(diǎn)

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

6、缺點(diǎn)

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

4、如何選擇持久化機(jī)制

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

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