目錄
- 概述
- RDB
- AOF
- 如何選擇持久化機(jī)制
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文件后臺(tái)重寫,使得AOF文件的體積不至于過大。
3.如果你只希望你的數(shù)據(jù)在服務(wù)器運(yùn)行的時(shí)候存在,你也可以不使用任何持久化的方式。
4.你也可以同時(shí)開啟兩種持久化方式,在這種情況下,當(dāng)redis重啟的時(shí)候會(huì)優(yōu)先載入AOF文件來恢復(fù)原始的數(shù)據(jù)。因?yàn)樵谕ǔG闆r下AOF文件保存的數(shù)據(jù)集要比RDB文件保存的數(shù)據(jù)集要完整。
2、RDB
1、概念
在指定的時(shí)間間隔內(nèi)將內(nèi)存中的數(shù)據(jù)集快照寫入磁盤中,它恢復(fù)的時(shí)候是將快照中的文件直接讀取到內(nèi)存中。
2、持久化機(jī)制-BGSAVE
image
通常,會(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)在后臺(tái)執(zhí)行保存或者正在運(yùn)行另一個(gè)非后臺(tái)保存的進(jìn)程,特別是正在進(jìn)行AOF
寫入時(shí),則會(huì)返回錯(cuò)誤。如果使用了bgsave
任務(wù),而正在進(jìn)行AOF
寫入時(shí),該命令將立即返回ok,并計(jì)劃在下一次機(jī)會(huì)運(yùn)行后臺(tái)保存。阻塞只會(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)地在后臺(tái)對 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)整。