宕機了，Redis 如何避免資料丟失？

語言: CN / TW / HK
時間 2023-01-31 05:15:05

theme: orange

前言

如果有人問你："你會把 Redis 用在什麼業務場景下？"

我想你大概率會說："我會把它當作快取使用，因為它把後端資料庫中的資料儲存在記憶體中，然後直接從記憶體中讀取資料，響應速度會非常快。"

沒錯，這確實是 Redis 的一個普遍使用場景，但是，這裡也有一個絕對不能忽略的問題：一旦伺服器宕機，記憶體中的資料將全部丟失。

目前，Redis 的持久化主要有兩大機制，即 AOF（Append Only File）日誌和 RDB（Redis DataBase） 快照。

AOF

日誌是如何實現的

說到日誌，我們比較熟悉的是資料庫的寫前日誌（Write Ahead Log, WAL），在實際寫資料前，先把修改的資料記到日誌檔案中，以便故障時進行恢復。不過，AOF 日誌正好相反，它是寫後日志，"寫後"的意思是 Redis 是先執行命令，把資料寫入記憶體，然後才記錄日誌。

image.png

AOF 裡記錄的是 Redis 收到的每一條命令，這些命令是以文字形式儲存的。

我們以 Redis 收到“set testkey testvalue”命令後記錄的日誌為例，看看 AOF 日誌的內容。其中，“*3”表示當前命令有三個部分，每部分都是由“\$+數字”開頭，後面緊跟著具體的命令、鍵或值。這裡，“數字”表示這部分中的命令、鍵或值一共有多少位元組。例如，“$3 set”表示這部分有 3 個位元組，也就是“set”命令。

image.png

寫後日志的優勢與風險

為了避免額外的檢查開銷，Redis 在向 AOF 裡面記錄日誌的時候，並不會先去對這些命令進行語法檢查。

如果先記日誌再執行命令的話，日誌中就有可能記錄了錯誤的命令，Redis 在使用日誌恢復資料時，就可能會出錯。而寫後日志這種方式，就是先讓系統執行命令，只有命令能執行成功，才會被記錄到日誌中，否則，系統就會直接向客戶端報錯。

所以，Redis 使用寫後日志這一方式的一大好處是，可以避免出現記錄錯誤命令的情況。

除此之外，寫後日志一個好處：它是在命令執行後才記錄日誌，不會阻塞當前的寫操作。

AOF 也有兩個潛在的風險： * 風險一：如果剛執行完一個命令，還沒有來得及記日誌就宕機了，那麼這個命令和相應的資料就有丟失的風險。 * 如果此時 Redis 是用作快取，還可以從後端資料庫重新讀入資料進行恢復。 * 如果 Redis 是直接用作資料庫的話，此時，因為命令沒有記入日誌，所以就無法用日誌進行恢復了。 * 風險二：AOF 雖然避免了對當前命令的阻塞，但可能會給下一個操作帶來阻塞風險。 * AOF 日誌也是在主執行緒中執行(寫回策略為 always 時)，如果在把日誌檔案寫入磁碟時，磁碟寫壓力大，就會導致寫盤很慢，進而導致後續的操作也無法執行了。

這兩個風險都是和 AOF 寫回磁碟的時機相關的。這也就意味著，如果我們能夠控制一個寫命令執行完後 AOF 日誌寫回磁碟的時機，這兩個風險就解除了。

日誌的寫回策略

AOF 機制一共有三種寫回策略，也就是 AOF 配置項 appendfsync 的三個可選值。 * Always 同步寫回：每個寫命令執行完，立馬同步地將日誌寫回磁碟； * Everysec 每秒寫回：每個寫命令執行完，只是先把日誌寫到 AOF 檔案的記憶體緩衝區，每隔一秒把緩衝區中的內容寫入磁碟； * No 作業系統控制的寫回：每個寫命令執行完，只是先把日誌寫到 AOF 檔案的記憶體緩衝區，由作業系統決定何時將緩衝區內容寫回磁碟。

針對避免主執行緒阻塞和減少資料丟失問題，這三種寫回策略都無法做到兩全其美。

image.png

我們就可以根據系統對高效能和高可靠性的要求，來選擇使用哪種寫回策略了。 * 想要獲得高效能，就選擇 No 策略； * 想要得到高可靠性保證，就選擇 Always 策略； * 允許資料有一點丟失，又希望效能別受太大影響的話，那麼就選擇 Everysec 策略。

日誌的重寫

重寫的作用

AOF 是以檔案的形式在記錄接收到的所有寫命令。隨著接收的寫命令越來越多，AOF 檔案會越來越大。這也就意味著，我們一定要小心 AOF 檔案過大帶來的效能問題，主要在於以下三個方面：

  • 一是，檔案系統本身對檔案大小有限制，無法儲存過大的檔案；
  • 二是，如果檔案太大，之後再往裡面追加命令記錄的話，效率也會變低；
  • 三是，如果發生宕機，AOF 中記錄的命令要一個個被重新執行，用於故障恢復，如果日誌檔案太大，整個恢復過程就會非常緩慢，這就會影響到 Redis 的正常使用。

AOF 重寫機制就是在重寫時，Redis 根據資料庫的現狀建立一個新的 AOF 檔案，也就是說，讀取資料庫中的所有鍵值對，然後對每一個鍵值對用一條命令記錄它的寫入。重寫機制具有“多變一”功能。所謂的“多變一”，也就是說，舊日誌檔案中的多條命令，在重寫後的新日誌中變成了一條命令。

image.png

重寫的過程

