快捷導(dǎo)航

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

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

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

Redis 中的 RDB 與 AOF

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

RDB

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

??大家一起來揭秘??
在揭秘之前，我們需要先提一個(gè)小的知識(shí)點(diǎn)，不知道 Linux 下的 fork 函數(shù)大家有沒有用過呢？fork 函數(shù)是 Linux 的子進(jìn)程創(chuàng)建函數(shù)。它會(huì)通過復(fù)制主進(jìn)程的方式快速創(chuàng)建一個(gè)子進(jìn)程，并且在調(diào)用 fork 函數(shù)時(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)程就會(huì)保留持久化開始時(shí)刻的數(shù)據(jù)狀況。所以，對(duì)于上面那個(gè)問題來說，持久化的數(shù)據(jù)依然是 A。

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

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

??優(yōu)點(diǎn)??

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

??缺點(diǎn)??

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

AOF

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

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

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

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

??優(yōu)點(diǎn)??