Redis RDB技術底層原理詳解

Posted on by

每日一句

低頭是一種能力，它不是自卑，也不是怯弱，它是清醒中的嬗變。有時，稍微低一下頭，或者我們的人生路會更精彩。

前提概要

Redis是一個的鍵-值（K-V）對的內存數據庫服務，通常包含瞭任意個非空數據庫。而每個非空的鍵值數據庫中又可以存放任意個K-V，基本的結構如下圖所示：

  • Redis的強勁性能很大程度上是由於其將所有數據都存儲在瞭內存中，為瞭使Redis在重啟之後仍能保證數據不丟失，需要將數據從內存中以某種形式同步到硬盤中，這一過程就是持久化。
  • 我們知道redis中緩存的數據都存放在內存中，一旦服務故障，會導致內存中數據丟失，所以需要一種數據持久化的方案，將redis內存中的數據，寫入磁盤，當redis重啟後，能從磁盤中恢復數據。

Redis服務器的結構

  • 這裡有一個問題，因為Redis是一個內存數據庫，如果它直接將數據存儲到內存中，但是如果不考慮將存儲在內存中的數據持久化到硬盤裡面，一旦服務器進程退出，那麼數據庫中的數據也會消失。
  • 數據庫的持久化機制主要有兩種，一種是RDB機制，另外一種是AOF機制，AOF機制已經在前面的文章中介紹過瞭，
  • 如果有興趣可以去看看，而本文主要講述RDB機制。

RDB持久化方式

RDB持久化是指在指定的時間間隔內將redis內存中的數據集快照寫入磁盤，實現原理是redis服務在指定的時間間隔內先fork一個子進程，由子進程將數據集寫入臨時文件，寫入成功後，再替換之前的文件，用二進制壓縮存儲，生成dump.rdb文件存放在磁盤中。

RDB機制

  • Redis提供瞭RDB持久化能力，這個功能可以將Redis在內存中的數據庫狀態保持在磁盤裡面，避免數據意外丟失。
  • RDB持久化機制可以手動執行，也可以根據服務器配置選定定期執行操作，該功能可以將某一個時間點的數據快照進行保存到一個RDB文件中。

RDB優勢

  • 一旦采用該方式，那麼你的整個Redis數據庫將隻包含一個文件，這對於文件備份而言是非常完美的。比如，你可能打算每個小時歸檔一次最近24小時的數據，同時還要每天歸檔一次最近30天的數據。通過這樣的備份策略，一旦系統出現災難性故障，我們可以非常容易的進行恢復。
  • 對於災難恢復而言，RDB是非常不錯的選擇。因為我們可以非常輕松的將一個單獨的文件壓縮後再轉移到其它存儲介質上。
  • 性能最大化。對於Redis的服務進程而言，在開始持久化時，它唯一需要做的隻是fork出子進程，之後再由子進程完成這些持久化的工作，這樣就可以極大的避免服務進程執行IO操作瞭。
  • 相比於AOF機制，如果數據集很大，RDB的啟動效率會更高。

RDB劣勢

如果你想保證數據的高可用性，即最大限度的避免數據丟失，那麼RDB將不是一個很好的選擇。因為系統一旦在定時持久化之前出現宕機現象，此前沒有來得及寫入磁盤的數據都將丟失。

由於RDB是通過fork子進程來協助完成數據持久化工作的，因此，如果當數據集較大時，可能會導致整個服務器停止服務幾百毫秒，甚至是1秒鐘。

RDB配置規則

在redis的6379.conf配置文件中：

備份配置參數

save <seconds> <changes>

save <指定時間間隔> <執行指定次數更新操作>，滿足條件就將內存中的數據同步到硬盤中。官方出廠配置默認是 900秒內有1個更改，300秒內有10個更改以及60秒內有10000個更改，則將內存中的數據快照寫入磁盤。

save 900 1      #在900秒（15分鐘）之後，如果至少有一個key發生變化，則dump內存快照
save 300 10     #在300秒（15分鐘）之後，如果至少有10個key發生變化，則dump內存快照
save 60 10000   #在60秒（1分鐘）之後，如果至少有10000個key發生變化，則dump內存快照

文件配置參數

默認的rdb文件路徑是當前目錄,文件名是dump.rdb,可以在配置文件中修改路徑和文件名,分別是dir和dbfilename.

# 存放快照的目錄
dir ./ # rdb文件存儲路徑
dbfilename dump.rdb # rdb文件名

壓縮配置參數

在進行鏡像備份時,是否進行壓縮。

rdbcompression yes  #Redis默認是開啟壓縮的。
# yes：壓縮，但是需要一些cpu的消耗。
# no：不壓縮，需要更多的磁盤空間。

