一、優(yōu)勢

1.RDB 是一個非常緊湊(compact)的文件，它保存了redis 在某個時間點上的數(shù)據(jù)集。這種文件非常適合用于進行備份和災(zāi)難恢復(fù)。

2.生成RDB 文件的時候，redis 主進程會fork()一個子進程來處理所有保存工作，主進程不需要進行任何磁盤IO 操作。

3.RDB 在恢復(fù)大數(shù)據(jù)集時的速度比AOF 的恢復(fù)速度要快。

二、劣勢

1、RDB 方式數(shù)據(jù)沒辦法做到實時持久化/秒級持久化。因為bgsave 每次運行都要執(zhí)行fork 操作創(chuàng)建子進程，頻繁執(zhí)行成本過高。

2、在一定間隔時間做一次備份，所以如果redis 意外down 掉的話，就會丟失最后一次快照之后的所有修改（數(shù)據(jù)有丟失）。

如果數(shù)據(jù)相對來說比較重要，希望將損失降到最小，則可以使用AOF 方式進行持久化。

?

AOF

Append Only File

AOF：Redis 默認不開啟。AOF 采用日志的形式來記錄每個寫操作，并追加到文件中。開啟后，執(zhí)行更改Redis 數(shù)據(jù)的命令時，就會把命令寫入到AOF 文件中。

Redis 重啟時會根據(jù)日志文件的內(nèi)容把寫指令從前到后執(zhí)行一次以完成數(shù)據(jù)的恢復(fù)工作。

?

AOF 配置

配置文件redis.conf

# 開關(guān) appendonly no # 文件名 appendfilename "appendonly.aof"

AOF 文件的內(nèi)容（vim 查看）：

問題：數(shù)據(jù)都是實時持久化到磁盤嗎？

由于操作系統(tǒng)的緩存機制，AOF 數(shù)據(jù)并沒有真正地寫入硬盤，而是進入了系統(tǒng)的硬盤緩存。什么時候把緩沖區(qū)的內(nèi)容寫入到AOF 文件？

參數(shù)	說明
appendfsync everysec	AOF 持久化策略（硬盤緩存到磁盤），默認everysec ? no 表示不執(zhí)行fsync，由操作系統(tǒng)保證數(shù)據(jù)同步到磁盤，速度最快，但是不太安全； ? always 表示每次寫入都執(zhí)行fsync，以保證數(shù)據(jù)同步到磁盤，效率很低； ? everysec 表示每秒執(zhí)行一次fsync，可能會導(dǎo)致丟失這1s 數(shù)據(jù)。通常選擇everysec ， 兼顧安全性和效率。

?

?

?

?

?

問題：文件越來越大，怎么辦？

由于AOF 持久化是Redis 不斷將寫命令記錄到AOF 文件中，隨著Redis 不斷的進行，AOF 的文件會越來越大，文件越大，占用服務(wù)器內(nèi)存越大以及AOF 恢復(fù)要求時間越長。

例如set leon 666，執(zhí)行1000 次，結(jié)果都是leon=666。

為了解決這個問題，Redis 新增了重寫機制，當AOF 文件的大小超過所設(shè)定的閾值時，Redis 就會啟動AOF 文件的內(nèi)容壓縮，只保留可以恢復(fù)數(shù)據(jù)的最小指令集。

可以使用命令bgrewriteaof 來重寫。

AOF 文件重寫并不是對原文件進行重新整理，而是直接讀取服務(wù)器現(xiàn)有的鍵值對，然后用一條命令去代替之前記錄這個鍵值對的多條命令，生成一個新的文件后去替換原來的AOF 文件。

# 重寫觸發(fā)機制 auto-aof-rewrite-percentage 100 auto-aof-rewrite-min-size 64mb

