為什麼需要持久化，以及Redis持久化的RDB方式在這篇文章講的已經很透徹了，足以弔打面試官了。而且此篇內容需要RDB文章的內容支持，所以建議先看下：看完這篇還不懂Redis的RDB持久化，你們來打我！ 一、什麼是AOF 它也是Redis持久化的重要手段之一，aof->Append Only Fil ...
為什麼需要持久化，以及Redis持久化的RDB方式在這篇文章講的已經很透徹了，足以弔打面試官了。而且此篇內容需要RDB文章的內容支持，所以建議先看下：看完這篇還不懂Redis的RDB持久化，你們來打我！
一、什麼是AOF
它也是Redis持久化的重要手段之一，aof->Append Only File，只追加文件，也就是每次處理完請求命令後都會將此命令追加到aof文件的末尾。而RDB是壓縮成二進位等時機開子進程去乾這件事。
二、優缺點
1、優點
- 持久化的速度快，因為每次都只是追加，rdb每次都全量持久化
- 數據相對更可靠，丟失少，因可以配置每秒持久化、每個命令執行完就持久化
2、缺點
- 災難性恢復的時候過慢，因為aof每次都只追加原命令，導致aof文件過大，但是後面會rewrite，但是相對於rdb也是慢的。
- 會對主進程對外提供請求的效率造成影響，接收請求、處理請求、寫aof文件這三步是串列原子執行的。而非非同步多線程執行的。Redis單線程！
三、AOF原理
1、基礎原理
就是每次都在aof文件後面追加命令。他與主進程收到請求、處理請求是串列化的，而非非同步並行的。圖示如下
在這裡插入圖片描述
所以aof的頻率高的話絕逼會對Redis帶來性能影響，因為每次都是刷盤操作。跟mysql一樣了。Redis每次都是先將命令放到緩衝區，然後根據具體策略（每秒/每條指令/緩衝區滿）進行刷盤操作。如果配置的always，那麼就是典型阻塞，如果是sec，每秒的話，那麼會開一個同步線程去每秒進行刷盤操作，對主線程影響稍小。
2、額外擴展
其實Redis每次在寫入AOF緩衝區之前，他都會調用flushAppendOnlyFile()，判斷是否需要將AOF緩衝區的內容寫入和同步到AOF文件中。這個決策是由配置文件的三個策略來控制的
- always
- everysec
- no
四、REWRITE
1、為什麼要rewrite？
比如我有業務很簡單，就來回delete set 同一個key。就這個業務運行了10年，那麼aof文件將記錄無數個delete k1， set k1 xxx。其實都是重覆的，但是我aof每次都追加，文件變成了1T大小。這時候Redis宕機了，要恢復，你想想1TB大小的aof文件去恢復，累死了。最主要的是1TB大小隻記錄了兩個命令，所以壓縮其實就是來處理這件事的。
2、4.0版本之前的rewrite
Redis4.0之前和Redis4.0的rewrite（重寫）方式不一樣，Redis4.0之前就是將aof文件中重覆的命令給去掉。保留最新的命令。進而減少aof文件大小。比如
set k1 123
set k1 345
del k1
set k1 789經過rewrite後（Redis4.0之前），只會變成如下
set k1 7893、4.0版本以及之後的rewrite
4.0之前的做法效率很是低下，需要逐條命令對比。4.0開始的rewrite支持混合模式(也是就是rdb和aof一起用)，直接將rdb持久化的方式來操作將二進位內容覆蓋到aof文件中（rdb是二進位，所以很小），然後再有寫入的話還是繼續append追加到文件原始命令，等下次文件過大的時候再次rewrite（還是按照rdb持久化的方式將內容覆蓋到aof中）。但是這種模式也是配置的，預設是開，也可以關閉。
4、rewrite觸發條件
1、手動觸發
- 客戶端執行bgrewriteaof命令
2、自動觸發
通過以下兩個配置協作觸發
auto-aof-rewrite-min-size
AOF文件最小重寫大小，只有當AOF文件大小大於該值時候才可能重寫,4.0預設配置64mb。
auto-aof-rewrite-percentage
當前AOF文件大小和最後一次重寫後的大小之間的比率等於或者等於指定的增長百分比，如100代表當前AOF文件是上次重寫的兩倍時候才重寫。
3、觸發滿足條件
- 沒有BGSAVE命令（RDB持久化）/AOF持久化在執行
- 沒有BGREWRITEAOF在進行；
前兩點也就是說只允許同時fork()一個子進程出來幹活。
- 當前AOF文件大小要大於server.aof_rewrite_min_size的值；
- 當前AOF文件大小和最後一次重寫後的大小之間的比率等於或者大於指定的增長百分比（auto-aof-rewrite-percentage參數）
5、rewrite原理
4.0之前版本的，和4.0以及之後關閉混合模式的情況下。
在這裡插入圖片描述
- aof_rewrite_buf：rewrite(重寫)緩衝區、aof_buf：寫命令存放的緩衝區
- 開始bgrewriteaof的時候，判斷當前有沒有bgsave/bgrewriteaof在執行，若有，則不執行，這個再rdb篇幅也有提到，以及下麵很多fork()知識在rdb都有提到。看完這篇還不懂Redis的RDB持久化，你們來打我！
- 主進程fork()出子進程，在執行fork()這個方法的時候是阻塞的，子進程創建完畢後就不阻塞了
- 主進程fork完子進程後，主進程能繼續接收客戶端的請求，所有寫命令依然是寫入AOF文件緩衝區並根據配置文件的策略同步到磁碟的。
- 因為fork的子進程僅僅共用主進程fork()時的記憶體，後期主進程在更改記憶體數據，子進程是不可見的。因此Redis採取重寫緩衝區（aof_rewite_buf）保存fork之後的客戶端請求。防止新AOF文件生成期間丟失主進程執行的新命令所生成的數據。所以此時客戶端的寫請求不僅僅寫入原來的aof_buf緩衝區，還寫入了重寫緩衝區。這就是我為什麼用深藍色的框給他兩框到一起的原因。
- 子進程通過記憶體快照的形式，開始生成新的aof文件。
- 新aof文件生成完後，子進程向主進程發信號。
- 主進程收到信號後，會把重寫緩衝區(aof_rewite_buf)中的數據寫入到新的AOF文件（主要是避免這部分數據丟失）
- 使用新的AOF文件覆蓋舊的AOF文件，且標記AOF重寫完成。
五、RDB-AOF混合持久化
redis4.0之後才支持，預設開啟
1、優點
混合持久化結合了RDB持久化 和 AOF 持久化的優點,採取了rdb的文件小易於災難恢復，同時結合AOF，增量的數據以AOF方式保存了，數據更少的丟失。
2、缺點
相容性差，一旦開啟了混合持久化，在4.0之前版本都不識別該aof文件，同時由於前部分是RDB格式，需要專業的工具來閱讀，因為是二進位，所以閱讀性較差。
3、原理
需要先掌握看完這篇還不懂Redis的RDB持久化，你們來打我！和此篇幅的aof
混合持久化也是通過bgrewriteaof完成的，所以基本流程和上述一樣。不同的是當開啟混合模式時，fork出的子進程先將共用的記憶體副本全量以RDB的方式寫入aof。這樣提高了速度也極大的縮小了aof文件（畢竟都是二進位）。寫完還是通知主進程，然後再將重寫緩衝區的內容以AOF方式寫入到文件，然後替換舊的aof文件。也就是說這種模式下的aof文件發生rewrite後前半部分是rdb格式（REDIS開頭的二進位數據），後半部分是正常的aof追加的命令（重寫緩衝區里的）。
4、數據恢復
會優先看是否存在aof文件，若存在則先按照aof文件恢復，因為aof畢竟比rdb全。若aof不存在，則才會查找rdb是否存在。這是預設的機制。畢竟aof文件也rewrite成rdb二進位格式，文件小，易於回覆。所以redis會優先採取aof。
六、總結
此篇都是重點，廢話很少。沒啥可總結的。
最後小編整理了一套技術資料不僅能精準消除技術盲點、累計面試經驗，更可以攻剋JVM、Spring、分散式、微服務等技術難題。
海量電子書，珍藏版
領取步驟
1.加微信獲取
