redis持久化方案

redis持久化方案

前言

redis提供兩種持久化方案:

  • RDB持久化(原理是將Reids在內(nèi)存中的數(shù)據(jù)庫(kù)記錄定時(shí)dump到磁盤上的RDB持久化)
  • AOF持久化(原理是將Reids的操作日志以追加的方式寫入文件)

這兩種持久化方式有什么區(qū)別,如何選擇呢?

RDB方式

RDB方式是指在指定的時(shí)間間隔內(nèi)將內(nèi)存中的數(shù)據(jù)集快照寫入磁盤,實(shí)際的操作過(guò)程是fork一個(gè)子進(jìn)程,先將數(shù)據(jù)集寫入臨時(shí)文件,寫入成功后,再替換之前的文件,用二進(jìn)制壓縮存儲(chǔ)(binlog)。

RDB方式
優(yōu)點(diǎn)
  1. 文件備份非常簡(jiǎn)便。如果采用該方式,那么整個(gè)Redis數(shù)據(jù)庫(kù)將只包含一個(gè)數(shù)據(jù)文件,非常便于復(fù)制和備份,并且非常容易管理。比如,可以設(shè)置每小時(shí)備份過(guò)去24小時(shí)的數(shù)據(jù),同時(shí)可以每天備份過(guò)去一個(gè)月的數(shù)據(jù)。使用類似的備份策略,我們可以非常容易的在災(zāi)難發(fā)生時(shí)進(jìn)行數(shù)據(jù)恢復(fù)。

  2. 性能最大化。對(duì)于Redis的服務(wù)進(jìn)程而言,在開始持久化時(shí),它唯一需要做的只是fork出子進(jìn)程,之后再由子進(jìn)程完成這些持久化的工作,這樣就可以極大的避免服務(wù)進(jìn)程執(zhí)行IO操作了。

  3. 相比于AOF機(jī)制,如果數(shù)據(jù)集很大,RDB的啟動(dòng)效率會(huì)更高。

缺點(diǎn)
  1. 如果你想保證數(shù)據(jù)的高可用性,即最大限度的避免數(shù)據(jù)丟失,那么RDB將不是一個(gè)很好的選擇。因?yàn)橄到y(tǒng)一旦在定時(shí)持久化之前出現(xiàn)宕機(jī)現(xiàn)象,此前沒有來(lái)得及寫入磁盤的數(shù)據(jù)都將丟失。

  2. 由于RDB是通過(guò)fork子進(jìn)程來(lái)協(xié)助完成數(shù)據(jù)持久化工作的,因此,如果當(dāng)數(shù)據(jù)集較大時(shí),可能會(huì)導(dǎo)致整個(gè)服務(wù)器停止服務(wù)幾百毫秒,甚至是1秒鐘。

AOF方式

AOF持久化以日志的形式記錄服務(wù)器所處理的每一個(gè)寫、刪除操作(讀操作不用記錄),以文本方式保存,可以打開此文件看到詳細(xì)的操作過(guò)程。


AOF方式
優(yōu)點(diǎn)
  1. 更高的數(shù)據(jù)安全性。Redis中提供了3種同步策略,即每秒同步、每修改同步和不同步。事實(shí)上,每秒同步也是異步完成的,其效率也是非常高的,所差的是一旦系統(tǒng)出現(xiàn)宕機(jī)現(xiàn)象,那么這一秒鐘之內(nèi)修改的數(shù)據(jù)將會(huì)丟失。而每修改同步,我們可以將其視為同步持久化,即每次發(fā)生的數(shù)據(jù)變化都會(huì)被立即記錄到磁盤中??梢灶A(yù)見,這種方式在效率上是最低的。至于無(wú)同步,無(wú)需多言,我想大家都能正確的理解它。

  2. 由于該機(jī)制對(duì)日志文件的寫入操作采用的是append模式,因此在寫入過(guò)程中即使出現(xiàn)宕機(jī)現(xiàn)象,也不會(huì)破壞日志文件中已經(jīng)存在的內(nèi)容。然而如果我們本次操作只是寫入了一半數(shù)據(jù)就出現(xiàn)了系統(tǒng)崩潰問(wèn)題,不用擔(dān)心,在Redis下一次啟動(dòng)之前,我們可以通過(guò)redis-check-aof工具來(lái)幫助我們解決數(shù)據(jù)一致性的問(wèn)題。

  3. 如果日志過(guò)大,Redis可以自動(dòng)啟用rewrite機(jī)制。即Redis以append模式不斷的將修改數(shù)據(jù)寫入到老的磁盤文件中,同時(shí)Redis還會(huì)創(chuàng)建一個(gè)新的文件用于記錄此期間有哪些修改命令被執(zhí)行。因此在進(jìn)行rewrite切換時(shí)可以更好的保證數(shù)據(jù)安全性。

  4. AOF包含一個(gè)格式清晰、易于理解的日志文件用于記錄所有的修改操作。事實(shí)上,我們也可以通過(guò)該文件完成數(shù)據(jù)的重建。

缺點(diǎn)
  1. 對(duì)于相同數(shù)量的數(shù)據(jù)集而言,AOF文件通常要大于RDB文件。RDB 在恢復(fù)大數(shù)據(jù)集時(shí)的速度比 AOF 的恢復(fù)速度要快的多。

  2. 根據(jù)同步策略的不同(AOF高頻同步),AOF在運(yùn)行效率上往往會(huì)慢于RDB。

二者選擇的標(biāo)準(zhǔn),就是CAP定律(一致性、可用性、容錯(cuò)性)中的C(一致性)和A(可用性)的選擇了。你是愿意犧牲性能換取更高的一致性呢(使用AOF),還是愿意降低一些一致性而換取更好的性能呢(使用RDB)?

配置

RDB持久化配置

save 900 1 # 在900秒(15分鐘)之后,如果至少有1個(gè)key發(fā)生變化,則dump內(nèi)存快照。
save 300 10 # 在300秒(5分鐘)之后,如果至少有10個(gè)key發(fā)生變化,則dump內(nèi)存快照。
save 60 10000 # 在60秒(1分鐘)之后,如果至少有10000個(gè)key發(fā)生變化,則dump內(nèi)存快照。

AOF持久化配置
appendfsync always # 每次有數(shù)據(jù)修改發(fā)生時(shí)都會(huì)寫入AOF文件。
appendfsync everysec # 每秒鐘同步一次,該策略為AOF的缺省策略。
appendfsync no # 從不同步。高效但是數(shù)據(jù)不會(huì)被持久化。

最后編輯于
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請(qǐng)聯(lián)系作者
【社區(qū)內(nèi)容提示】社區(qū)部分內(nèi)容疑似由AI輔助生成,瀏覽時(shí)請(qǐng)結(jié)合常識(shí)與多方信息審慎甄別。
平臺(tái)聲明:文章內(nèi)容(如有圖片或視頻亦包括在內(nèi))由作者上傳并發(fā)布,文章內(nèi)容僅代表作者本人觀點(diǎn),簡(jiǎn)書系信息發(fā)布平臺(tái),僅提供信息存儲(chǔ)服務(wù)。

相關(guān)閱讀更多精彩內(nèi)容

友情鏈接更多精彩內(nèi)容