對 redis 來說，它實現類似照片記錄效果的方式，就是把某一時刻的狀態以文件的形式寫到磁盤上，也就是快照。這樣一來，即使宕機，快照文件也不會丟失，數據的可靠性也就得到了保證。這個快照文件就稱為 RDB 文件，其中，RDB 就是 Redis DataBase 的縮寫。
和 AOF 相比，RDB 記錄的是某一時刻的數據，并不是操作，所以，在做數據恢復時，我們可以直接把 RDB 文件讀入內存，很快地完成恢復。聽起來好像很不錯，但內存快照也并不是最優選項。為什么這么說呢？
我們還要考慮兩個關鍵問題：
- 對哪些數據做快照？這關系到快照的執行效率問題；
- 做快照時，數據還能被增刪改嗎？這關系到 Redis 是否被阻塞，能否同時正常處理請求。
這么說可能你還不太好理解，我還是拿拍照片來舉例子。我們在拍照時，通常要關注兩個問題：
- 如何取景？也就是說，我們打算把哪些人、哪些物拍到照片中；
- 在按快門前，要記著提醒朋友不要亂動，否則拍出來的照片就模糊了
給哪些內存數據做快照？
Redis 的數據都在內存中，為了提供所有數據的可靠性保證，它執行的是全量快照，也就是說，把內存中的所有數據都記錄到磁盤中，這就類似于給 100 個人拍合影，把每一個人都拍進照片里。這樣做的好處是，一次性記錄了所有數據，一個都不少。
當你給一個人拍照時，只用協調一個人就夠了，但是，拍 100 人的大合影，卻需要協調 100 個人的位置、狀態，等等，這當然會更費時費力。同樣，給內存的全量數據做快照，把它們全部寫入磁盤也會花費很多時間。而且，全量數據越多，RDB 文件就越大，往磁盤上寫數據的時間開銷就越大。
對于 Redis 而言，它的單線程模型就決定了，我們要盡量避免所有會阻塞主線程的操作，所以，針對任何操作，我們都會提一個靈魂之問：“它會阻塞主線程嗎?”RDB 文件的生成是否會阻塞主線程，這就關系到是否會降低 Redis 的性能。
Redis 提供了兩個命令來生成 RDB 文件，分別是 save 和 bgsave。
- save：在主線程中執行，會導致阻塞；
- bgsave：創建一個子進程，專門用于寫入 RDB 文件，避免了主線程的阻塞，這也是 Redis RDB 文件生成的默認配置。
好了，這個時候，我們就可以通過 bgsave 命令來執行全量快照，這既提供了數據的可靠性保證，也避免了對 Redis 的性能影響。
接下來，我們要關注的問題就是，在對內存數據做快照時，這些數據還能“動”嗎? 也就是說，這些數據還能被修改嗎？這個問題非常重要，這是因為，如果數據能被修改，那就意味著 Redis 還能正常處理寫操作。否則，所有寫操作都得等到快照完了才能執行，性能一下子就降低了。
快照時數據能修改嗎?
在給別人拍照時，一旦對方動了，那么這張照片就拍糊了，我們就需要重拍，所以我們當然希望對方保持不動。對于內存快照而言，我們也不希望數據“動”。
舉個例子。我們在時刻 t 給內存做快照，假設內存數據量是 4GB，磁盤的寫入帶寬是 0.2GB/s，簡單來說，至少需要 20s（4/0.2 = 20）才能做完。如果在時刻 t+5s 時，一個還沒有被寫入磁盤的內存數據 A，被修改成了 A’，那么就會破壞快照的完整性，因為 A’不是時刻 t 時的狀態。因此，和拍照類似，我們在做快照時也不希望數據“動”，也就是不能被修改。
但是，如果快照執行期間數據不能被修改，是會有潛在問題的。對于剛剛的例子來說，在做快照的 20s 時間里，如果這 4GB 的數據都不能被修改，Redis 就不能處理對這些數據的寫操作，那無疑就會給業務服務造成巨大的影響。
你可能會想到，可以用 bgsave 避免阻塞啊。這里我就要說到一個常見的誤區了，避免阻塞和正常處理寫操作并不是一回事。此時，主線程的確沒有阻塞，可以正常接收請求，但是，為了保證快照完整性，它只能處理讀操作，因為不能修改正在執行快照的數據。
為了快照而暫停寫操作，肯定是不能接受的。所以這個時候，Redis 就會借助操作系統提供的寫時復制技術（Copy-On-Write, COW），在執行快照的同時，正常處理寫操作
簡單來說，bgsave 子進程是由主線程 fork 生成的，可以共享主線程的所有內存數據。bgsave 子進程運行后，開始讀取主線程的內存數據，并把它們寫入 RDB 文件。
此時，如果主線程對這些數據也都是讀操作（例如圖中的鍵值對 A），那么，主線程和 bgsave 子進程相互不影響。但是，如果主線程要修改一塊數據（例如圖中的鍵值對 C），那么，這塊數據就會被復制一份，生成該數據的副本。然后，bgsave 子進程會把這個副本數據寫入 RDB 文件，而在這個過程中，主線程仍然可以直接修改原來的數據。
這既保證了快照的完整性，也允許主線程同時對數據進行修改，避免了對正常業務的影響。
到這里，我們就解決了對“哪些數據做快照”以及“做快照時數據能否修改”這兩大問題：Redis 會使用 bgsave 對當前內存中的所有數據做快照，這個操作是子進程在后臺完成的，這就允許主線程同時可以修改數據。
現在，我們再來看另一個問題：多久做一次快照？我們在拍照的時候，還有項技術叫“連拍”，可以記錄人或物連續多個瞬間的狀態。那么，快照也適合“連拍”嗎？
可以每秒做一次快照嗎？
對于快照來說，所謂“連拍”就是指連續地做快照。這樣一來，快照的間隔時間變得很短，即使某一時刻發生宕機了，因為上一時刻快照剛執行，丟失的數據也不會太多。但是，這其中的快照間隔時間就很關鍵了。
如下圖所示，我們先在 T0 時刻做了一次快照，然后又在 T0+t 時刻做了一次快照，在這期間，數據塊 5 和 9 被修改了。如果在 t 這段時間內，機器宕機了，那么，只能按照 T0 時刻的快照進行恢復。此時，數據塊 5 和 9 的修改值因為沒有快照記錄，就無法恢復了。
所以，要想盡可能恢復數據，t 值就要盡可能小，t 越小，就越像“連拍”。那么，t 值可以小到什么程度呢，比如說是不是可以每秒做一次快照？畢竟，每次快照都是由 bgsave 子進程在后臺執行，也不會阻塞主線程。
這種想法其實是錯誤的。雖然 bgsave 執行時不阻塞主線程，但是，如果頻繁地執行全量快照，也會帶來兩方面的開銷。
一方面，頻繁將全量數據寫入磁盤，會給磁盤帶來很大壓力，多個快照競爭有限的磁盤帶寬，前一個快照還沒有做完，后一個又開始做了，容易造成惡性循環。
另一方面，bgsave 子進程需要通過 fork 操作從主線程創建出來。雖然，子進程在創建后不會再阻塞主線程，但是，fork 這個創建過程本身會阻塞主線程，而且主線程的內存越大，阻塞時間越長。如果頻繁 fork 出 bgsave 子進程，這就會頻繁阻塞主線程了。那么，有什么其他好方法嗎？
如果我們對每一個鍵值對的修改，都做個記錄，那么，如果有 1 萬個被修改的鍵值對，我們就需要有 1 萬條額外的記錄。而且，有的時候，鍵值對非常小，比如只有 32 字節，而記錄它被修改的元數據信息，可能就需要 8 字節，這樣的畫，為了“記住”修改，引入的額外空間開銷比較大。這對于內存資源寶貴的 Redis 來說，有些得不償失。
到這里，你可以發現，雖然跟 AOF 相比，快照的恢復速度快，但是，快照的頻率不好把握，如果頻率太低，兩次快照間一旦宕機，就可能有比較多的數據丟失。如果頻率太高，又會產生額外開銷，那么，還有什么方法既能利用 RDB 的快速恢復，又能以較小的開銷做到盡量少丟數據呢？Redis 4.0 中提出了一個混合使用 AOF 日志和內存快照的方法。
簡單來說，內存快照以一定的頻率執行，在兩次快照之間，使用 AOF 日志記錄這期間的所有命令操作。這樣一來，快照不用很頻繁地執行，這就避免了頻繁 fork 對主線程的影響。而且，AOF 日志也只用記錄兩次快照間的操作，也就是說，不需要記錄所有操作了，因此，就不會出現文件過大的情況了，也可以避免重寫開銷。如下圖所示，T1 和 T2 時刻的修改，用 AOF 日志記錄，等到第二次做全量快照時，就可以清空 AOF 日志，因為此時的修改都已經記錄到快照中了，恢復時就不再用日志了。
這個方法既能享受到 RDB 文件快速恢復的好處，又能享受到 AOF 只記錄操作命令的簡單優勢，頗有點“魚和熊掌可以兼得”的感覺，建議你在實踐中用起來。
