圖解 Redis丨這就是 RDB 快照,能記錄實際資料的

語言: CN / TW / HK
摘要:所謂的快照,就是記錄某一個瞬間東西,比如當我們給風景拍照時,那一個瞬間的畫面和資訊就記錄到了一張照片。RDB 快照就是記錄某一個瞬間的記憶體資料,記錄的是實際資料。

本文分享自華為雲社群《圖解 Redis | 不多說了,這就是 RDB 快照》,原文作者:小林coding 。

雖說 Redis 是記憶體資料庫,但是它為資料的持久化提供了兩個技術。分別是「 AOF 日誌和 RDB 快照」。

這兩種技術都會用各用一個日誌檔案來記錄資訊,但是記錄的內容是不同的。

  • AOF 檔案的內容是操作命令;
  • RDB 檔案的內容是二進位制資料。

今天主要講下 RDB 快照

所謂的快照,就是記錄某一個瞬間東西,比如當我們給風景拍照時,那一個瞬間的畫面和資訊就記錄到了一張照片。

所以,RDB 快照就是記錄某一個瞬間的記憶體資料,記錄的是實際資料,而 AOF 檔案記錄的是命令操作的日誌,而不是實際的資料。

因此在 Redis 恢復資料時, RDB 恢復資料的效率會比 AOF 高些,因為直接將 RDB 檔案讀入記憶體就可以,不需要像 AOF 那樣還需要額外執行操作命令的步驟才能恢復資料。

接下來,就來具體聊聊 RDB 快照 。

快照怎麼用?

要熟悉一個東西,先看看怎麼用是比較好的方式。

Redis 提供了兩個命令來生成 RDB 檔案,分別是 save 和 bgsave,他們的區別就在於是否在「主執行緒」裡執行:

  • 執行了 save 命令,就會在主執行緒生成 RDB 檔案,由於和執行操作命令在同一個執行緒,所以如果寫入 RDB 檔案的時間太長,會阻塞主執行緒
  • 執行了 bgsava 命令,會建立一個子程序來生成 RDB 檔案,這樣可以避免主執行緒的阻塞

RDB 檔案的載入工作是在伺服器啟動時自動執行的,Redis 並沒有提供專門用於載入 RDB 檔案的命令。

Redis 還可以通過配置檔案的選項來實現每隔一段時間自動執行一次 bgsava 命令,預設會提供以下配置:

save 900 1
save 300 10
save 60 10000

別看選項名叫 sava,實際上執行的是 bgsava 命令,也就是會建立子程序來生成 RDB 快照檔案。

只要滿足上面條件的任意一個,就會執行 bgsava,它們的意思分別是:

  • 900 秒之內,對資料庫進行了至少 1 次修改;
  • 300 秒之內,對資料庫進行了至少 10 次修改;
  • 60 秒之內,對資料庫進行了至少 10000 次修改。

這裡提一點,Redis 的快照是全量快照,也就是說每次執行快照,都是把記憶體中的「所有資料」都記錄到磁碟中。

所以可以認為,執行快照是一個比較重的操作,如果頻率太頻繁,可能會對 Redis 效能產生影響。如果頻率太低,伺服器故障時,丟失的資料會更多。

通常可能設定至少 5 分鐘才儲存一次快照,這時如果 Redis 出現宕機等情況,則意味著最多可能丟失 5 分鐘資料。

這就是 RDB 快照的缺點,在伺服器發生故障時,丟失的資料會比 AOF 持久化的方式更多,因為 RDB 快照是全量快照的方式,因此執行的頻率不能太頻繁,否則會影響 Redis 效能,而 AOF 日誌可以以秒級的方式記錄操作命令,所以丟失的資料就相對更少。

執行快照時,資料能被修改嗎?

那問題來了,執行 bgsava 過程中,由於是交給子程序來構建 RDB 檔案,主執行緒還是可以繼續工作的,此時主執行緒可以修改資料嗎?

如果不可以修改資料的話,那這樣效能一下就降低了很多。如果可以修改資料,又是如何做到到呢?

直接說結論吧,執行 bgsava 過程中,Redis 依然可以繼續處理操作命令的,也就是資料是能被修改的。

那具體如何做到到呢?關鍵的技術就在於寫時複製技術(Copy-On-Write, COW)。

執行 bgsava 命令的時候,會通過 fork() 建立子程序,此時子程序和父程序是共享同一片記憶體資料的,因為建立子程序的時候,會複製父程序的頁表,但是頁表指向的實體記憶體還是一個。

