本篇內(nèi)容主要講解“redis持久化的方法是什么”,感興趣的朋友不妨來看看。本文介紹的方法操作簡(jiǎn)單快捷,實(shí)用性強(qiáng)。下面就讓小編來帶大家學(xué)習(xí)“Redis持久化的方法是什么”吧!
創(chuàng)新互聯(lián)致力于互聯(lián)網(wǎng)品牌建設(shè)與網(wǎng)絡(luò)營(yíng)銷,包括網(wǎng)站設(shè)計(jì)制作、做網(wǎng)站、SEO優(yōu)化、網(wǎng)絡(luò)推廣、整站優(yōu)化營(yíng)銷策劃推廣、電子商務(wù)、移動(dòng)互聯(lián)網(wǎng)營(yíng)銷等。創(chuàng)新互聯(lián)為不同類型的客戶提供良好的互聯(lián)網(wǎng)應(yīng)用定制及解決方案,創(chuàng)新互聯(lián)核心團(tuán)隊(duì)十多年專注互聯(lián)網(wǎng)開發(fā),積累了豐富的網(wǎng)站經(jīng)驗(yàn),為廣大企業(yè)客戶提供一站式企業(yè)網(wǎng)站建設(shè)服務(wù),在網(wǎng)站建設(shè)行業(yè)內(nèi)樹立了良好口碑。
RDB持久化Redis支持RDB與AOF兩種持久化機(jī)制,持久化可以避免因進(jìn)程異常退出或down機(jī)導(dǎo)致的數(shù)據(jù)丟失問題,在下次重啟時(shí)能利用之前的持久化文件實(shí)現(xiàn)數(shù)據(jù)恢復(fù)。
RDB持久化即通過創(chuàng)建快照(壓縮的二進(jìn)制文件)的方式進(jìn)行持久化,保存某個(gè)時(shí)間點(diǎn)的全量數(shù)據(jù)。RDB持久化是Redis默認(rèn)的持久化方式。RDB持久化的觸發(fā)包括手動(dòng)觸發(fā)與自動(dòng)觸發(fā)兩種方式。
手動(dòng)觸發(fā)
save, 在
命令行執(zhí)行save
命令,將以同步的方式創(chuàng)建rdb文件保存快照,會(huì)阻塞服務(wù)器的主進(jìn)程,生產(chǎn)環(huán)境中不要用
bgsave, 在命令行執(zhí)行bgsave命令,將通過fork一個(gè)子進(jìn)程以異步的方式創(chuàng)建rdb文件保存快照,除了fork時(shí)有阻塞,子進(jìn)程在創(chuàng)建rdb文件時(shí),主進(jìn)程可繼續(xù)處理請(qǐng)求
自動(dòng)觸發(fā)
在redis.conf中配置 save m n 定時(shí)觸發(fā),如 save 900 1表示在900s內(nèi)至少存在一次更新就觸發(fā)
主從復(fù)制時(shí),如果從節(jié)點(diǎn)執(zhí)行全量復(fù)制操作,主節(jié)點(diǎn)自動(dòng)執(zhí)行bgsave生成RDB文件并發(fā)送給從節(jié)點(diǎn)
執(zhí)行debug reload命令重新加載Redis時(shí)
執(zhí)行shutdown且沒有開啟AOF持久化
redis.conf中RDB持久化配置
# 只要滿足下列條件之一,則會(huì)執(zhí)行bgsave命令 save 900 1 # 在900s內(nèi)存在至少一次寫操作 save 300 10 save 60 10000 # 禁用RBD持久化,可在最后加 save "" # 當(dāng)備份進(jìn)程出錯(cuò)時(shí)主進(jìn)程是否停止寫入操作 stop-writes-on-bgsave-error yes # 是否壓縮rdb文件 推薦no 相對(duì)于硬盤成本cpu資源更貴 rdbcompression no
AOF持久化
AOF(Append-Only-File)持久化即記錄所有變更數(shù)據(jù)庫狀態(tài)的指令,以append的形式追加保存到AOF文件中。在服務(wù)器下次啟動(dòng)時(shí),就可以通過載入和執(zhí)行AOF文件中保存的命令,來還原服務(wù)器關(guān)閉前的數(shù)據(jù)庫狀態(tài)。
redis.conf中AOF持久化配置如下
# 默認(rèn)關(guān)閉AOF,若要開啟將no改為yes appendonly no # append文件的名字 appendfilename "appendonly.aof" # 每隔一秒將緩存區(qū)內(nèi)容寫入文件 默認(rèn)開啟的寫入方式 appendfsync everysec # 當(dāng)AOF文件大小的增長(zhǎng)率大于該配置項(xiàng)時(shí)自動(dòng)開啟重寫(這里指超過原大小的100%)。 auto-aof-rewrite-percentage 100 # 當(dāng)AOF文件大小大于該配置項(xiàng)時(shí)自動(dòng)開啟重寫 auto-aof-rewrite-min-size 64mb
AOF持久化的實(shí)現(xiàn)包括3個(gè)步驟:
命令追加:將命令追加到AOF緩沖區(qū)
文件寫入:緩沖區(qū)內(nèi)容寫到AOF文件
文件保存:AOF文件保存到磁盤
其中后兩步的頻率通過appendfsync來配置,appendfsync的選項(xiàng)包括
always, 每執(zhí)行一個(gè)命令就保存一次,安全性最高,最多只丟失一個(gè)命令的數(shù)據(jù),但是性能也最低(頻繁的磁盤IO)
everysec,每一秒保存一次,推薦使用,在安全性與性能之間折中,最多丟失一秒的數(shù)據(jù)
no, 依賴操作系統(tǒng)來執(zhí)行(一般大概30s一次的樣子),安全性最低,性能最高,丟失操作系統(tǒng)最后一次對(duì)AOF文件觸發(fā)SAVE操作之后的數(shù)據(jù)
AOF通過保存命令來持久化,隨著時(shí)間的推移,AOF文件會(huì)越來越大,Redis通過AOF文件重寫來解決AOF文件不斷增大的問題(可以減少文件的磁盤占有量,加快數(shù)據(jù)恢復(fù)的速度),原理如下:
調(diào)用fork,創(chuàng)建一個(gè)子進(jìn)程
子進(jìn)程讀取當(dāng)前數(shù)據(jù)庫的狀態(tài)來“重寫”一個(gè)新的AOF文件(這里雖然叫“重寫”,但實(shí)際并沒有對(duì)舊文件進(jìn)行任何讀取,而是根據(jù)數(shù)據(jù)庫的當(dāng)前狀態(tài)來形成指令)
主進(jìn)程持續(xù)將新的變動(dòng)同時(shí)寫到AOF重寫緩沖區(qū)與原來的AOF緩沖區(qū)中
主進(jìn)程獲取到子進(jìn)程重寫AOF完成的信號(hào),調(diào)用信號(hào)處理函數(shù)將AOF重寫緩沖區(qū)內(nèi)容寫入新的AOF文件中,并對(duì)新文件進(jìn)行重命名,原子地覆蓋原有AOF文件,完成新舊文件的替換
AOF的重寫也分為手動(dòng)觸發(fā)與自動(dòng)觸發(fā)
手動(dòng)觸發(fā): 直接調(diào)用bgrewriteaof命令 自動(dòng)觸發(fā): 根據(jù)auto-aof-rewrite-min-size和auto-aof-rewrite-percentage參數(shù)確定自動(dòng)觸發(fā)時(shí)機(jī)。其中auto-aof-rewrite-min-size表示運(yùn)行AOF重寫時(shí)文件最小體積,默認(rèn)為64MB。auto-aof-rewrite-percentage表示當(dāng)前AOF文件大?。╝of_current_size)和上一次重寫后AOF文件大?。╝of_base_size)的比值。自動(dòng)觸發(fā)時(shí)機(jī)為 aof_current_size > auto-aof-rewrite-min-size &&(aof_current_size - aof_base_size)/aof_base_size> = auto-aof-rewrite-percentage
RDB vs AOF
RDB與AOF兩種方式各有優(yōu)缺點(diǎn)。
RDB的優(yōu)點(diǎn):與AOF相比,RDB文件相對(duì)較小,恢復(fù)數(shù)據(jù)比較快(原因見數(shù)據(jù)恢復(fù)部分)
RDB的缺點(diǎn):服務(wù)器宕機(jī),RBD方式會(huì)丟失掉上一次RDB持久化后的數(shù)據(jù);使用bgsave fork子進(jìn)程時(shí)會(huì)耗費(fèi)內(nèi)存。
AOF的優(yōu)點(diǎn): AOF只是追加文件,對(duì)服務(wù)器性能影響較小,速度比RDB快,消耗內(nèi)存也少,同時(shí)可讀性高。
AOF的缺點(diǎn):生成的文件相對(duì)較大,即使通過AOF重寫,仍然會(huì)比較大;恢復(fù)數(shù)據(jù)的速度比RDB慢。
數(shù)據(jù)庫的恢復(fù)
服務(wù)器啟動(dòng)時(shí),如果沒有開啟AOF持久化功能,則會(huì)自動(dòng)載入RDB文件,期間會(huì)阻塞主進(jìn)程。如果開啟了AOF持久化功能,服務(wù)器則會(huì)優(yōu)先使用AOF文件來還原數(shù)據(jù)庫狀態(tài),因?yàn)锳OF文件的更新頻率通常比RDB文件的更新頻率高,保存的數(shù)據(jù)更完整。
redis數(shù)據(jù)庫恢復(fù)的處理流程如下,
在數(shù)據(jù)恢復(fù)方面,RDB的啟動(dòng)時(shí)間會(huì)更短,原因有兩個(gè):
RDB 文件中每一條數(shù)據(jù)只有一條記錄,不會(huì)像AOF日志那樣可能有一條數(shù)據(jù)的多次操作記錄。所以每條數(shù)據(jù)只需要寫一次就行了,文件相對(duì)較小。
RDB 文件的存儲(chǔ)格式和Redis數(shù)據(jù)在內(nèi)存中的編碼格式是一致的,不需要再進(jìn)行數(shù)據(jù)編碼工作,所以在CPU消耗上要遠(yuǎn)小于AOF日志的加載。
但是在進(jìn)行RDB持久化時(shí),fork出來進(jìn)行dump操作的子進(jìn)程會(huì)占用與父進(jìn)程一樣的內(nèi)存,采用的copy-on-write機(jī)制,對(duì)性能的影響和內(nèi)存的消耗都是比較大的。比如16G內(nèi)存,Redis已經(jīng)使用了10G,這時(shí)save的話會(huì)再生成10G,變成20G,大于系統(tǒng)的16G。這時(shí)候會(huì)發(fā)生交換,要是虛擬內(nèi)存不夠則會(huì)崩潰,導(dǎo)致數(shù)據(jù)丟失。所以在用redis的時(shí)候一定對(duì)系統(tǒng)內(nèi)存做好容量規(guī)劃。
RDB、AOF混合持久化
Redis從4.0版開始支持RDB與AOF的混合持久化方案。首先由RDB定期完成內(nèi)存快照的備份,然后再由AOF完成兩次RDB之間的數(shù)據(jù)備份,由這兩部分共同構(gòu)成持久化文件。該方案的優(yōu)點(diǎn)是充分利用了RDB加載快、備份文件小及AOF盡可能不丟數(shù)據(jù)的特性。缺點(diǎn)是兼容性差,一旦開啟了混合持久化,在4.0之前的版本都不識(shí)別該持久化文件,同時(shí)由于前部分是RDB格式,閱讀性較低。
開啟混合持久化
aof-use-rdb-preamble yes
數(shù)據(jù)恢復(fù)加載過程就是先按照RDB進(jìn)行加載,然后把AOF命令追加寫入。
持久化方案的建議
如果Redis只是用來做緩存服務(wù)器,比如數(shù)據(jù)庫查詢數(shù)據(jù)后緩存,那可以不用考慮持久化,因?yàn)榫彺娣?wù)失效還能再?gòu)臄?shù)據(jù)庫獲取恢復(fù)。
如果你要想提供很高的數(shù)據(jù)保障性,那么建議你同時(shí)使用兩種持久化方式。如果你可以接受災(zāi)難帶來的幾分鐘的數(shù)據(jù)丟失,那么可以僅使用RDB。
通常的設(shè)計(jì)思路是利用主從復(fù)制機(jī)制來彌補(bǔ)持久化時(shí)性能上的影響。即Master上RDB、AOF都不做,保證Master的讀寫性能,而Slave上則同時(shí)開啟RDB和AOF(或4.0以上版本的混合持久化方式)來進(jìn)行持久化,保證數(shù)據(jù)的安全性。
到此,相信大家對(duì)“Redis持久化的方法是什么”有了更深的了解,不妨來實(shí)際操作一番吧!這里是創(chuàng)新互聯(lián)網(wǎng)站,更多相關(guān)內(nèi)容可以進(jìn)入相關(guān)頻道進(jìn)行查詢,關(guān)注我們,繼續(xù)學(xué)習(xí)!
文章名稱:Redis持久化的方法是什么
文章源于:http://chinadenli.net/article16/gdoigg.html
成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián),為您提供品牌網(wǎng)站設(shè)計(jì)、、建站公司、做網(wǎng)站、網(wǎng)站導(dǎo)航、外貿(mào)建站
聲明:本網(wǎng)站發(fā)布的內(nèi)容(圖片、視頻和文字)以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主,如果涉及侵權(quán)請(qǐng)盡快告知,我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng),如需處理請(qǐng)聯(lián)系客服。電話:028-86922220;郵箱:631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載,或轉(zhuǎn)載時(shí)需注明來源: 創(chuàng)新互聯(lián)