共計(jì) 2141 個字符，預(yù)計(jì)需要花費(fèi) 6 分鐘才能閱讀完成。

自動寫代碼機(jī)器人，免費(fèi)開通

這篇文章給大家分享的是有關(guān) redis 中持久化的優(yōu)缺點(diǎn)是什么的內(nèi)容。丸趣 TV 小編覺得挺實(shí)用的，因此分享給大家做個參考。一起跟隨丸趣 TV 小編過來看看吧。

Redis 是一種高級 key-value 數(shù)據(jù)庫。它跟 memcached 類似，不過數(shù)據(jù)可以持久化，而且支持的數(shù)據(jù)類型很豐富。有字符串，鏈表，集 合和有序集合。支持在服務(wù)器端計(jì)算集合的并，交和補(bǔ)集 (difference) 等，還支持多種排序功能。所以 Redis 也可以被看成是一個數(shù)據(jù)結(jié)構(gòu)服務(wù)器。

Redis 的所有數(shù)據(jù)都是保存在內(nèi)存中，然后不定期的通過異步方式保存到磁盤上 (這稱為“半持久化模式”)；也可以把每一次數(shù)據(jù)變化都寫入到一個 append only file(aof) 里面(這稱為“全持久化模式”)。

由于 Redis 的數(shù)據(jù)都存放在內(nèi)存中，如果沒有配置持久化，redis 重啟后數(shù)據(jù)就全丟失了，于是需要開啟 redis 的持久化功能，將數(shù)據(jù)保存到磁盤上，當(dāng) redis 重啟后，可以從磁盤中恢復(fù)數(shù)據(jù)。

redis 提供兩種方式進(jìn)行持久化，一種是 RDB 持久化（原理是將 Reids 在內(nèi)存中的數(shù)據(jù)庫記錄定時 dump 到磁盤上的 RDB 持久化），另外一種是 AOF（append only file）持久化（原理是將 Reids 的操作日志以追加的方式寫入文件）。

那么這兩種持久化方式有什么區(qū)別呢，改如何選擇呢？

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

AOF 持久化以日志的形式記錄服務(wù)器所處理的每一個寫、刪除操作，查詢操作不會記錄，以文本的方式記錄，可以打開文件看到詳細(xì)的操作記錄。

二者優(yōu)缺點(diǎn)

RDB 存在哪些優(yōu)勢呢？

1). 一旦采用該方式，那么你的整個 Redis 數(shù)據(jù)庫將只包含一個文件，這對于文件備份而言是非常完美的。比如，你可能打算每個小時歸檔一次最近 24 小時的數(shù)據(jù)，同時還要每天歸檔一次最近 30 天的數(shù)據(jù)。通過這樣的備份策略，一旦系統(tǒng)出現(xiàn)災(zāi)難性故障，我們可以非常容易的進(jìn)行恢復(fù)。

2). 對于災(zāi)難恢復(fù)而言，RDB 是非常不錯的選擇。因?yàn)槲覀兛梢苑浅］p松的將一個單獨(dú)的文件壓縮后再轉(zhuǎn)移到其它存儲介質(zhì)上。

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

4). 相比于 AOF 機(jī)制，如果數(shù)據(jù)集很大，RDB 的啟動效率會更高。

RDB 又存在哪些劣勢呢？

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

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

AOF 的優(yōu)勢有哪些呢？

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

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

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

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

AOF 的劣勢有哪些呢？

1). 對于相同數(shù)量的數(shù)據(jù)集而言，AOF 文件通常要大于 RDB 文件。RDB 在恢復(fù)大數(shù)據(jù)集時的速度比 AOF 的恢復(fù)速度要快。

2). 根據(jù)同步策略的不同，AOF 在運(yùn)行效率上往往會慢于 RDB。總之，每秒同步策略的效率是比較高的，同步禁用策略的效率和 RDB 一樣高效。

二者選擇的標(biāo)準(zhǔn)，就是看系統(tǒng)是愿意犧牲一些性能，換取更高的緩存一致性（aof），還是愿意寫操作頻繁的時候，不啟用備份來換取更高的性能，待手動運(yùn)行 save 的時候，再做備份（rdb）。rdb 這個就更有些 eventually consistent 的意思了。

感謝各位的閱讀！關(guān)于 redis 中持久化的優(yōu)缺點(diǎn)是什么就分享到這里了，希望以上內(nèi)容可以對大家有一定的幫助，讓大家可以學(xué)到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到吧！

向 AI 問一下細(xì)節(jié)

丸趣 TV 網(wǎng) – 提供最優(yōu)質(zhì)的資源集合！