背景

先說一下redis的普通使用場景，由於redis的資料是儲存在記憶體中，響應速度比起資料庫會快很多，所以一般人們會將redis當做快取使用。但是這裡有一個問題，假如伺服器宕機，記憶體中的資料將全部丟失。

​對於上面問題的解決方案，最容易想到的是直接從後端資料庫恢復資料，但這樣一來必須頻繁訪問資料庫，會給資料庫帶來很大的壓力，同時，資料的響應速度和效能肯定是比不上直接從redis獲取。所以，對 Redis 來說，實現資料的持久化，避免從後端資料庫中進行恢復，是至關重要的。目前，Redis 的持久化主要有兩大機制，即AOF（Append Only File）日誌和 RDB 快照。

一、AOF日誌

實現：

說到日誌，我們比較熟悉的是資料庫的寫前日誌（write ahead log，WAL），也就是說在實際寫資料前，先把修改的資料記到日誌檔案中，以便故障時進行恢復。不過AOF日誌正好相反，它是寫後日志，即redis是先執行命令，把資料寫入記憶體後再記錄日誌的，如下圖：

​對於AOF日誌，記錄的不僅僅是資料，確切的說，redis記錄的是redis收到的每條命令，這些命令都是以文字形式儲存的。以“set key value”為例，看看AOF日誌的內容。其中，“*3”表示當前命令有三個部分，每部分都是由“$+數字”開頭，後面緊跟著具體的命令、鍵或值。這裡，“數字”表示這部分中的命令、鍵或值一共有多少位元組。例如，“$3 set”表示這部分有 3 個位元組，也就是“set”命令。

​為了避免額外的檢查開銷，Redis 在向 AOF 裡面記錄日誌的時候，並不會先去對這些命令進行語法檢查。所以，如果先記日誌再執行命令的話，日誌中就有可能記錄了錯誤的命令，Redis 在使用日誌恢復資料時，就可能會出錯。而寫後日志這種方式，就是先讓系統執行命令，只有命令能執行成功，才會被記錄到日誌中，否則，系統就會直接向客戶端報錯。所以，Redis 使用寫後日志這一方式的一大好處是，可以避免出現記錄錯誤命令的情況。除此之外，AOF 還有一個好處：它是在命令執行後才記錄日誌，所以不會阻塞當前的寫操作。

​不過，AOF 也有兩個潛在的風險。首先，如果剛執行完一個命令，還沒有來得及記日誌就宕機了，那麼這個命令和相應的資料就有丟失的風險。如果此時 Redis 是用作快取，還可以從後端資料庫重新讀入資料進行恢復，但是，如果 Redis 是直接用作資料庫的話，此時，因為命令沒有記入日誌，所以就無法用日誌進行恢復了。其次，AOF 雖然避免了對當前命令的阻塞，但可能會給下一個操作帶來阻塞風險。這是因為，AOF 日誌也是在主執行緒中執行的，如果在把日誌檔案寫入磁碟時，磁碟寫壓力大，就會導致寫盤很慢，進而導致後續的操作也無法執行了。仔細分析的話，你就會發現，這兩個風險都是和 AOF 寫回磁碟的時機相關的。這也就意味著，如果我們能夠控制一個寫命令執行完後 AOF 日誌寫回磁碟的時機，這兩個風險就解除了。

其實，對於這個問題，AOF 機制給我們提供了三個選擇，也就是 AOF 配置項 appendfsync 的三個可選值。

• Always，同步寫回：每個寫命令執行完，立馬同步地將日誌寫回磁碟；

• Everysec，每秒寫回：每個寫命令執行完，只是先把日誌寫到 AOF 檔案的記憶體緩衝區，每隔一秒把緩衝區中的內容寫入磁碟；

• No，作業系統控制的寫回：每個寫命令執行完，只是先把日誌寫到 AOF 檔案的記憶體緩衝區，由作業系統決定何時將緩衝區內容寫回磁碟。

針對避免主執行緒阻塞和減少資料丟失問題，這三種寫回策略都無法做到兩全其美。我們來分析下其中的原因。

• “同步寫回”可以做到基本不丟資料，但是它在每一個寫命令後都有一個慢速的落盤操作，不可避免地會影響主執行緒效能；

• 雖然“作業系統控制的寫回”在寫完緩衝區後，就可以繼續執行後續的命令，但是落盤的時機已經不在 Redis 手中了，只要 AOF 記錄沒有寫回磁碟，一旦宕機對應的資料就丟失了；

• “每秒寫回”採用一秒寫回一次的頻率，避免了“同步寫回”的效能開銷，雖然減少了對系統性能的影響，但是如果發生宕機，上一秒內未落盤的命令操作仍然會丟失。所以，這隻能算是，在避免影響主執行緒效能和避免資料丟失兩者間取了個折中。

