• dbfilename：預設為dump.rdb，即預設的備份檔名為dump.rdb，可以通過這個配置進行修改；
• dir：預設為當前目錄，即備份的檔案存放的目錄。

RDB手動觸發備份

上面說到自動觸發備份，其實在實際應用場景中，有些需求很急，如果要求等到滿足條件備份完成之後才處理問題，間隔時間短還好點，如果間隔時間超過5分鐘，估計等待處理問題的人要上房揭瓦啦；Redis同樣為大家考慮到了，提供手動備份的方式，如下：

• save：直接執行save命令，但會阻塞主程序操作，只能等待備份完成之後才能進行其他處理；
• bgsave：直接執行bgsave命令，主程序會fork一個子程序進行備份操作，不阻塞主程序；當資料過大時，可能會在fork的時候有短暫的耗時，但影響不大； 上面的自動備份其實最後也是bgsave這種模式。
• flushall：執行flushall命令會觸發RBD備份，但是備份檔案是空的，在本地測試一把就行了，沒有任何意義，千萬別在生產庫上用；

簡單測試一下，刪除dump.rdb檔案，將配置檔案恢復到預設值，然後指定配置檔案重啟redis-server，如下：

如何停止或禁用RDB快照自動備份

可以通過配置檔案的形式配置，也可以通過命令的形式進行關閉，但通過命令的方式，伺服器重啟之後就失效了，所以一般建議通過配置檔案進行配置；

• 配置檔案方式：去除所有關於save的配置，或者配置一個save ""即可，重啟redis-server；
• 命令方式：在客戶端中執行config set save ""即可，但redis-server重啟時就恢復預設值了；

RDB備份流程

簡要說明：

1. 當觸發bgsave持久化時(滿足配置條件或手動執行bgsave命令)，主程序fork一個子程序進行持久化操作，主程序不參與任何持久化IO操作；
2. 為了不影響原有rdb檔案的使用，子程序會將快照資料先寫入到臨時檔案;
3. 當快照資料完全備份到臨時檔案時，就替換掉原有的rdb檔案，從而得到最新資料的rdb檔案；

注：當執行sava命令的時候，會導致阻塞，只有等快照資料持久化完成之後，才能做其他事情；

RDB持久化優缺點

每一項技術在解決已有問題的時候，肯定也會帶來新問題，RDB用來解決持久化問題，那它有什麼優缺點呢？

優點

• RDB儲存的資料檔案比較緊湊，對比AOF來說，相同資料的檔案大小比較小；
• 大量資料持久化時速度相對AOF比較快；
• RDB中bgsave模式對主程序影響比較小，只有在主程序fork子程序的時候耗費資源，但影響不大；自動備份後臺用的就是bgsave模式；

缺點

• RDB可能會丟失最後一次沒有備份的資料，如果在最後一次沒開始備份之前，伺服器掛了，那最後一次的資料就沒了；
• 當資料量巨大時，主程序在fork子程序的時候，可能會導致稍微的卡頓；

AOF持久化

既然已經有了RDB持久化了，那為什麼還得出一個AOF呢？從RDB的缺點來看，很大程度上是因為可能會丟失最後一次備份之前的資料，對於一些重要資料來說，是不能接受的。而AOF的出現，將資料丟失風險極大的降低。先不說那麼多，實操一把再慢慢聊。

AOF預設情況是沒開啟的，開啟配置檔案，為了不讓RDB備份影響，這裡暫時先將RDB備份禁用掉，如下：

1.禁用RDB備份：

2.開啟AOF備份：根據上一篇文章提到的，先找到APPEND ONLY MODE配置塊，將AOF備份開啟appendonly yes

3.配置好了，指定配置檔案重啟redis-server，先來看看效果：

當一啟動redis-server的時候，appendonly.aof檔案就已經生成了；來，咱們接著敲點命令，如下↓↓↓

4.嘗試開啟appendonly.aof檔案看看，和dump.rdp檔案有什麼不同；

appendonly.aof只記錄寫命令，讀命令不記錄，而且記錄方式是以追加的方式，所以速度相對比較快；

同RDB一樣，在redis-server重啟時，自動載入AOF檔案命令依次執行，最終將資料進行恢復；

AOF其他配置項

這就是Redis的強大，針對每一個功能都可以通過配置項進行完成，使用非常方便；

