這篇文章主要介紹“怎么使用快照和AOF將Redis數(shù)據(jù)持久化到硬盤中”,在日常操作中,相信很多人在怎么使用快照和AOF將Redis數(shù)據(jù)持久化到硬盤中問題上存在疑惑,小編查閱了各式資料,整理出簡單好用的操作方法,希望對大家解答”怎么使用快照和AOF將Redis數(shù)據(jù)持久化到硬盤中”的疑惑有所幫助!接下來,請跟著小編一起來學(xué)習(xí)吧!
創(chuàng)新互聯(lián)長期為超過千家客戶提供的網(wǎng)站建設(shè)服務(wù),團(tuán)隊(duì)從業(yè)經(jīng)驗(yàn)10年,關(guān)注不同地域、不同群體,并針對不同對象提供差異化的產(chǎn)品和服務(wù);打造開放共贏平臺,與合作伙伴共同營造健康的互聯(lián)網(wǎng)生態(tài)環(huán)境。為來安企業(yè)提供專業(yè)的成都網(wǎng)站制作、網(wǎng)站設(shè)計(jì),來安網(wǎng)站改版等技術(shù)服務(wù)。擁有十多年豐富建站經(jīng)驗(yàn)和眾多成功案例,為您定制開發(fā)。我們知道Redis是一款內(nèi)存服務(wù)器,就算我們對自己的服務(wù)器足夠的信任,不會出現(xiàn)任何軟件或者硬件的故障,但也會有可能出現(xiàn)突然斷電等情況,造成Redis服務(wù)器中的數(shù)據(jù)失效。因此,我們需要向傳統(tǒng)的關(guān)系型數(shù)據(jù)庫一樣對數(shù)據(jù)進(jìn)行備份,將Redis在內(nèi)存中的數(shù)據(jù)持久化到硬盤等非易失性介質(zhì)中,來保證數(shù)據(jù)的可靠性。
將Redis內(nèi)存服務(wù)器中的數(shù)據(jù)持久化到硬盤等介質(zhì)中的一個(gè)好處就是,使得我們的服務(wù)器在重啟之后還可以重用以前的數(shù)據(jù),或者是為了防止系統(tǒng)出現(xiàn)故障而將數(shù)據(jù)備份到一個(gè)遠(yuǎn)程的位置。
還有一些場景,例如:
對于一些需要進(jìn)行大量計(jì)算而得到的數(shù)據(jù),放置在Redis服務(wù)器,我們就有必要對其進(jìn)行數(shù)據(jù)的持久化,如果需要對數(shù)據(jù)進(jìn)行恢復(fù)的時(shí)候,我們就不需進(jìn)行重新的計(jì)算,只需要簡單的將這臺機(jī)器上的數(shù)據(jù)復(fù)制到另一臺需要恢復(fù)的Redis服務(wù)器就可以了。
Redis給我們提供了兩種不同方式的持久化方法:快照(Snapshotting) 和 只追加文件(append-only-file)。
(1)名詞簡介
快照(RDB):就是我們俗稱的備份,他可以在定期內(nèi)對數(shù)據(jù)進(jìn)行備份,將Redis服務(wù)器中的數(shù)據(jù)持久化到硬盤中;
只追加文件(AOF):他會在執(zhí)行寫命令的時(shí)候,將執(zhí)行的寫命令復(fù)制到硬盤里面,后期恢復(fù)的時(shí)候,只需要重新執(zhí)行一下這個(gè)寫命令就可以了。類似于我們的MySQL數(shù)據(jù)庫在進(jìn)行主從復(fù)制的時(shí)候,使用的是binlog
二進(jìn)制文件,同樣的是執(zhí)行一遍寫命令;
(2)快照持久化通用的配置:
save 60 1000 #60秒時(shí)間內(nèi)有1000次寫入操作的時(shí)候執(zhí)行快照的創(chuàng)建stop-writes-on-bgsave-error no #創(chuàng)建快照失敗的時(shí)候是否仍然繼續(xù)執(zhí)行寫命令rdbcompression yes #是否對快照文件進(jìn)行壓縮dbfilename dump.rdb #如何命名硬盤上的快照文件dir ./ #快照所保存的位置
(3)AOP持久化配置:
appendonly no #是否使用AOF持久化appendfsync everysec #多久執(zhí)行一次將寫入內(nèi)容同步到硬盤上no-appendfsync-on-rewrite no #對AOF進(jìn)行壓縮的時(shí)候能否執(zhí)行同步操作auto-aof-rewrite-percentage 100 #多久執(zhí)行一次AOF壓縮auto-aof-rewrite-min-size 64mb #多久執(zhí)行一次AOF壓縮dir ./ #AOF所保存的位置
需要注意的是:這兩種持久化的方式既可以單獨(dú)的使用,也可以同時(shí)使用,具體選擇哪種方式需要根據(jù)具體的情況進(jìn)行選擇。
快照就是我們所說的備份。用戶可以將Redis內(nèi)存中的數(shù)據(jù)在某一個(gè)時(shí)間點(diǎn)進(jìn)行備份,在創(chuàng)建快照之后,用戶可以對快照進(jìn)行備份。通常情況下,為了防止單臺服務(wù)器出現(xiàn)故障造成所有數(shù)據(jù)的丟失,我們還可以將快照復(fù)制到其他服務(wù)器,創(chuàng)建具有相同數(shù)據(jù)的數(shù)據(jù)副本,這樣的話,數(shù)據(jù)恢復(fù)的時(shí)候或者服務(wù)器重啟的時(shí)候就可以使用這些快照信息進(jìn)行數(shù)據(jù)的恢復(fù),也可以防止單臺服務(wù)器出現(xiàn)故障的時(shí)候造成數(shù)據(jù)的丟失。
但是,沒我們還需要注意的是,創(chuàng)建快照的方式,并不能完全保證我們的數(shù)據(jù)不丟失,這個(gè)大家可以很好的理解,因?yàn)榭煺盏膭?chuàng)建時(shí)定時(shí)的,并不是每一次更新操作都會創(chuàng)建一個(gè)快照的。系統(tǒng)發(fā)生崩潰的時(shí)候,用戶將丟失最近一次生成快照之后更改的所有數(shù)據(jù)。因此,快照持久化的方式只適合于數(shù)據(jù)不經(jīng)常修改或者丟失部分?jǐn)?shù)據(jù)影響不大的場景。
一、創(chuàng)建快照的方式:
(1)客戶端通過向Redis發(fā)送BGSAVE
命令來創(chuàng)建快照。
使用BGSAVE的時(shí)候,Redis會調(diào)用fork來創(chuàng)建一個(gè)子進(jìn)程,然后子進(jìn)程負(fù)責(zé)將快照寫到硬盤中,而父進(jìn)程則繼續(xù)處理命令請求。
使用場景:
如果用戶使用了save設(shè)置,例如:save 60 1000
,那么從Redis最近一次創(chuàng)建快照之后開始計(jì)算,當(dāng)“60秒之內(nèi)有1000次寫入操作”這個(gè)條件滿足的時(shí)候,Redis就會自動(dòng)觸發(fā)BGSAVE命令。
如果用戶使用了多個(gè)save設(shè)置,那么當(dāng)任意一個(gè)save配置滿足條件的時(shí)候,Redis都會觸發(fā)一次BGSAVE命令。
(2)客戶端通過向Redis發(fā)送SAVE
命令來創(chuàng)建快照。
接收到SAVE命令的Redis服務(wù)器在快照創(chuàng)建完畢之前將不再響應(yīng)任何其他命令的請求。SAVE命令并不常用,我們通常只在沒有足夠的內(nèi)存去執(zhí)行BGSAVE命令的時(shí)候才會使用SAVE命令,或者即使等待持久化操作執(zhí)行完畢也無所謂的情況下,才會使用這個(gè)命令;
使用場景:
當(dāng)Redis通過SHUTDOWN命令接收到關(guān)閉服務(wù)器的請求時(shí),或者接收到標(biāo)準(zhǔn)的TERM信號時(shí),會執(zhí)行一次SAVE命令,阻塞所有的客戶端,不再執(zhí)行客戶端發(fā)送的任何命令,并且在執(zhí)行完SAVE命令之后關(guān)閉服務(wù)器。
二、使用快照持久化注意事項(xiàng):
我們在使用快照的方式來保存數(shù)據(jù)的時(shí)候,如果Redis服務(wù)器中的數(shù)據(jù)量比較小的話,例如只有幾個(gè)GB的時(shí)候。Redis會創(chuàng)建子進(jìn)程并將數(shù)據(jù)保存到硬盤里邊,生成快照所需的時(shí)間比讀取數(shù)據(jù)所需要的時(shí)間還要短。
但是,隨著數(shù)據(jù)的增大,Redis占用的內(nèi)存越來越大的時(shí)候,BGSAVE在創(chuàng)建子進(jìn)程的時(shí)候消耗的時(shí)間也會越來越多,如果Redis服務(wù)器所剩下的內(nèi)存不多的時(shí)候,這行BGSAVE命令會使得系統(tǒng)長時(shí)間地停頓,還有可能導(dǎo)致服務(wù)器無法使用。
各虛擬機(jī)類別,創(chuàng)建子線程所耗時(shí)間:
因此,為了防止Redis因?yàn)閯?chuàng)建子進(jìn)程的時(shí)候出現(xiàn)停頓,我們可以考慮關(guān)閉自動(dòng)保存,轉(zhuǎn)而通過手動(dòng)的方式發(fā)送BGSAVE或者SAVE來進(jìn)行持久化,
手動(dòng)的方式發(fā)送BGSAVE也會出現(xiàn)停頓的現(xiàn)象,但是我們可以控制發(fā)送該命令的時(shí)間來控制出現(xiàn)停頓的時(shí)候不影響具體的業(yè)務(wù)請求。
另外,值得注意的是,在使用SAVE命令的時(shí)候,雖然會一直阻塞Redis直到快照生成完畢,但是其不需要?jiǎng)?chuàng)建子進(jìn)程,所以不會向BGSAVE一樣,因?yàn)閯?chuàng)建子進(jìn)程而導(dǎo)致Redis停頓。也正因?yàn)槿绱耍琒AVE創(chuàng)建快照的速度要比BGSAVE創(chuàng)建快照的速度更快一些。
創(chuàng)建快照的時(shí)候,我們可以在業(yè)務(wù)請求,比較少的時(shí)候,比如凌晨三、四點(diǎn),通過手寫腳本的方式,定時(shí)執(zhí)行。
AOF持久化會將被執(zhí)行的寫命令寫到AOF文件的末尾,以此來記錄數(shù)據(jù)發(fā)生的變化。這樣,我們在恢復(fù)數(shù)據(jù)的時(shí)候,只需要從頭到尾的執(zhí)行一下AOF文件即可恢復(fù)數(shù)據(jù)。
一、打開AOF持久化選項(xiàng)
我們可以通過使用如下命令打開AOF:
appendonly yes
我們,通過如下命令來配置AOF文件的同步頻率:
appendfsync everysec/always/no
二、appendfsync同步頻率的區(qū)別
appendfsync同步頻率的區(qū)別如下圖:
(1)always的方式固然可以對沒一條數(shù)據(jù)進(jìn)行很好的保存,但是這種同步策略需要對硬盤進(jìn)行大量的寫操作,所以Redis處理命令的速度會受到硬盤性能的限制。
普通的硬盤每秒鐘只能處理大約200個(gè)寫命令,使用固態(tài)硬盤SSD每秒可以處理幾萬個(gè)寫命令,但是每次只寫一個(gè)命令,這種只能怪不斷地寫入很少量的數(shù)據(jù)的做法有可能引發(fā)嚴(yán)重的寫入放大問題,這種情況下降嚴(yán)重影響固態(tài)硬盤的使用壽命。
(2)everysec的方式,Redis以每秒一次的頻率大隊(duì)AOF文件進(jìn)行同步。這樣的話既可以兼顧數(shù)據(jù)安全也可以兼顧寫入性能。
Redis以每秒同步一次AOF文件的性能和不使用任何持久化特性時(shí)的性能相差無幾,使用每秒更新一次 的方式,可以保證,即使出現(xiàn)故障,丟失的數(shù)據(jù)也在一秒之內(nèi)產(chǎn)生的數(shù)據(jù)。
(3)no的方式,Redis將不對AOF文件執(zhí)行任何顯示的同步操作,而是由操作系統(tǒng)來決定應(yīng)該何時(shí)對AOF文件進(jìn)行同步。
這個(gè)命令一般不會對Redis的性能造成多大的影響,但是當(dāng)系統(tǒng)出現(xiàn)故障的時(shí)候使用這種選項(xiàng)的Redis服務(wù)器丟失不定數(shù)量的數(shù)據(jù)。
另外,當(dāng)用戶的硬盤處理寫入操作的速度不夠快的話,那么緩沖區(qū)被等待寫入硬盤的數(shù)據(jù)填滿時(shí),Redis的寫入操作將被阻塞,并導(dǎo)致Redis處理命令請求的速度變慢,因?yàn)檫@個(gè)原因,一般不推薦使用這個(gè)選項(xiàng)。
三、重寫/壓縮AOF文件
隨著數(shù)據(jù)量的增大,AOF的文件可能會很大,這樣在每次進(jìn)行數(shù)據(jù)恢復(fù)的時(shí)候就會進(jìn)行很長的時(shí)間,為了解決日益增大的AOF文件,用戶可以向Redis發(fā)送BGREWRITEAOF
命令,這個(gè)命令會通過移除AOF文件中的冗余命令來重寫AOF文件,是AOF文件的體檢變得盡可能的小。
BGREWRITEAOF的工作原理和BGSAVE的原理很像:Redis會創(chuàng)建一個(gè)子進(jìn)程,然后由子進(jìn)程負(fù)責(zé)對AOF文件的重寫操作。
因?yàn)锳OF文件重寫的時(shí)候匯創(chuàng)建子進(jìn)程,所以快照持久化因?yàn)閯?chuàng)建子進(jìn)程而導(dǎo)致的性能和內(nèi)存占用問題同樣會出現(xiàn)在AOF文件重寫的 時(shí)候。
四、觸發(fā)重寫/壓縮AOF文件條件設(shè)定
AOF通過設(shè)置auto-aof-rewrite-percentage
和
auto-aof-rewrite-min-size
選項(xiàng)來自動(dòng)執(zhí)行BGREWRITEAOF。
其具體含義,通過實(shí)例可以看出,如下配置:
auto-aof-rewrite-percentage 100 auto-aof-rewrite-min-size 64mb
表示當(dāng)前AOF的文件體積大于64MB,并且AOF文件的體積比上一次重寫之后的體積變大了至少一倍(100%)的時(shí)候,Redis將執(zhí)行重寫B(tài)GREWRITEAOF命令。
如果AOF重寫執(zhí)行的過于頻繁的話,可以將auto-aof-rewrite-percentage
選項(xiàng)的值設(shè)置為100以上,這種最偶發(fā)就可以讓Redis在AOF文件的體積變得更大之后才執(zhí)行重寫操作,不過,這也使得在進(jìn)行數(shù)據(jù)恢復(fù)的時(shí)候執(zhí)行的時(shí)間變得更加長一些。
無論使用哪種方式進(jìn)行持久化,我們在進(jìn)行恢復(fù)數(shù)據(jù)的時(shí)候,Redis提供了兩個(gè)命令行程序:
redis-check-aofredis-check-dump
他們可以再系統(tǒng)發(fā)生故障的時(shí)候,檢查快照和AOF文件的狀態(tài),并對有需要的情況對文件進(jìn)行修復(fù)。
如果用戶在運(yùn)行redis-check-aof命令的時(shí)候,指定了--fix
參數(shù),那么程序?qū)OF文件進(jìn)行修復(fù)。
程序修復(fù)AOF文件的方法很簡單:他會掃描給定的AOF文件,尋找不正確或者不完整的命令,當(dāng)發(fā)現(xiàn)第一個(gè)出現(xiàn)錯(cuò)誤命令的時(shí)候,程序會刪除出錯(cuò)命令以及出錯(cuò)命令之后的所有命令,只保留那些位于出錯(cuò)命令之前的正確命令。大部分情況,被刪除的都是AOF文件末尾的不完整的寫命令。
到此,關(guān)于“怎么使用快照和AOF將Redis數(shù)據(jù)持久化到硬盤中”的學(xué)習(xí)就結(jié)束了,希望能夠解決大家的疑惑。理論與實(shí)踐的搭配能更好的幫助大家學(xué)習(xí),快去試試吧!若想繼續(xù)學(xué)習(xí)更多相關(guān)知識,請繼續(xù)關(guān)注創(chuàng)新互聯(lián)-成都網(wǎng)站建設(shè)公司網(wǎng)站,小編會繼續(xù)努力為大家?guī)砀鄬?shí)用的文章!
文章名稱:怎么使用快照和AOF將Redis數(shù)據(jù)持久化到硬盤中-創(chuàng)新互聯(lián)
網(wǎng)站地址:http://www.rwnh.cn/article16/cedigg.html
成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián),為您提供企業(yè)網(wǎng)站制作、網(wǎng)站改版、ChatGPT、網(wǎng)站營銷、網(wǎng)站收錄、服務(wù)器托管
聲明:本網(wǎng)站發(fā)布的內(nèi)容(圖片、視頻和文字)以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主,如果涉及侵權(quán)請盡快告知,我們將會在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場,如需處理請聯(lián)系客服。電話:028-86922220;郵箱:631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載,或轉(zhuǎn)載時(shí)需注明來源: 創(chuàng)新互聯(lián)
猜你還喜歡下面的內(nèi)容