我們知道 Redis 之所以讀寫快、性能高，得益于它是一種基于內存的數據庫，毫無疑問它的操作都幾乎都是基于內存。但是內存型數據庫也有一個很大的弊端：如果進程崩潰或者服務重啟的時候內存數據得不到保存，就會造成數據丟失。為了解決這個問題 Redis 提供了兩種持久化方式 RDB 和 AOF 。今天筆者主要和大家一起探討 Redis 的 AOF 模式是如何運行的。

AOF 詳解

AOF 是 Append Only File 的縮寫，默認是關閉的。當 Redis 啟動時只要開啟 AOF 模式就會通過 AOF 文件恢復數據，否則將從 RDB 快照文件中恢復數據。開啟 AOF 模式需要將 redis.conf 中默認的 appendonly no 改為 appendonly yes 。AOF 開啟后 Redis 內部會維護一份 AOF 文件，AOF 文件可以看做是 Redis 的日志文件。Redis 服務使用其通信協議的格式將更新命令保存到 AOF 文件中，所以文件內容容易被人讀懂，我們在維護時能夠輕松的對文件進行分析。

工作原理

Redis 內部維護了一個緩沖區 aof_buf ，Redis 服務如果發現有更新命令，這些更新命令不是被直接寫入到 AOF 文件中的，而是會被先以 Redis 通信協議的格式追加到 aof_buf 中(命令追加)，維護 aof_buf 緩沖區的同時會執行 appendfsync 策略(寫入和同步策略)。

持久化的過程

了解 appendfsync 策略之前我們先要搞清楚 AOF 持久化的過程，它一共有三步：

1)命令追加：更新命令追加寫入到 aof_buf 中。

2)文件寫入：執行 write 操作，寫入到系統緩沖區。

3)文件同步：從系統緩沖區同步到磁盤中。

同步策略(appendfsync)

1)always：Redis 每次執行更新命令將 aof_buf 中內容寫入并同步到 AOF 文件中。 該策略每次執行更新命令觸發，每次發生數據變更就會立刻同步到到磁盤。

always 策略

2)everysec： 將 aof_buf 緩沖區所有內容寫入到 AOF 文件，如果上次同步時間距離現在超過1秒鐘，那么再次對 AOF 文件進行同步，這個操作是由一個線程專門負責執行的。everysec 策略持久化性能較好，但是宕機時會造成數據丟失。

everysec 策略

3)no：將 aof_buf 中的內容寫入到 AOF 文件中，但并不對 AOF 同步，何時同步由操作系統來決定。

no 策略

我們可以看到三種策略都是將 aof_buf 緩沖區的所有內容寫入到 aof 文件，只是同步時操作不一樣。在操作系統中，除非設置了自動同步，否則為了減少磁盤的寫入量，延長磁盤壽命、提高文件寫入效率。寫入文件時并不是同步寫入到磁盤中，而是先寫入內存，這段內存區域被稱為系統緩沖區。在系統緩沖區數據累計到一定數量后(具體數量因系統實際設置而定)，會有系統進程一次性寫入所有緩沖數據。因此只有等到同步執行完畢這是才是持久化完成。

always 的優點是數據安全，效率太低，因為過于頻繁的調用系統；只有在這種策略下，redis的事務是滿足持久化的。

no 的優點是效率較高，但是不夠安全，因為 aof_buf 中的數據可能因為宕機而丟失。

ererysec 介于兩者之間，在效率和安全之間達到一個平衡。這里我們又一次看到折中思想在計算機中的應用。

AOF 的重寫機制

AOF 文件由于不斷寫入，會變得越來越大。通過分析 AOF 文件，往往發現里面有太多的重復和冗余數據，重寫策略就是成一個新的 AOF 文件來代替舊的 AOF 文件，這個操作在滿足一定條件 Redis 會自動觸發。

當 AOF 文件大小從 0 增長到指定大小時，會觸發 AOF 的第一次 rewrite 操作，Redis 會 fork 出來一個進程(這樣主進還可以程繼續處理命令，fork出來的子進程帶有主進程的數據副本，可以在避免鎖的情況下，保證數據的一致性)，通過 bgRewriteAOF 命令完成：基于當前數據生成新 AOF 文件。在此期間 Redis 如果收到新的更新命令，Redis 會將命令暫時保存在內存。等待新的 AOF 文件生成后，Redis 會將內存中的命令追加到新 AOF 文件中。新 AOF 完成后，Redis 會刪除舊的 AOF 文件。當新的 AOF 文件擴大到2倍的時候會觸發第二次 rewrite。

在重寫期間，主進程繼續處理命令，而新的命令有可能還會對現在有數據進行修改，這會導致當前數據庫中的數據和生成的 AOF 文件不一致。Redis 維護了一個 AOF 重寫緩沖區 rewrite_buf ，主進程接收到更新命令后，把命令寫入到 rewrite_buf 中。這樣主進程在接收到跟新命令的時候一邊將命令寫入 aof_buf ，(重寫執行是)一邊寫入到 rewrite_buf 中(重寫的時候會保持繼續更新舊 AOF 文件)。

fork 出來的子進程完成 bgRewriteAOF 操作后，會向主進程發送信號，會執行一個信號處理函數 1)將 rewrite_buf 中的數據全量寫到新的 AOF 文件中。2)重命名新 AOF 文件，覆蓋舊文件。信號處理函數完成時主進程會短暫阻塞。

AOF 優勢劣勢有哪些呢？

優勢

1)AOF 模式帶來了更高數據安全性的數據持久化解決方案。

2)AOF 模式對日志文件的寫入操作采用的是 append 模式，因此在寫入過程中即使出現宕機現象，也不會破壞日志文件中已經存在的內容。如果我們數據寫入了一半出現了宕機現象 redis-check-aof 工具可以幫我們解決問題，感興趣同學們可以去研究下。

3)如果日志過大，Redis 有自動啟動的 rewrite 機制。即 Redis 以 append 模式不斷的將修改數據寫入到老的磁盤文件中，同時Redis還會創建一個新的文件用于記錄此期間有哪些修改命令被執行。因此在進行 rewrite 切換時可以更好的保證數據安全性。

4) AOF 包含一個格式清晰、易于理解的日志文件用于記錄所有的更新操作。事實上，我們也可以通過該文件完成數據的重建。

劣勢

1)由于 AOF 格式是 Redis 通信協議并且文件是命令 append 因此通常要大于 RDB 模式下產生的 .rdb 文件。RDB 模式產生的是數據快照文件小，海量數據集時 RDB 模式恢復速度會比 AOF 快。

2)同步策略與 RDB 模式，AOF 在運行效率上往往會慢于 RDB 。但是，everysec 同步策略的效率也是是比較高的，no 同步策略的效率和RDB一樣高效。

---

總結：

Redis 的兩種持久化機制各有優劣，AOF 模式是犧牲性能換取數據數據一致性， RDB 模式則是犧牲一致性換取更高性能。同學們選型時需要根據業務場景合理的使用。

想了解 RDB 持久化模式的同學可以關注下，下回再一起聊一聊~

點擊收藏、關注不迷路，歡迎大家評論區留言討論~

總結

以上是生活随笔為你收集整理的执行一次怎么会写入两次数据_浅谈 Redis 数据持久化之 AOF 模式的全部內容，希望文章能夠幫你解決所遇到的問題。

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