Redis持久化——記憶體快照(RDB)
我們都知道Redis是記憶體資料庫，它將自己的數據存儲的記憶體中。這樣一旦伺服器進程退出(斷電、重啟等原因)，那麼數據將會丟失。為了解決這個問題，Redis提供兩種持久化的方式來將數據持久化到硬碟上，即記憶體快照(RDB)與AOF日誌。
1 什麼是記憶體快照
所謂記憶體快照，顧名思義就是給記憶體拍個照，在某個時刻把記憶體中的數據記錄下來，以文件的形式保存到硬碟上，這樣即使宕機，數據依然存在。在伺服器重啟後只需要把「照片」中的數據恢復即可。
RDB持久化就是把當前進程的數據在某個時刻生成快照(一個壓縮的二進位文件)保存到硬碟的過程，觸發RDB持久化過程分為手動觸發和自動觸發。
1.1 RDB文件的創建
RDB文件的創建可以手動觸發，也可以自動觸發。
1.1 手動觸發
手動觸發分別對應save和bgsave命令：
1.1.1 save命令
save命令會阻塞當前Redis伺服器，直到RDB過程完成為止。在伺服器進程阻塞期間，伺服器不能處理任何命令請求。因此，當save命令正在執行時，客戶端發送的所有命令都會被拒絕，知道save命令執行完畢。
redis>save //等待，直到RDB文件創建完畢
ok
注意:
Redis的單執行緒模型就決定了，我們要盡量避免所有會阻塞主執行緒的操作，由於Save命令執行期間阻塞伺服器進程，對於記憶體比較大的實例會造成長時間阻塞，因此線上環境不建議使用。
1.1.2 bgsave命令
bgsave命令會派生出一個子進程(而不是執行緒)，由子進程進行RDB文件創建，而父進程繼續處理命令。
redis>bgsave
Background saving started //直接返回，由子進程進行RDB文件創建
redis> //繼續處理其它命令
注意:
- 在bgsave命令執行的時候，為了避免父進程與子進程同時執行兩個rdbSave的調用而產生競爭條件，客戶端發送的save命令會被伺服器拒絕。
- 如果bgsave命令正在執行，bgrewriteaof（aof重寫）命令會被延遲到bgsave命令之後執行，如果bgrewriteaof命令正在執行，那麼客戶端發送的bgsave命令會被伺服器拒絕。
- 雖然bgsave命令是由子進程進行RDB文件的生成，但是fork()創建子進程的時候會阻塞父進程（詳情請往下看）。
1.2 自動觸發
因為bgsave命令可以在不阻塞伺服器進程的情況下保存，所以redis可以通過設置伺服器配置的save選項，讓伺服器每隔一段時間自動執行一次bgsave命令。如：我們向伺服器設置如下配置(這也是redis默認的配置):
save 900 1
save 300 10
save 60 10000
那麼只要滿足如下條件中的一個bgsave命令就會被執行：
- 伺服器在900秒內對資料庫進行了至少1次修改
- 伺服器在300秒內對資料庫進行了至少10次修改
- 伺服器在60秒內對資料庫進行了至少10000次修改
1.2 RDB文件的載入
在Redis啟動的時候，只要檢測到RDB文件的存在，就會自動載入RDB文件。需要注意的是
-
因為AOF文件的更新頻率通常比RDB文件的更新頻率高,所以口如果伺服器開啟了AOF持久化功能,那麼伺服器會優先使用AOF文件來還原資料庫狀態。
-
只有在AOF持久化功能處於關閉狀態時,伺服器才會使用RDB文件來還原資料庫狀態。
注意:伺服器在載入RDB文件期間,會一直處於阻塞狀態,直到載入工作完成為止
2 記憶體快照的問題
了解了什麼是Redis的RDB持久化，我們來思考兩個問題。
2.1 快照的時候數據可以修改嗎
Redis RDB持久化是對某一時刻的記憶體中的全量數據進行拍照。這讓我們不得不思考，快照的時候數據可以修改嗎？
首先，如果我們使用save命令做持久化，那麼由於Redis單執行緒模型的原因，在持久化的過程中會阻塞，是不能執行其它命令的。也許有人會說可以使用bgave命令，但使用bgsave就沒有問題了嗎？
我們在拍照的時候，通常攝影師是不讓我們動的，因為一動可能照片就模糊了。在Redis 進行記憶體快照的時候也會如此。如果我們持久化的過程中，有些數據被修改了。那麼就會破壞快照的正確性與完整性。
比如在t時刻,我們對記憶體進行快照，此時我們希望的是記錄下來t時刻記憶體中所有的數據，假設我們的RDB操作需要10s的時間，而t+2s我們執行了一個修改操作把Key1的值由A修改成了B，而此時RDB操作卻還沒有把Key1的值寫入磁碟。在t+5s的時候讀取到key1的值寫入磁碟。那麼此次快照記錄的Key1的值就是B，而不是t時刻的A。這樣就破壞了RDB文件的正確性。
RDB文件的生成是需要時間的，如果快照執行期間數據不能被修改，對於業務系統來說不能接受的。那麼Redis 是如何解決這個問題的呢？
Redis 藉助了作業系統提供的寫時複製技術（Copy-On-Write, COW），可以讓在執行快照的同時，正常處理寫操作。簡單來說，bgsave fork子進程的時候，並不會完全複製主進程的記憶體數據，而是只複製必要的虛擬數據結構，並不為其分配真實的物理空間，它與父進程共享同一個物理記憶體空間。bgsave 子進程運行後，開始讀取主執行緒的記憶體數據，並把它們寫入 RDB 文件。此時，如果主執行緒對這些數據也都是讀操作，那麼，主執行緒和 bgsave 子進程相互不影響。但是，如果主執行緒要修改一塊數據，此時會給子進程分配一塊物理記憶體空間，把要修改的數據複製一份，生成該數據的副本到子進程的物理記憶體空間。然後，bgsave 子進程會把這個副本數據寫入 RDB 文件，而在這個過程中，主執行緒仍然可以直接修改原來的數據。
2.2 可以頻繁進行快照操作嗎
假設我們在t 時刻做了一次快照，然後又在 t+n 時刻做了一次快照，而在這期間，發生了數據修改。而此時宕機了，那麼，只能按照 t 時刻的快照進行恢復。那麼這n秒的數據就徹底丟失無法恢復了。
所以，要想儘可能恢複數據，就只能縮短快照執行的時間間隔，間隔的時間越小，丟失數據也就越少。那麼可以頻繁的執行快照操作嗎？
我們知道bgsave 執行時並不阻塞主執行緒，但是這不代表可以頻繁執行快照操作。
一方面，持久化是一個寫入磁碟的過程，頻繁將全量數據寫入磁碟，會給磁碟帶來很大壓力，頻繁執行快照也容易導致前一個快照還沒有執行完，後一個又開始了，這樣多個快照競爭有限的磁碟頻寬，容易造成惡性循環。
再者，bgsave所fork出來的子進程執行操作雖然並不會阻塞父進程的操作，但是fork出子進程的操作卻是由主進程完成的，會阻塞主進程，fork子進程需要拷貝進程必要的數據結構，其中有一項就是拷貝記憶體頁表（虛擬記憶體和物理記憶體的映射索引表），這個拷貝過程會消耗大量CPU資源，拷貝完成之前整個進程是會阻塞的，阻塞時間取決於整個實例的記憶體大小，實例越大，記憶體頁表越大，fork阻塞時間也就越久。
也許有人會想到是否可以做增量快照呢？也就是只對上一次快照之後的數據做快照。
首先思路肯定是可以，但是增量快照要求記住哪些數據上一次快照之後產生的。這就需要額外的元數據來記錄這些資訊，會引入額外的空間消耗。這對於記憶體資源寶貴的 Redis 來說，並不是一個很好的方案。
如果不能頻繁執行快照操作，那麼該如何解決兩次快照之間的數據丟失的問題呢？Redis 還提供了另外一種持久化方式——AOF(append to file)日誌。
關於AOF日誌請看Redis持久化——AOF日誌
