本篇重點談一談自己對AOF重寫的理解，不講代碼！不講代碼！！不講代碼！！！
因為redis是內存型的nosql數據庫，所以對於數據的安全問題必須要考慮，redis支持將數據持久化的磁盤。redis的持久化方式有兩種——RDB和AOF。
對於RDB，簡單提一句，通俗的說它就是一個快照（備份）機制，在某時刻redis會產生一個父進程的副本（快照），並由子進程將快照寫入臨時文件，這種方式看起來非常簡單粗暴，而且可以想象，如果系統發生崩潰，且在最近一次rdb之后還有未備份的數據，那么這些數據會損失掉，我們大多數情況下是不能接受這樣的數據損失的（比如電商系統），所以RDB的這種機制並不適於實時性的持久化。
AOF是redis的另一種持久化的機制，相對於RDB，redis就更適合於更實時的數據持久化操作。
那么AOF是通過怎樣的機制進行數據的持久化呢？
首先redis會將其運行過程中執行成功的每一個寫操作（操作指令），寫入一個.aof文件，當redis重啟時，只需要完全的執行一次已經保存的aof文件，就可以恢復以前的數據。由於保存的是操作指令，通過將aof文件復制到其他服務器執行，就可以實現數據的移植。由於aof存放的是操作指令，所以它單次的消耗會遠低於RDB，所以它更適合做更實時的持久化。
需要注意的是，如果RDB和AOF同時存在，那么redis會以AOF為准。
AOF中有怎樣的配置用來控制AOF的寫入頻率呢？
AOF有這樣幾種配置用來控制讀寫的頻率：
（1）每次一收到寫命令就立即強制寫入磁盤，保證完全的持久化。（對應配置 appendfsync always）
這種做法看起來幾乎完美無缺，最大程度上的實現了數據的完整性，但是我們忽略了redis的讀寫效率。通過在redis目錄下執行redis-benchmark命令可以查看redis的讀寫效率，大概在10w次/s，這樣的一個超高速度對於我們的磁盤來說幾乎是不可承受的，如果某一時刻redis的寫操作達到這樣的峰值，我們的磁盤大概會崩潰，這樣的機制在一個心臟大血管小的場景下，會極大的產生io開銷，其實很難保證數據的安全。
（2）由操作系統決定何時同步數據。（對應配置 appendfsync no）
這樣的機制就更不用說了，我們完全沒辦法確定操作系統的選擇，雖然這種操作保證了性能，但是如果系統宕機，那么redis會丟失多少數據也是我們不能確定的。
（3）每秒鍾強制寫入磁盤一次。（對應配置 appendfsync everysec）
這種機制在性能和持久化方面做了很好的折中，雖然一秒鍾的時間在我們看起來很短，但是對於redis確是很長的一段時間，畢竟人家10w次的讀寫效率在那里擺着。而這種機制也是redis推薦的配置，打開redis的配置文件就會發現，前面兩種配置都是被注釋掉的。
AOF在開啟過程中有什么需要注意或者了解的？
首先，AOF的同步時間間隔很小，能使得數據更安全，理論上來說，在AOF狀態下redis至多丟失一秒的數據，因為我們的推薦配置就是每秒鍾強制寫入一次，它比RDB的實時性更高。其次，當redis重啟時，可能會執行一個非常大的aof，因為我們所有數據的寫操作可能都被保存在.aof文件中，這樣的話會導致redis重啟時間很長（大數據中是以100G數據為入門級別的）。而第三點，就是AOF文件會不斷的增長，它可能會比RDB產生的快照文件大幾倍，因為它保存的是對所有數據的所有寫操作，而我們通常對同一數據不止進行一次寫操作，或增加或修改或刪除，同一數據可能會有很多這樣的操作，數據量小的情況下或許沒什么，但是在極端情況下，就可能會對磁盤空間造成壓力。
那么如何解決AOF文件增長的問題呢？就引出了本篇隨筆的重點——AOF重寫。
AOF重寫的實現
為了減小aof文件的體量，可以手動發送“bgrewriteaof”指令，通過子進程生成更小體積的aof，然后替換掉舊的、大體量的aof文件。
AOF重寫的工作原理
上圖就是AOF的工作原理了，感覺自己畫的還是比較通俗易懂的哈哈哈
需要注意的是，在這里子進程把數據轉為寫指令存入新的AOF文件時，記錄的只是每個數據的最后一次寫指令，也就是最新的數據，不會記錄之前冗余的操作，所以這樣會很大程度的縮小AOF的體量，同時，該操作是產生新的AOF文件進行寫入，而不是在原有文件上的修改，通過上圖也可以看出來。而緩存中疊加到新的aof的操作仍是新增的全部操作，但是這些數據已經很有限，相比之前的一股腦添加，這種機制很好的解決的AOF文件不斷增大的問題。
AOF重寫的相關配置
1）auto-aof-rewrite-percentage 100
2）auto-aof-rewrite-min-size 64mb
這兩個配置項的意思是，在aof文件體量超過64mb，且比上次重寫后的體量增加了100%時自動觸發重寫。我們可以修改這些參數達到自己的實際要求
AOF重寫須知
和RDB一樣，如果當前的數據量巨大，那么創建子進程的過程會很耗時。在大數據的處理工作中，文件的刪除也是一項比較麻煩的工作。想我們普通的筆記本電腦，刪除一個幾GB的文件都是一項很耗時的工作，更何況大數據的量級遠遠大過我們日常使用的數據。所以在替換aof文件時，如果舊的aof很大，刪除它也是一個很耗時的過程。當然這並不是aof或者redis的缺點，只是可能會出現的一個客觀情況。