一、RDB持久化的缺點
創建RDB文件需要將服務器所有的數據庫的數據都保存起來，這是一個非常耗費資源和時間的操作，所以服務器需要隔一段時間才能創建一個新的RDB文件，就也是說創建RDB文件的操作不能執行的過于頻繁，否則就會嚴重地影響服務器的性能。

在 save 配置選項的默認設置下，即使有超過 10000 次修改操作發生，服務器也至少會間隔一分鐘才創建下一個 RDB 文件：

save 900 1 save 300 10 save 60 10000

如果在等待創建下一個 RDB 文件的過程中，服務器遭遇了意外停機，那么用戶將丟失最后一次創建RDB 文件之后，數據庫發生的所有修改。

解決方法：

為了解決 RDB 持久化在遭遇意外停機時丟失大量數據的問題，Redis 提供了 AOF 持久化功能。比起 RDB 持久化， AOF 持久化有一個巨大的優勢，那就是，用戶可以根據自己的需要對 AOF 持久化進行調整，讓 Redis 在遭遇意外停機時不丟失任何數據，或者只丟失一秒鐘數據，這比 RDB 持久化遭遇意外停機時，丟失的數據要少得多。

?

二、AOF 持久化的運作原理

數據保存

AOF 持久化保存數據庫數據的方法是：每當有修改數據庫的命令被執行時，服務器就會將被執行的命令寫入到 AOF 文件的末尾。

數據還原

因為 AOF 文件里面儲存了服務器執行過的所有數據庫修改命令，所以給定一個 AOF 文件，服務器只要重新執行一遍 AOF 文件里面包含的所有命令，就可以達到還原數據庫數據的目的。
舉個例子，對于包含以下內容的 AOF 文件來說：

SELECT 0 SET msg "hello" INCR counter SADD alphabets "a" "b" "c" INCR counter

服務器只要重新執行這些命令，就可以還原出右圖所示的數據庫

安全性問題
雖然服務器每執行一個修改數據庫的命令，就會將被執行的命令寫入到 AOF 文件，但這并不意味著AOF 持久化不會丟失任何數據。
在目前常見的操作系統中，執行系統調用 write 函數，將一些內容寫入到某個文件里面時，為了提高效率，系統通常不會直接將內容寫入到硬盤里面，而是先將內容放入到一個內存緩沖區（buffer）里面，等到緩沖區被填滿，或者用戶執行 fsync 調用和 fdatasync 調用時，才將儲存在緩沖區里面的內容真正地寫入到硬盤里面。
對于 AOF 持久化來說，當一條命令真正地被寫入到硬盤里面時，這條命令才不會因為停機而意外丟失。
因此，AOF 持久化在遭遇停機時丟失命令的數量，取決于命令被寫入到硬盤的時間：
1） 越早將命令寫入到硬盤，發生意外停機時丟失的數據就越少；
2） 越遲將命令寫入到硬盤，發生意外停機時丟失的數據就越多。

?

安全性控制
為了控制 Redis 服務器在遇到意外停機時丟失的數據量，Redis 為 AOF 持久化提供了 appendfsync選項，這個選項的值可以是 always 、 everysec 或者 no ，這些值的意思分別為：
always ：服務器每寫入一個命令，就調用一次 fdatasync ，將緩沖區里面的命令寫入到硬盤里面。在這種模式下，服務器即使遭遇意外停機，也不會丟失任何已經成功執行的命令數據。
everysec ：服務器每秒鐘調用一次 fdatasync ，將緩沖區里面的命令寫入到硬盤里面。在這種模式下，服務器遭遇意外停機時，最多只丟失一秒鐘內執行的命令數據。
no ：服務器不主動調用 fdatasync ，由操作系統決定何時將緩沖區里面的命令寫入到硬盤里面。在這種模式下，服務器遭遇意外停機時，丟失命令的數量是不確定的。

運行速度： always 的速度慢， everysec 和 no 都很快。默認值： everysec 。

?

三、AOF 重寫
隨著服務器的不斷運行，為了記錄數據庫發生的變化，服務器會將越來越多的命令寫入到 AOF 文件里面，使得 AOF 文件的體積不斷地增大。為了讓 AOF 文件的大小控制在合理的范圍，避免它胡亂地增長，Redis 提供了 AOF 重寫功能，通過這個功能，服務器可以產生一個新的 AOF 文件：
1） 新 AOF 文件記錄的數據庫數據和原有 AOF 文件記錄的數據庫數據完全一樣；
2） 新的 AOF 文件會使用盡可能少的命令來記錄數據庫數據，因此新 AOF 文件的體積通常會比原有 AOF 文件的體積要小得多。
3） AOF 重寫期間，服務器不會被阻塞，可以正常處理客戶端發送的命令請求。

AOF 重寫的觸發
有兩種方法可以觸發 AOF 重寫：
1） 客戶端向服務器發送 BGREWRITEAOF 命令；
2） 通過設置配置選項來讓服務器自動執行 BGREWRITEAOF 命令，它們分別是：
auto-aof-rewrite-min-size <size> ，觸發 AOF 重寫所需的最小體積：只有在 AOF 文件的體積
大于等于 size 時，服務器才會考慮是否需要進行 AOF 重寫。這個選項用于避免對體積過小的AOF 文件進行重寫。
auto-aof-rewrite-percentage <percent> ，指定觸發重寫所需的 AOF 文件體積百分比：當 AOF
文件的體積大于 auto-aof-rewrite-min-size 指定的體積，并且超過上一次重寫之后的 AOF 文件體積的 percent% 時，就會觸發 AOF 重寫。（如果服務器剛剛啟動不久，還沒有進行過 AOF 重寫，那么使用服務器啟動時載入的 AOF 文件的體積來作為基準值。）將這個值設置為 0 表示關閉自動 AOF 重寫。
例子：

auto-aof-rewrite-percentage 100 auto-aof-rewrite-min-size 64mb

?

四、AOF持久化小結
創建 RDB 文件需要將服務器包含的所有數據全部寫入到硬盤里面，這是一個非常耗費資源和時間的操作，因此服務器通常需要每隔一段時間才創建一個新的 RDB 文件，這使得服務器在遭遇意外停機時，可能會丟失大量數據；

AOF 持久化會將每個修改了數據庫的命令都寫入到 AOF 文件末尾，在啟動服務器的時候，只要重新執行 AOF 文件包含的命令，就可以還原服務器原有的數據庫數據；

因為寫入緩沖區的存在，AOF 持久化的安全性取決于緩沖區里面的命令何時會被真正地寫入到硬盤里面，通過設置 appendfsync 配置選項，用戶可以讓 AOF 持久化不丟失任何已經成功執行的命令數據，或者只丟失一秒鐘內被執行的命令數據，又或者不主動執行 fdatasync 調用，將寫入硬盤的時機交給操作系統來管理；

隨著服務器的運行，AOF 文件會產生越來越多冗余命令，使得文件的體積不斷增大，而通過執行 AOF重寫操作，服務器可以創建一個保存相同數據庫數據，但不包含任何冗余命令的新 AOF 文件，并使用這個新 AOF 文件來代替原有的 AOF 文件。

?

五、RDB和AOF對比

可以同時使用兩種持久化，根據你的需求來判斷。還原數據優先使用 AOF 文件。

總結

以上是生活随笔為你收集整理的Redis数据持久化之AOF持久化的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。