AOF(AppendOfFile)介紹:
以日誌的形式來記錄每個寫操作,將Redis執行過的所有寫指令記錄下來(讀操作不記錄),只許追加檔案但不可以改寫檔案,redis啟動之初會讀取該檔案重新構建資料,換言之,redis重啟的話就根據記錄檔的內容將寫指令從前到後執行一次以完成資料的恢複工作
也就是說AOF會將所有的寫操作以日的形式志記錄到檔案中,而且這個儲存的時間間隔是1秒鐘,那麼這個時候所有的記錄是不是就絕對的正確了,而不會像RDB那樣丟失最後一次儲存的資料,那麼問題來了,如果操作的次數越多,那麼所記錄下來的也就也多,記錄檔也就越大,比如
set k1 1incr k1incr k1incr k1incr k1incr k1incr k1incr k1incr k1incr k1incr k1incr k1incr k1……
這裡呢k1每次增長,但是回複的是會如果我們執行
set k1 100
100表示我們增長的次數,這樣是不是會比incr的命令效率更高,而卻也可以防止出錯,這個也就是AOF的缺點
AOF配置介紹:
預設是不開啟AOF的,因為redis認為RDB已經足夠滿足持久化的需求了,那麼在這裡我們就需要修改配置,啟動AOF
OK,啟動之後,那麼這個時候就有兩個持久化的策略了,那麼這個時候會出問題嗎。
這個是不會有衝突的,因為RDB幹RDB的事,AOF幹AOF的事,所以大家可以放心的使用,是不會有衝突的
首先把之前產生的dump.rdb刪除
執行上述命令之後我們可以發現在redis的安裝目錄下會有appendonlyfile.aof檔案,那麼我們可以開啟看看
我們可以看到這裡記錄了我們所有的寫操作,那麼接下來就是重新啟動redis服務,查看剛才的那些操作是否會恢複
串連之後我們發現之前的操作並沒有恢複,這個是怎麼回事呢。還記得剛剛我執行了flushall命令嗎,沒錯就是這個命令搞得鬼,其實是已經恢複了,只不過在恢複之後又執行了flushall操作,然後就把資料給清空了。OK那麼接下來我們就手動刪除flushall的命令,使資料正常的恢複
這個時候呢我們再次啟動redis就會發現之前的全部都已經恢複了(註:如果沒有恢複稍等片刻後再查看,有可能redis還沒有讀AOF)
紅框的部分是為了類比在記錄寫動作記錄的過程中出錯的情況,那麼這個時候我們再次啟動redis服務並且串連
這個時候發現無法串連redis服務,因為是之前的.aof在讀的過程中出現了異常,所以導致串連失敗。那麼這個時候說明事先讀取.aof檔案的。那麼該怎麼修複呢。是不是我們通過vim或者vi手動去刪除剛才那些未知的內容呢。那肯定不是的了
大家可以看到在redis的安裝目錄下有個redis-ckeck-aof,這個就是用來修複AOF檔案的,執行命令
redis-check-aof --fix appendonlyfile.aof
這個時候再次開啟AOF檔案
這個時候發現之前那些未知的字串已經沒有了
那麼這個時候再次啟動redis服務並且串連
這個時候呢我們發現就可以正常的使用redis了