Redis數(shù)據(jù)持久化

redis數(shù)據(jù)持久化

Redis提供了將數(shù)據(jù)定期自動(dòng)持久化到硬盤的能力,包括RDB,AOF兩種方案,兩種方案各有利弊,可以配合起來同時(shí)使用,確保數(shù)據(jù)的穩(wěn)定性。

創(chuàng)新互聯(lián)建站主要從事成都網(wǎng)站制作、網(wǎng)站建設(shè)、網(wǎng)頁設(shè)計(jì)、企業(yè)做網(wǎng)站、公司建網(wǎng)站等業(yè)務(wù)。立足成都服務(wù)江華,10余年網(wǎng)站建設(shè)經(jīng)驗(yàn),價(jià)格優(yōu)惠、服務(wù)專業(yè),歡迎來電咨詢建站服務(wù):028-86922220

必須使用數(shù)據(jù)持久化嗎?

Redis數(shù)據(jù)持久化機(jī)制是可以關(guān)閉的。如果把 Redis服務(wù)作為緩存服務(wù)使用,Redis中存儲(chǔ)的所有數(shù)據(jù)都不是該數(shù)據(jù)的主體而僅僅是同步過來的備份,則可以關(guān)閉Redis的數(shù)據(jù)持久化機(jī)制。

但通常,仍要建議至少開啟 RDB方式的數(shù)據(jù)持久化,因?yàn)椋?/p>

  • RDB方式的持久化幾乎不損耗 Redis本身的性能,在進(jìn)行 RDB持久化時(shí),Redis 主進(jìn)程唯一需要做的事情就是 fork出一個(gè)子進(jìn)程,所有持久化工作都由子進(jìn)程完成。

  • Redis無論因?yàn)槭裁丛騝rash掉之后,重啟時(shí)能夠自動(dòng)恢復(fù)到上一次RDB快照中記錄的數(shù)據(jù)。這省去了手工從其他數(shù)據(jù)源(如DB)同步數(shù)據(jù)的過程,而且要比其他任何的數(shù)據(jù)恢復(fù)方式都要快。

  • 現(xiàn)在硬盤那么大,真的不缺那一點(diǎn)地方

RDB

采用RDB持久方式,Redis會(huì)定期保存數(shù)據(jù)快照至一個(gè) rbd 文件中,并在啟動(dòng)時(shí)自動(dòng)加載rdb文件,恢復(fù)之前保存的數(shù)據(jù)??梢栽谂渲梦募信渲?Redis 進(jìn)行快照保存的時(shí)機(jī):

save?[seconds]?[changes]

? ?意為在[seconds]秒內(nèi)如果發(fā)生了[changes]次數(shù)據(jù)修改,則進(jìn)行一次RDB快照保存,例如

save?60?100

會(huì)讓Redis每60秒檢查一次數(shù)據(jù)變更情況,如果發(fā)生了100次或以上的數(shù)據(jù)變更,則進(jìn)行RDB快照保存。
可以配置多條save指令,讓Redis執(zhí)行多級的快照保存策略。
Redis默認(rèn)開啟RDB快照,默認(rèn)的RDB策略如下:

save?900?1
save?300?10
save?60?10000

也可以通過BGSAVE命令手工觸發(fā)RDB快照保存。

RDB的優(yōu)點(diǎn):

  • 對性能影響最小。如前文所述,Redis在保存RDB快照時(shí)會(huì)fork出子進(jìn)程進(jìn)行,幾乎不影響Redis處理客戶端請求的效率。

  • 每次快照會(huì)生成一個(gè)完整的數(shù)據(jù)快照文件,所以可以輔以其他手段保存多個(gè)時(shí)間點(diǎn)的快照(例如把每天0點(diǎn)的快照備份至其他存儲(chǔ)媒介中),作為非??煽康臑?zāi)難恢復(fù)手段。

  • 使用RDB文件進(jìn)行數(shù)據(jù)恢復(fù)比使用AOF要快很多。