​到這裡，我們就可以根據系統對高效能和高可靠性的要求，來選擇使用哪種寫回策略了。總結一下就是：想要獲得高效能，就選擇 No 策略；如果想要得到高可靠性保證，就選擇 Always 策略；如果允許資料有一點丟失，又希望效能別受太大影響的話，那麼就選擇 Everysec 策略。但是，按照系統的效能需求選定了寫回策略，並不是“高枕無憂”了。畢竟，AOF 是以檔案的形式在記錄接收到的所有寫命令。隨著接收的寫命令越來越多，AOF 檔案會越來越大。這也就意味著，我們一定要小心 AOF 檔案過大帶來的效能問題。這裡的“效能問題”，主要在於以下三個方面：一是，檔案系統本身對檔案大小有限制，無法儲存過大的檔案；二是，如果檔案太大，之後再往裡面追加命令記錄的話，效率也會變低；三是，如果發生宕機，AOF 中記錄的命令要一個個被重新執行，用於故障恢復，如果日誌檔案太大，整個恢復過程就會非常緩慢，這就會影響到 Redis 的正常使用。所以，我們就要採取一定的控制手段，這個時候，AOF 重寫機制就登場了。

日誌檔案太大了怎麼辦？

​簡單來說，AOF 重寫機制就是在重寫時，Redis 根據資料庫的現狀建立一個新的 AOF 檔案，也就是說，讀取資料庫中的所有鍵值對，然後對每一個鍵值對用一條命令記錄它的寫入。比如說，當讀取了鍵值對“testkey”: “testvalue”之後，重寫機制會記錄 set testkey testvalue 這條命令。這樣，當需要恢復時，可以重新執行該命令，實現“testkey”: “testvalue”的寫入。

​為什麼重寫機制可以把日誌檔案變小呢? 實際上，重寫機制具有“多變一”功能。所謂的“多變一”，也就是說，舊日誌檔案中的多條命令，在重寫後的新日誌中變成了一條命令。

​我們知道，AOF 檔案是以追加的方式，逐一記錄接收到的寫命令的。當一個鍵值對被多條寫命令反覆修改時，AOF 檔案會記錄相應的多條命令。但是，在重寫的時候，是根據這個鍵值對當前的最新狀態，為它生成對應的寫入命令。這樣一來，一個鍵值對在重寫日誌中只用一條命令就行了，而且，在日誌恢復時，只用執行這條命令，就可以直接完成這個鍵值對的寫入了。

​當我們對一個列表先後做了 6 次修改操作後，列表的最後狀態是[“D”, “C”, “N”]，此時，只用 LPUSH u:list “N”, “C”, "D"這一條命令就能實現該資料的恢復，這就節省了五條命令的空間。對於被修改過成百上千次的鍵值對來說，重寫能節省的空間當然就更大了。不過，雖然 AOF 重寫後，日誌檔案會縮小，但是，要把整個資料庫的最新資料的操作日誌都寫回磁碟，仍然是一個非常耗時的過程。

AOF 重寫會阻塞嗎?

​和 AOF 日誌由主執行緒寫回不同，重寫過程是由後臺子程序 bgrewriteaof 來完成的，這也是為了避免阻塞主執行緒，導致資料庫效能下降。每次執行重寫時，主執行緒 fork 出後臺的 bgrewriteaof 子程序。此時，fork 會把主執行緒的記憶體拷貝一份給 bgrewriteaof 子程序，這裡面就包含了資料庫的最新資料。然後，bgrewriteaof 子程序就可以在不影響主執行緒的情況下，逐一把拷貝的資料寫成操作，記入重寫日誌。

​因為主執行緒未阻塞，仍然可以處理新來的操作。此時，如果有寫操作，第一處日誌就是指正在使用的 AOF 日誌，Redis 會把這個操作寫到它的緩衝區。這樣一來，即使宕機了，這個 AOF 日誌的操作仍然是齊全的，可以用於恢復。而第二處日誌，就是指新的 AOF 重寫日誌。這個操作也會被寫到重寫日誌的緩衝區。這樣，重寫日誌也不會丟失最新的操作。等到拷貝資料的所有操作記錄重寫完成後，重寫日誌記錄的這些最新操作也會寫入新的 AOF 檔案，以保證資料庫最新狀態的記錄。此時，我們就可以用新的 AOF 檔案替代舊檔案了。

​總結來說，每次 AOF 重寫時，Redis 會先執行一個記憶體拷貝，用於重寫；然後，使用兩個日誌保證在重寫過程中，新寫入的資料不會丟失。而且，因為 Redis 採用額外的執行緒進行資料重寫，所以，這個過程並不會阻塞主執行緒。

恢復資料

可以使用可以先使用 Redis 附帶的 redis-check-aof 程式，對原來的 AOF 檔案進行修復，進而再啟動redis

redis-check-aof --fix AOF檔案

二、RDB快照

TODO