AOF 日誌由主執行緒寫回不同，重寫過程是由後臺子程序 bgrewriteaof 來完成的，這也是為了避免阻塞主執行緒，導致資料庫效能下降。

我把重寫的過程總結為“一個拷貝，兩處日誌”。

“一個拷貝”就是指，每次執行重寫時，主執行緒 fork 出後臺的 bgrewriteaof 子程序。此時，fork 會把主執行緒的記憶體拷貝一份給 bgrewriteaof 子程序，這裡面就包含了資料庫的最新資料。然後，bgrewriteaof 子程序就可以在不影響主執行緒的情況下，逐一把拷貝的資料寫成操作，記入重寫日誌。

第一處日誌，指的是因為主執行緒未阻塞，仍然可以處理新來的操作，Redis 會把這個操作寫到它的緩衝區。這樣一來，即使宕機了，這個 AOF 日誌的操作仍然是齊全的，可以用於恢復。

第二處日誌，就是指新的 AOF 重寫日誌。這個操作也會被寫到重寫日誌的緩衝區。這樣，重寫日誌也不會丟失最新的操作。等到拷貝資料的所有操作記錄重寫完成後，重寫日誌記錄的這些最新操作也會寫入新的 AOF 檔案，以保證資料庫最新狀態的記錄。

此時，我們就可以用新的 AOF 檔案替代舊檔案了。

image.png

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

正因為記錄的是操作命令，而不是實際的資料，所以，用 AOF 方法進行故障恢復的時候，需要逐一把操作日誌都執行一遍。如果操作日誌非常多，Redis 就會恢復得很緩慢，影響到正常使用。這當然不是理想的結果。那麼，還有沒有既可以保證可靠性，還能在宕機時實現快速恢復的其他方法呢？

RDB

對 Redis 來說，它實現類似照片記錄效果的方式，把某一時刻的狀態以檔案的形式寫到磁碟上，也就是快照（RDB 檔案）。這樣一來，即使宕機，快照檔案也不會丟失，資料的可靠性也就得到了保證。

和 AOF 相比，RDB 記錄的是某一時刻的資料，並不是操作，所以，在做資料恢復時，我們可以直接把 RDB 檔案讀入記憶體，很快地完成恢復。

快照的原理

Redis 提供了兩個命令來生成 RDB 檔案，分別是 save 和 bgsave。 * save：在主執行緒中執行，會導致阻塞； * bgsave：建立一個子程序，專門用於寫入 RDB 檔案，避免了主執行緒的阻塞，這也是 Redis RDB 檔案生成的預設配置。

我們可以通過 bgsave 命令來執行全量快照，這既提供了資料的可靠性保證，也避免了對 Redis 的效能影響。

在執行快照的同時，Redis 就會藉助作業系統提供的寫時複製技術（Copy-On-Write, COW），正常處理寫操作。bgsave 子程序是由主執行緒 fork 生成的，可以共享主執行緒的所有記憶體資料。bgsave 子程序執行後，開始讀取主執行緒的記憶體資料，並把它們寫入 RDB 檔案。

如果主執行緒對這些資料也都是讀操作（例如圖中的鍵值對 A），那麼，主執行緒和 bgsave 子程序相互不影響。但是，如果主執行緒要修改一塊資料（例如圖中的鍵值對 C），那麼，這塊資料就會被複制一份，生成該資料的副本（鍵值對 C’）。然後，主執行緒在這個資料副本上進行修改。同時，bgsave 子程序可以繼續把原來的資料（鍵值對 C）寫入 RDB 檔案。 image.png

這樣既保證了快照的完整性，也允許主執行緒同時對資料進行修改，避免了對正常業務的影響。

混合 AOF/RDB

雖然 bgsave 執行時不阻塞主執行緒，但是，如果頻繁地執行全量快照，也會帶來兩方面的開銷。

一方面，頻繁將全量資料寫入磁碟，會給磁碟帶來很大壓力，多個快照競爭有限的磁碟頻寬，前一個快照還沒有做完，後一個又開始做了，容易造成惡性迴圈（所以，在 Redis 中如果有一個 bgsave 在執行，就不會再啟動第二個 bgsave 子程序）。

另一方面，bgsave 子程序需要通過 fork 操作從主執行緒創建出來。雖然，子程序在建立後不會再阻塞主執行緒，但是，fork 這個建立過程本身會阻塞主執行緒，而且主執行緒的記憶體越大，阻塞時間越長。

Redis 4.0 中提出了一個混合使用 AOF 日誌和記憶體快照的方法。簡單來說，記憶體快照以一定的頻率執行，在兩次快照之間，使用 AOF 日誌記錄這期間的所有命令操作。這樣一來，快照不用很頻繁地執行，這就避免了頻繁 fork 對主執行緒的影響。而且，AOF 日誌也只用記錄兩次快照間的操作，也就是說，不需要記錄所有操作了，因此，就不會出現檔案過大的情況了，也可以避免重寫開銷。

image.png

總結

最後，關於 AOF 和 RDB 的選擇問題，我想再給你提三點建議： * 資料不能丟失時，記憶體快照和 AOF 的混合使用是一個很好的選擇； * 如果允許分鐘級別的資料丟失，可以只使用 RDB； * 如果只用 AOF，優先使用 everysec 的配置選項，因為它在可靠性和效能之間取了一個平衡。

參考

摘自 極客時間 - 蔣德鈞老師的《Redis 核心技術與實戰》 <- 極其推薦大家閱讀~

《Redis 核心技術與實戰》學習筆記 Day13

「」
「」