如果沒有觸發自動快照,需要對Redis執行手動快照操作,save和bgsave命令來手動快照,兩個命令是：

  • SAVE：由主進程進行快照，會阻塞其他請求。
  • BGSAVE：通過fork子進程進行快照，不會阻塞其他請求。

註意:由於Redis使用fork來復制一份當前進程,那麼子進程就會占有和主進程一樣的內存資源,比如說主進程8G內存,那麼在備份的時候,必須保證有16G的內存,要不然會啟用虛擬內存,性能非常的差。

快照的過程如下：

  • Redis使用fork函數復制一份當前進程（父進程）的副本（子進程）；
  • 父進程繼續接收並處理客戶端發來的命令，而子進程開始將內存中的數據寫入硬盤中的臨時文件；
  • 當子進程寫入完所有數據後會用該臨時文件替換舊的RDB文件，至此一次快照操作完成。（註意：會存在寫一部命令壓縮緩存區，記錄寫入rdb文件時候的操作）

在執行fork的時候操作系統會使用寫時復制（copy-on-write）策略，即fork函數發生的一刻父子進程共享同一內存數據，當父進程要更改其中某片數據時（如執行一個寫命令），操作系統會將該片數據復制一份以保證子進程的數據不受影響，所以新的RDB文件存儲的是執行fork時那一刻的內存快照數據。

通過上述過程可以發現Redis在進行快照的過程中不會修改RDB文件，隻有快照結束後才會將舊的文件替換成新的，也就是說任何時候RDB文件都是完整的。這使得可以通過定時備份RDB文件來實現Redis數據庫備份。

快照的過程壓縮分析：

RDB文件是經過壓縮（上文介紹瞭：可以配置rdbcompression參數以禁用壓縮節省CPU占用）的二進制格式，所以占用的空間會小於內存中的數據大小，更加利於傳輸。

快照的讀取加載過程：

  • Redis啟動後會讀取RDB快照文件，將數據從硬盤載入到內存。根據數據量大小與結構和服務器性能不同，這個時間也不同。通常將一個記錄一千萬個字符串類型鍵、大小為1GB的快照文件載入到內存中需要花費20～30秒鐘。
  • 通過RDB方式實現持久化，一旦Redis異常退出，就會丟失最後一次快照以後更改的所有數據。這就需要開發者根據具體的應用場合，通過組合設置自動快照條件的方式來將可能發生的數據損失控制在能夠接受的范圍。如果數據很重要以至於無法承受任何損失，則可以考慮使用AOF方式進行持久化。

RDB 的優缺點

優點：

  1. 適合大規模的數據恢復。
  2. 如果業務對數據完整性和一致性要求不高，RDB是很好的選擇。

缺點：

  • 數據的完整性和一致性不高，因為RDB可能在最後一次備份時宕機瞭。
  • 備份時占用內存，因為Redis 在備份時會獨立創建一個子進程，將數據寫入到一個臨時文件（此時內存中的數據是原來的兩倍），最後再將臨時文件替換之前的備份文件。
  • 由於RDB是通過fork子進程來協助完成數據持久化工作的，因此，如果當數據集較大時，可能會導致整個服務器停止服務幾百毫秒，甚至是1秒鐘。(回寫和覆蓋的時候用的是主進程)。

RDB與AOF二者選擇的標準（雖然還沒有講AOF，提前普及）

  • 如果系統是願意犧牲一些性能，換取更高的緩存一致性（aof）
  • 或者是願意寫操作頻繁的時候，不啟用備份來換取更高的性能，待手動運行save的時候，再做備份（rdb）。

Redis允許同時開啟AOF和RDB，既保證瞭數據安全又使得進行備份等操作十分容易。此時重新啟動Redis後Redis會使用AOF文件來恢復數據，因為AOF方式的持久化可能丟失的數據更少。

總結

  • Redis 默認開啟RDB持久化方式，在指定的時間間隔內，執行指定次數的寫操作，則將內存中的數據寫入到磁盤中。
  • RDB 持久化適合大規模的數據恢復但它的數據一致性和完整性較差。
  • Redis 需要手動開啟AOF持久化方式，默認是每秒將寫操作日志追加到AOF文件中。

所以Redis的持久化和數據的恢復要選擇在夜深人靜的時候執行是比較合理的。

到此這篇關於Redis RDB技術底層原理詳解的文章就介紹到這瞭,更多相關Redis RDB底層原理內容請搜索WalkonNet以前的文章或繼續瀏覽下面的相關文章希望大傢以後多多支持WalkonNet！

推薦閱讀：