• appendonly：預設no，不開啟AOF持久化；可以通過設定為yes開啟；
• appendfilename：預設appendonly.aof，代表生成的AOF日誌檔名，可以更改；
• appendfsync：預設everysec，設定同步命令到磁碟的策略，即預設每秒通過fsync進行一次命令同步到磁碟；有三種命令同步策略可以選擇，如下：always：只要有寫入命令就通過fsync同步到磁碟，資料完整性好，但效率不好；everysec：每秒通過fsync進行一次命令同步到磁碟，可能會導致一秒中資料的丟失，因為可能在命令還沒同步的時候，機器掛掉等操作，但可接受；綜合考慮，推薦使用這種策略；no：不同步，由作業系統處理，這種資料不能保證安全；
• auto-aof-rewrite-percentage：預設100，搭配auto-aof-rewrite-min-size一起觸發AOF檔案重寫策略，即預設噹噹前AOF檔案大小是上次重寫的兩倍時才重寫，為了避免比率達到觸發條件，但檔案很小就觸發重寫的情況，所以搭配auto-aof-rewrite-min-size設定AOF檔案的最小重寫大小；即當前AOF檔案大小達到比率的同時檔案大小不低於auto-aof-rewrite-min-size設定的值才觸發重寫；
• auto-aof-rewrite-min-size：預設64mb，搭配auto-aof-rewrite-percentage使用；

AOF觸發重寫

當執行的寫命令過多時，就會導致AOF檔案過度增大，而對於一些重複性的命令存在AOF檔案中是沒有必要的，如下圖所示：

上圖中多次對a1這個Key進行多次寫入，最終的值為10，可見如果AOF檔案中只記錄一條最終值的寫命令豈不是最好，從而減少AOF檔案的大小；這裡檔案大小肯定達不到自動觸發重寫的條件，這裡就手動觸發，然後再看看AOF檔案內容，是否進行了優化，如下：

如上圖可見，重寫之後的AOF檔案的確是我們自己想要，是不是覺得Redis更加牛X了；觸發重寫有以下兩種方式：

• 自動觸發：即當滿足設定的auto-aof-rewrite-percentage和auto-aof-rewrite-min-size值會自動觸發重寫；
• 手動觸發：在客戶端中執行bgrewriteaof命令；

AOF重寫流程

簡要說明：

1. 當觸發到重寫AOF檔案時，主程序fork一個子程序，子程序根據記憶體中的現有資料進行命令精簡化，重寫到新的AOF檔案中；
2. 在子程序正在重寫AOF檔案時，如果有新的寫命令，將其存放到重寫緩衝區，同時也同步到原來的AOF檔案；
3. 當子程序重寫完成之後，通知主程序將重寫緩衝區中的新命令寫入到新AOF檔案中，完成之後，用新的AOF檔案將原來的AOF檔案替換；
4. 最後得到優化之後的AOF檔案，減少檔案大小；

AOF檔案修復

對於AOF檔案內容的合法性怎麼解決呢，有可能由於突然事件，比如宕機，導致AOF檔案寫入不完整；也有可能有人惡意新增不規範資料，redis會怎麼處理呢？這裡就模擬手動修改AOF檔案，如下：

根據提示，使用redis-check-aof --fix 進行修復，如下：

啟動圖就不截了，小夥伴們試試去；還有redis也能對rdb檔案修復，文中沒有體現，但小夥伴記得去嘗試一下，用redis-check-rdb這個工具即可，在windows版本中redis沒有提供此工具，去linux用高點的版本實操一把。

AOF持久化優缺點

AOF的出現，是解決了RDB丟失最後一次沒儲存的資料，極大的降低了資料丟失的風險，但其也帶來相關問題；

優點

• 降低資料丟失風險，如果丟失，最多一秒資料；
• 以追加方式記錄日誌，速度快；
• 自動優化AOF檔案，檔案過大時進行重寫，精簡AOF檔案；

缺點

獨家面經總結，超級精彩

本人面試騰訊，阿里，百度等企業總結下來的面試經歷，都是真實的，分享給大家！

Java面試準備

準確的說這裡又分為兩部分：

1. Java刷題
2. 演算法刷題

Java刷題：此份文件詳細記錄了千道面試題與詳解；

以上所有文件已經打包好，只需要動動手指點選【轉發+關注】，然後點選即可免費獲取！