RDB的缺點(diǎn):

  • 快照是定期生成的,所以在Redis crash時(shí)或多或少會(huì)丟失一部分?jǐn)?shù)據(jù)。

  • 如果數(shù)據(jù)集非常大且CPU不夠強(qiáng)(比如單核CPU),Redis在fork子進(jìn)程時(shí)可能會(huì)消耗相對較長的時(shí)間(長至1秒),影響這期間的客戶端請求。

AOF

采用AOF持久方式時(shí),Redis會(huì)把每一個(gè)寫請求都記錄在一個(gè)日志文件里。在Redis重啟時(shí),會(huì)把AOF文件中記錄的所有寫操作順序執(zhí)行一遍,確保數(shù)據(jù)恢復(fù)到最新。

AOF默認(rèn)是關(guān)閉的,如要開啟,進(jìn)行如下配置:

appendonly?yes

AOF提供了三種fsync配置,always/everysec/no,通過配置項(xiàng)[appendfsync]指定:

  • appendfsync no:不進(jìn)行fsync,將flush文件的時(shí)機(jī)交給OS決定,速度最快

  • appendfsync always:每寫入一條日志就進(jìn)行一次fsync操作,數(shù)據(jù)安全性最高,但速度最慢

  • appendfsync everysec:折中的做法,交由后臺(tái)線程每秒fsync一次

隨著AOF不斷地記錄寫操作日志,必定會(huì)出現(xiàn)一些無用的日志,例如某個(gè)時(shí)間點(diǎn)執(zhí)行了命令SET key1 "abc",在之后某個(gè)時(shí)間點(diǎn)又執(zhí)行了SET key1 "bcd",那么第一條命令很顯然是沒有用的。大量的無用日志會(huì)讓AOF文件過大,也會(huì)讓數(shù)據(jù)恢復(fù)的時(shí)間過長。
所以Redis提供了AOF rewrite功能,可以重寫AOF文件,只保留能夠把數(shù)據(jù)恢復(fù)到最新狀態(tài)的最小寫操作集。
AOF rewrite可以通過BGREWRITEAOF命令觸發(fā),也可以配置Redis定期自動(dòng)進(jìn)行:

auto-aof-rewrite-percentage?100
auto-aof-rewrite-min-size?64mb

上面兩行配置的含義是,Redis在每次AOF rewrite時(shí),會(huì)記錄完成rewrite后的AOF日志大小,當(dāng)AOF日志大小在該基礎(chǔ)上增長了100%后,自動(dòng)進(jìn)行AOF rewrite。同時(shí)如果增長的大小沒有達(dá)到64mb,則不會(huì)進(jìn)行rewrite。

AOF的優(yōu)點(diǎn)

  • 最安全,在啟用appendfsync always時(shí),任何已寫入的數(shù)據(jù)都不會(huì)丟失,使用在啟用appendfsync everysec也至多只會(huì)丟失1秒的數(shù)據(jù)。

  • AOF文件在發(fā)生斷電等問題時(shí)也不會(huì)損壞,即使出現(xiàn)了某條日志只寫入了一半的情況,也可以使用redis-check-aof工具輕松修復(fù)。

  • AOF文件易讀,可修改,在進(jìn)行了某些錯(cuò)誤的數(shù)據(jù)清除操作后,只要AOF文件沒有rewrite,就可以把AOF文件備份出來,把錯(cuò)誤的命令刪除,然后恢復(fù)數(shù)據(jù)。

AOF的缺點(diǎn):

  • AOF文件通常比RDB文件更大

  • 性能消耗比RDB高

  • 數(shù)據(jù)恢復(fù)速度比RDB慢

網(wǎng)站名稱:Redis數(shù)據(jù)持久化
文章出自:http://muchs.cn/article44/gjghee.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián),為您提供靜態(tài)網(wǎng)站、Google、標(biāo)簽優(yōu)化、小程序開發(fā)、全網(wǎng)營銷推廣、網(wǎng)站內(nèi)鏈

廣告

聲明:本網(wǎng)站發(fā)布的內(nèi)容(圖片、視頻和文字)以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主,如果涉及侵權(quán)請盡快告知,我們將會(huì)在第一時(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)

網(wǎng)站托管運(yùn)營