參數(shù)	說明
auto-aof-rewrite-percentag e	默認值為100。aof 自動重寫配置，當目前aof 文件大小超過上一次重寫的aof 文件大小的 百分之多少進行重寫，即當aof 文件增長到一定大小的時候，Redis 能夠調(diào)用bgrewriteaof 對日志文件進行重寫。當前AOF 文件大小是上次日志重寫得到AOF 文件大小的二倍（設(shè) 置為100）時，自動啟動新的日志重寫過程。
auto-aof-rewrite-min-size	默認64M。設(shè)置允許重寫的最小aof 文件大小，避免了達到約定百分比但尺寸仍然很小的 情況還要重寫。

?

?

?

?

?

?

問題：重寫過程中，AOF 文件被更改了怎么辦？

另外有兩個與AOF 相關(guān)的參數(shù)：

參數(shù)	說明
no-appendfsync-on-rewrite	在aof 重寫或者寫入rdb 文件的時候，會執(zhí)行大量IO，此時對于everysec 和always 的aof 模式來說，執(zhí)行fsync 會造成阻塞過長時間，no-appendfsync-on-rewrite 字段設(shè)置為默認設(shè) 置為no。如果對延遲要求很高的應(yīng)用，這個字段可以設(shè)置為yes，否則還是設(shè)置為no，這 樣對持久化特性來說這是更安全的選擇。設(shè)置為yes 表示rewrite 期間對新寫操作不fsync, 暫時存在內(nèi)存中,等rewrite 完成后再寫入，默認為no，建議修改為yes。Linux 的默認fsync 策略是30 秒?？赡軄G失30 秒數(shù)據(jù)。
aof-load-truncated	aof 文件可能在尾部是不完整的，當redis 啟動的時候，aof 文件的數(shù)據(jù)被載入內(nèi)存。重啟 可能發(fā)生在redis 所在的主機操作系統(tǒng)宕機后，尤其在ext4 文件系統(tǒng)沒有加上data=ordered 選項，出現(xiàn)這種現(xiàn)象。redis 宕機或者異常終止不會造成尾部不完整現(xiàn)象，可以選擇讓redis 退出，或者導(dǎo)入盡可能多的數(shù)據(jù)。如果選擇的是yes，當截斷的aof 文件被導(dǎo)入的時候， 會自動發(fā)布一個log 給客戶端然后load。如果是no，用戶必須手動redis-check-aof 修復(fù)AOF 文件才可以。默認值為yes。

AOF 數(shù)據(jù)恢復(fù)

重啟Redis 之后就會進行AOF 文件的恢復(fù)。

AOF 優(yōu)勢與劣勢

優(yōu)點：

1、AOF 持久化的方法提供了多種的同步頻率，即使使用默認的同步頻率每秒同步一次，Redis 最多也就丟失1 秒的數(shù)據(jù)而已。

缺點：

1、對于具有相同數(shù)據(jù)的的Redis，AOF 文件通常會比RDF 文件體積更大（RDB存的是數(shù)據(jù)快照）。

2、雖然AOF 提供了多種同步的頻率，默認情況下，每秒同步一次的頻率也具有較高的性能。在高并發(fā)的情況下，RDB 比AOF 具好更好的性能保證。

兩種方案比較

那么對于AOF 和RDB 兩種持久化方式，我們應(yīng)該如何選擇呢？

如果可以忍受一小段時間內(nèi)數(shù)據(jù)的丟失，毫無疑問使用RDB 是最好的，定時生成RDB 快照（snapshot）非常便于進行數(shù)據(jù)庫備份， 并且RDB 恢復(fù)數(shù)據(jù)集的速度也要比AOF 恢復(fù)的速度要快。

否則就使用AOF 重寫。但是一般情況下建議不要單獨使用某一種持久化機制，而是應(yīng)該兩種一起用，在這種情況下,當redis 重啟的時候會優(yōu)先載入AOF 文件來恢復(fù)原始的數(shù)據(jù)，因為在通常情況下AOF 文件保存的數(shù)據(jù)集要比RDB 文件保存的數(shù)據(jù)集要完整。

?

總結(jié)

以上是生活随笔為你收集整理的RDB 文件的优势和劣势的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

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