快捷導(dǎo)航

一文帶你了解Redis中RDB與AOF的區(qū)別

更新時間：2023年06月09日 10:55:06 作者：不肯過江東丶

Redis 在持久化時，給我們提供了兩種方式，這兩種方式就是 RDB 與 AOF，那這兩種方式有什么區(qū)別呢，本文就帶大家詳細(xì)的了解一下二者的區(qū)別,需要的朋友可以參考下

Redis 中的 RDB 與 AOF

我們都知道，Redis 運(yùn)行時是將數(shù)據(jù)保存在內(nèi)存中的，如果服務(wù)器宕機(jī)或者重啟，那么內(nèi)存中的數(shù)據(jù)必然會丟失，從而影響正常的業(yè)務(wù)運(yùn)行。所以，我們就必須要把數(shù)據(jù)持久化到磁盤，以便服務(wù)器故障時進(jìn)行數(shù)據(jù)恢復(fù)。Redis 在持久化時，給我們提供了兩種方式，這兩種方式就是 RDB 與 AOF。

RDB

RDB 即 RedisDB 的縮寫，這種持久化方式是將整個 Redis 內(nèi)存數(shù)據(jù)持久化到一個 .rdb 文件中。它保存了 Redis 在某個時間點上的數(shù)據(jù)集，這種數(shù)據(jù)集文件非常適用于備份，比如說，你可以每小時備份出一個 .rdb 文件，并且在每天的24點也備份出一個 .rdb 文件。這樣即使遇上問題，也可以隨時將數(shù)據(jù)集還原到不同的版本。這時候可能就有小伙伴要提出疑問了：“如果 Redis 在做持久化的同時，內(nèi)存數(shù)據(jù)被修改了怎么辦呢？比如數(shù)據(jù)一開始是 A，但是在做持久化的時候由 A 變成了 B，那最終持久化到 .rdb 文件中的值是多少呢？??” 這個問題問的就很好了，我們一起來揭秘一下??

??大家一起來揭秘??
在揭秘之前，我們需要先提一個小的知識點，不知道 Linux 下的 fork 函數(shù)大家有沒有用過呢？fork 函數(shù)是 Linux 的子進(jìn)程創(chuàng)建函數(shù)。它會通過復(fù)制主進(jìn)程的方式快速創(chuàng)建一個子進(jìn)程，并且在調(diào)用 fork 函數(shù)時，子進(jìn)程和主進(jìn)程有相同的數(shù)據(jù)內(nèi)容，二者運(yùn)行在各自的內(nèi)存空間，互不影響。Redis 就是通過調(diào)用 fork 的方式來創(chuàng)建子進(jìn)程，并通過子進(jìn)程進(jìn)行數(shù)據(jù)的持久化，所以子進(jìn)程就會保留持久化開始時刻的數(shù)據(jù)狀況。所以，對于上面那個問題來說，持久化的數(shù)據(jù)依然是 A。

關(guān)于 RDB，Redis 又提供了2種使用方式，分別是命令和配置文件。如果我們選擇使用命令的話，就可以通過 save 和 bgsave 命令，觸發(fā)持久化操作；當(dāng)然我們也可以選擇使用配置文件的方式來進(jìn)行持久化，比如可以修改 Redis 的配置文件為 save 100 10 （100 秒內(nèi)有10個key被修改時觸發(fā)持久化）、 save 60 10000（60 秒內(nèi)有10000個key被修改時觸發(fā)持久化）等等。

通過上面的了解，我們也可以總結(jié)出 RDB 的一些優(yōu)缺點了??

??優(yōu)點??

?? ① RDB 非常適用于災(zāi)難恢復(fù)。它只有一個文件，并且內(nèi)容都非常緊湊，在數(shù)據(jù)恢復(fù)時會比較容易操作。
?? ② RDB 可以最大化 Redis 的性能。父進(jìn)程在保存 RDB 文件時唯一要做的就是 fork 出一個子進(jìn)程，然后這個子進(jìn)程就會處理接下來的所有保存工作，父進(jìn)程無須執(zhí)行任何磁盤 I/O 操作。

??缺點??

?? ① 如果你需要盡量避免在服務(wù)器故障時丟失數(shù)據(jù)，那么我們就最好不要選擇 RDB 了。雖然 Redis 允許你設(shè)置不同的保存點來控制保存 RDB 文件的頻率，但是 RDB 文件需要保存整個數(shù)據(jù)集的狀態(tài)，所以它并不是一個輕松的操作。因此可能會至少花費 5 分鐘甚至更多時間才能保存好一次 RDB 文件。那么在這種情況下，一旦發(fā)生故障停機(jī)，就可能會丟失好幾分鐘的數(shù)據(jù)。
?? ② 每次保存 RDB 文件的時候，Redis 都要 fork 出一個子進(jìn)程，并由子進(jìn)程來進(jìn)行實際的持久化工作。那么如果在數(shù)據(jù)集比較龐大時， fork 操作可能會非常耗時，并可能會造成服務(wù)器在若干毫秒內(nèi)停止處理客戶端的請求；如果數(shù)據(jù)集非常巨大，并且 CPU 時間非常緊張的話，那么這種停止時間甚至可能會更長。

AOF

我們了解完 RDB 后再一起來看看 AOF。它就類似于 Binlog 的 statement 模式，AOF 會將 Redis 中每一步對數(shù)據(jù)修改的操作記錄都記錄到相應(yīng)的文件中。同時為了降低 I/O 消耗，AOF 寫文件時，會先將數(shù)據(jù)寫到緩沖區(qū)，然后再把緩沖區(qū)的內(nèi)容寫到磁盤，這個過程叫做 fsync。我們也可以設(shè)置不同的 fsync 策略??

appendfsync always ：每次寫操作都會將內(nèi)容寫到磁盤，但是會影響性能 appendfsync everysec ：每秒寫一次（AOF 的默認(rèn)策略） appendfsync no ：消極等待OS刷新(一般30s)，但是可能丟失數(shù)據(jù)

隨著服務(wù)器運(yùn)行時間越來越長，AOF 文件也勢必會越來越大，Redis 可以在 AOF 文件體積變得過大時，自動地在后臺對 AOF 進(jìn)行重寫。重寫后的新 AOF 文件包含了恢復(fù)當(dāng)前數(shù)據(jù)集所需的最小命令集合。整個重寫操作是絕對安全的，因為 Redis 在創(chuàng)建新 AOF 文件的過程中，會繼續(xù)將命令追加到現(xiàn)有的 AOF 文件里面，即使重寫過程中發(fā)生停機(jī)，現(xiàn)有的 AOF 文件也不會丟失。而一旦新 AOF 文件創(chuàng)建完畢，Redis 就會從舊 AOF 文件切換到新 AOF 文件，并開始對新 AOF 文件進(jìn)行追加操作。

通過上面的了解，我們也可以總結(jié)出 AOF 的一些優(yōu)缺點了??

??優(yōu)點??