RDB 持久化可以在指定的時間間隔內(nèi)生成數(shù)據(jù)集的時間點快照（point-in-time snapshot）。

AOF 持久化記錄服務(wù)器執(zhí)行的所有寫操作命令，并在服務(wù)器啟動時，通過重新執(zhí)行這些命令來還原數(shù)據(jù)集。?AOF?文件中的命令全部以?Redis?協(xié)議的格式來保存，新命令會被追加到文件的末尾。?Redis?還可以在后臺對?AOF?文件進(jìn)行重寫（rewrite），使得?AOF?文件的體積不會超出保存數(shù)據(jù)集狀態(tài)所需的實際大小。Redis?還可以同時使用?AOF?持久化和?RDB?持久化。 在這種情況下， 當(dāng)?Redis?重啟時， 它會優(yōu)先使用?AOF?文件來還原數(shù)據(jù)集， 因為?AOF?文件保存的數(shù)據(jù)集通常比?RDB?文件所保存的數(shù)據(jù)集更完整。你甚至可以關(guān)閉持久化功能，讓數(shù)據(jù)只在服務(wù)器運行時存在。

RDB 的優(yōu)點:

RDB 是一個非常緊湊（compact）的文件，它保存了?Redis?在某個時間點上的數(shù)據(jù)集。 這種文件非常適合用于進(jìn)行備份： 比如說，你可以在最近的?24?小時內(nèi)，每小時備份一次?RDB?文件，并且在每個月的每一天，也備份一個?RDB?文件。 這樣的話，即使遇上問題，也可以隨時將數(shù)據(jù)集還原到不同的版本。RDB?非常適用于災(zāi)難恢復(fù)（disaster recovery）：它只有一個文件，并且內(nèi)容都非常緊湊，可以（在加密后）將它傳送到別的數(shù)據(jù)中心，或者亞馬遜?S3?中。RDB?可以最大化?Redis?的性能：父進(jìn)程在保存?RDB?文件時唯一要做的就是?fork?出一個子進(jìn)程，然后這個子進(jìn)程就會處理接下來的所有保存工作，父進(jìn)程無須執(zhí)行任何磁盤?I/O?操作。RDB?在恢復(fù)大數(shù)據(jù)集時的速度比?AOF?的恢復(fù)速度要快。

RDB 的缺點:

如果你需要盡量避免在服務(wù)器故障時丟失數(shù)據(jù)，那么?RDB?不適合你。 雖然?Redis?允許你設(shè)置不同的保存點（save point）來控制保存?RDB?文件的頻率， 但是， 因為RDB?文件需要保存整個數(shù)據(jù)集的狀態(tài)， 所以它并不是一個輕松的操作。 因此你可能會至少?5?分鐘才保存一次?RDB?文件。 在這種情況下， 一旦發(fā)生故障停機， 你就可能會丟失好幾分鐘的數(shù)據(jù)。每次保存RDB?的時候，Redis?都要?fork()?出一個子進(jìn)程，并由子進(jìn)程來進(jìn)行實際的持久化工作。 在數(shù)據(jù)集比較龐大時，?fork()?可能會非常耗時，造成服務(wù)器在某某毫秒內(nèi)停止處理客戶端； 如果數(shù)據(jù)集非常巨大，并且?CPU?時間非常緊張的話，那么這種停止時間甚至可能會長達(dá)整整一秒。 雖然?AOF?重寫也需要進(jìn)行?fork()?，但無論?AOF?重寫的執(zhí)行間隔有多長，數(shù)據(jù)的耐久性都不會有任何損失。

AOF 的優(yōu)點:

使用?AOF?持久化會讓?Redis?變得非常耐久（much more durable）：你可以設(shè)置不同的?fsync?策略，比如無?fsync?，每秒鐘一次?fsync?，或者每次執(zhí)行寫入命令時?fsync?。?AOF?的默認(rèn)策略為每秒鐘?fsync?一次，在這種配置下，Redis?仍然可以保持良好的性能，并且就算發(fā)生故障停機，也最多只會丟失一秒鐘的數(shù)據(jù)（?fsync?會在后臺線程執(zhí)行，所以主線程可以繼續(xù)努力地處理命令請求）。AOF?文件是一個只進(jìn)行追加操作的日志文件（append only log）， 因此對?AOF?文件的寫入不需要進(jìn)行seek?， 即使日志因為某些原因而包含了未寫入完整的命令（比如寫入時磁盤已滿，寫入中途停機，等等），?redis-check-aof?工具也可以輕易地修復(fù)這種問題。

Redis 可以在?AOF?文件體積變得過大時，自動地在后臺對?AOF?進(jìn)行重寫： 重寫后的新?AOF?文件包含了恢復(fù)當(dāng)前數(shù)據(jù)集所需的最小命令集合。 整個重寫操作是絕對安全的，因為?Redis?在創(chuàng)建新?AOF?文件的過程中，會繼續(xù)將命令追加到現(xiàn)有的?AOF?文件里面，即使重寫過程中發(fā)生停機，現(xiàn)有的?AOF?文件也不會丟失。 而一旦新?AOF?文件創(chuàng)建完畢，Redis?就會從舊?AOF?文件切換到新?AOF?文件，并開始對新?AOF?文件進(jìn)行追加操作。AOF?文件有序地保存了對數(shù)據(jù)庫執(zhí)行的所有寫入操作， 這些寫入操作以?Redis?協(xié)議的格式保存， 因此?AOF?文件的內(nèi)容非常容易被人讀懂， 對文件進(jìn)行分析（parse）也很輕松。 導(dǎo)出（export）?AOF?文件也非常簡單： 舉個例子， 如果你不小心執(zhí)行了?FLUSHALL?命令， 但只要?AOF?文件未被重寫， 那么只要停止服務(wù)器， 移除?AOF?文件末尾的?FLUSHALL?命令， 并重啟?Redis?， 就可以將數(shù)據(jù)集恢復(fù)到?FLUSHALL?執(zhí)行之前的狀態(tài)。

AOF 的缺點:

對于相同的數(shù)據(jù)集來說，AOF?文件的體積通常要大于?RDB?文件的體積。根據(jù)所使用的?fsync?策略，AOF?的速度可能會慢于RDB?。 在一般情況下， 每秒?fsync?的性能依然非常高， 而關(guān)閉?fsync?可以讓?AOF?的速度和?RDB?一樣快， 即使在高負(fù)荷之下也是如此。 不過在處理巨大的寫入載入時，RDB?可以提供更有保證的最大延遲時間（latency）。AOF?在過去曾經(jīng)發(fā)生過這樣的?bug?： 因為個別命令的原因，導(dǎo)致?AOF?文件在重新載入時，無法將數(shù)據(jù)集恢復(fù)成保存時的原樣。 （舉個例子，阻塞命令?BRPOPLPUSH?就曾經(jīng)引起過這樣的?bug?。） 測試套件里為這種情況添加了測試： 它們會自動生成隨機的、復(fù)雜的數(shù)據(jù)集， 并通過重新載入這些數(shù)據(jù)來確保一切正常。 雖然這種?bug?在?AOF?文件中并不常見， 但是對比來說，?RDB?幾乎是不可能出現(xiàn)這種?bug?的。

總結(jié)

以上是生活随笔為你收集整理的请分别介绍一下aof和rdb都有哪些优点？以及两者有何区别？的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。