只有在發生修改記憶體資料的情況時,實體記憶體才會被複制一份。

這樣的目的是為了減少建立子程序時的效能損耗,從而加快建立子程序的速度,畢竟建立子程序的過程中,是會阻塞主執行緒的。

所以,建立 bgsave 子程序後,由於共享父程序的所有記憶體資料,於是就可以直接讀取主執行緒裡的記憶體資料,並將資料寫入到 RDB 檔案。

當主執行緒對這些共享的記憶體資料也都是隻讀操作,那麼,主執行緒和 bgsave 子程序相互不影響。

但是,如果主執行緒要修改共享資料裡的某一塊資料(比如鍵值對 A)時,就會發生寫時複製,於是這塊資料的實體記憶體就會被複制一份(鍵值對 A'),然後主執行緒在這個資料副本(鍵值對A')進行修改操作。與此同時,bgsave 子程序可以繼續把原來的資料(鍵值對 A)寫入到 RDB 檔案

就是這樣,Redis 使用 bgsave 對當前記憶體中的所有資料做快照,這個操作是由 bgsave 子程序在後臺完成的,執行時不會阻塞主執行緒,這就使得主執行緒同時可以修改資料。

細心的同學,肯定發現了,bgsave 快照過程中,如果主執行緒修改了共享資料,發生了寫時複製後,RDB 快照儲存的是原本的記憶體資料,而主執行緒剛修改的資料,是被辦法在這一時間寫入 RDB 檔案的,只能交由下一次的 bgsave 快照。

所以 Redis 在使用 bgsave 快照過程中,如果主執行緒修改了記憶體資料,不管是否是共享的記憶體資料,RDB 快照都無法寫入主執行緒剛修改的資料,因為此時主執行緒的記憶體資料和子執行緒的記憶體資料已經分離了,子執行緒寫入到 RDB 檔案的記憶體資料只能是原本的記憶體資料。

如果系統恰好在 RDB 快照檔案建立完畢後崩潰了,那麼 Redis 將會丟失主執行緒在快照期間修改的資料。

另外,寫時複製的時候會出現這麼個極端的情況。

在 Redis 執行 RDB 持久化期間,剛 fork 時,主程序和子程序共享同一實體記憶體,但是途中主程序處理了寫操作,修改了共享記憶體,於是當前被修改的資料的實體記憶體就會被複制一份。

那麼極端情況下,如果所有的共享記憶體都被修改,則此時的記憶體佔用是原先的 2 倍。

所以,針對寫操作多的場景,我們要留意下快照過程中記憶體的變化,防止記憶體被佔滿了。

RDB 和 AOF 合體

儘管 RDB 比 AOF 的資料恢復速度快,但是快照的頻率不好把握:

  • 如果頻率太低,兩次快照間一旦伺服器發生宕機,就可能會比較多的資料丟失;
  • 如果頻率太高,頻繁寫入磁碟和建立子程序會帶來額外的效能開銷。

那有沒有什麼方法不僅有 RDB 恢復速度快的優點和,又有 AOF 丟失資料少的優點呢?

當然有,那就是將 RDB 和 AOF 合體使用,這個方法是在 Redis 4.0 提出的,該方法叫混合使用 AOF 日誌和記憶體快照,也叫混合持久化。

如果想要開啟混合持久化功能,可以在 Redis 配置檔案將下面這個配置項設定成 yes:

aof-use-rdb-preamble yes

混合持久化工作在 AOF 日誌重寫過程

當開啟了混合持久化時,在 AOF 重寫日誌時,fork 出來的重寫子程序會先將與主執行緒共享的記憶體資料以 RDB 方式寫入到 AOF 檔案,然後主執行緒處理的操作命令會被記錄在重寫緩衝區裡,重寫緩衝區裡的增量命令會以 AOF 方式寫入到 AOF 檔案,寫入完成後通知主程序將新的含有 RDB 格式和 AOF 格式的 AOF 檔案替換舊的的 AOF 檔案。

也就是說,使用了混合持久化,AOF 檔案的前半部分是 RDB 格式的全量資料,後半部分是 AOF 格式的增量資料

這樣的好處在於,重啟 Redis 載入資料的時候,由於前半部分是 RDB 內容,這樣載入的時候速度會很快

載入完 RDB 的內容後,才會載入後半部分的 AOF 內容,這裡的內容是 Redis 後臺子程序重寫 AOF 期間,主執行緒處理的操作命令,可以使得資料更少的丟失

 

點選關注,第一時間瞭解華為雲新鮮技術~