目錄

•  前言
•  什么是AOF？
  •  三種寫回策略
  •  日志文件太大怎么辦？
  •  AOF重寫會阻塞主線程嗎？
  •  AOF的缺點
  •  總結
•  什么是RDB？
  •  給哪些數據做快照？
  •  快照時能夠修改數據嗎？
  •  多久做一次快照？
  •  增量快照
  •  AOF和RDB混合使用
  •  總結
•  總結

前言

Redis作為內存型的數據庫，雖然很快，依然有著很大的隱患，一旦「服務器宕機」重啟，內存中數據還會存在嗎？

很容易想到的一個方案是從后臺數據恢復這些數據，如果數據量很小，這倒是一個可行的方案。但是如果數據量過大，頻繁的從后臺數據庫訪問數據，壓力很大；另外一方面恢復數據的時間極慢。

對于Redis來說，實現數據的持久化和快速恢復是至關重要。

今天這篇文章就來介紹一下Redis持久化的兩種機制AOF日志、RDB快照。 

什么是 AOF 日志？

AOF(Append Only File)日志稱之為「寫后日志」，即是命令先執行完成，把數據寫入內存，然后才會記錄日志。

AOF日志（文本形式）會將收到每一條的命令且執行成功的命令以一定的格式寫入到文本中（追加的方式）。

「寫后日志有什么好處呢？」 如下：

1.  對于寫前日志無論命令是否執行成功都會被記錄，但是Redis的寫后日志則只有命令執行成功才會被寫入日志，避免了日志中存在錯誤命令；
2.  同時由于是命令執行成功之后才會寫入日志，因此不會阻塞當前命令的執行。

但是AOF日志也有「潛在的風險」，分析如下：

     1.  由于是寫后日志，如果在命令執行成功之后，在日志未寫入磁盤之前服務器突然宕機，那重啟恢復數據的時候，這部分的數據肯定在日志文件中不存在了，那么將會丟失。（無法通過后臺數據庫恢復的情況下）

    2.  雖然不會阻塞當前命令的執行，由于記錄日志也是在主線程中（Redis是單線程），如果日志寫入磁盤的時候突然阻塞了，肯定會影響下一個命令的執行。

為了解決上面的風險，AOF日志提供了三種回寫策略。

三種寫回策略

AOF機制提供了三種回寫策略，這些都在appendfsync配置，如下：

1.  Always（同步寫回）：命令執行完成，立馬同步的將日志寫入磁盤
2.  Everysec（每秒寫回）：命令執行完成后，先將日志寫入 AOF 文件的內存緩沖區，每隔一秒把緩沖區中內容寫入磁盤。
3.  No(操作系統控制的寫回)：每個寫命令執行完，只是先把日志寫到AOF文件的內存緩沖區，由操作系統決定何時將緩沖區內容寫回磁盤。

其實這三中寫回策略都無法解決主線程的阻塞和數據丟失的問題，分析如下：

1.  同步寫回：基本不丟失數據，但是每步操作都會有一個慢速的落盤操作，不可避免的影響主線程性能。
2.  每秒寫回：采用一秒寫一次到 AOF 日志文件中，但是一旦宕機還是會丟失一秒的數據。
3.  操作系統控制的寫回：在寫完緩沖區之后則會寫入磁盤，但是數據始終在緩沖區的時間內一旦宕機，數據還是會丟失。

以上三種策略優缺點總結如下表：

日志文件太大怎么辦？

隨著數據量的增大，AOF日志文件難免會很大，這樣將會導致寫入和恢復數據都將變得非常慢。此時AOF提供了一種「重寫機制」解決這一問題。

❝重寫機制理解起來很簡單，即是Redis會創建一個新的AOF日志文件，將每個鍵值對最終的值用一條命令寫入日志文件中。

比如讀取了鍵值對key1:value1，重寫機制會在新的AOF日志文件中記錄如下一條命令： 

set key1 value1 

其實即是記錄多次修改的最終的值記錄在新的AOF日志文件中，這樣當恢復數據時可直接執行該命令。

「為什么重寫機制能夠縮小文件呢？」 當一個鍵值被多次修改后，AOF日志文件中將會記錄多次修改鍵值的命令，重寫機制是根據這個鍵值最新狀態為它生成「寫入」命令，這樣舊文件中的「多條」命令在重寫后的新日志中變成了「一條」命令。

作者畫了一張重寫流程圖，僅供參考，如下：

重寫機制流程

AOF重寫會阻塞主線程嗎？

AOF重寫雖然能夠縮減日志文件的大小，達到減少日志記錄和數據恢復的時間，但是在數據量非常的大情況下把整個數據庫重寫后的日志寫入磁盤是一個非常耗時的過程，難道不會阻塞主線程嗎？

「答案是：不會阻塞主線程」；因為AOF重寫過程是由后臺子進程bgrewriteaof來完成的，這也是為了避免阻塞主線程，導致數據庫性能下降。

其實重寫的過程分為兩個階段：「一個拷貝，兩處日志」。

「一個拷貝」：指每次執行重寫時，主線程都fork一個子線程bgrewriteaof，主線程會把內存數據拷貝一份到子線程，此時子線程中包含了數據庫的最新數據。然后子線程就能在不影響主線程的情況下進行AOF重寫了。

「兩處日志」是什么？如下：

1.  第一處日志：子線程重寫并未阻塞主線程，此時主線程仍然會處理請求，此時的AOF日志仍然正在記錄著，這樣即使宕機了，數據也是齊全的。第一處日志即是值主線程正在使用的日志。
2.  第二處日志：指新的AOF重寫日志；重寫過程中的操作也會被寫到重寫日志緩沖區，這樣重寫日志也不會丟失最新的操作。等到拷貝數據的所有操作記錄重寫完成后，重寫日志記錄的這些最新操作也會寫入新的 AOF 文件，以保證數據庫最新狀態的記錄。此時，我們就可以用新的 AOF 文件替代舊文件了。

❝「總結」：Redis在進行AOF重寫時，會fork一個子線程（不會阻塞主線程）并進行內存拷貝用于重寫，然后使用兩個日志保證重寫過程中，新寫入的數據不會丟失。

AOF的缺點

雖說進行了日志重寫后，AOF日志文件會縮減很多，但是在數據恢復過程中仍然是一條命令一條命令（由于單線程，只能順序執行）的執行恢復數據，這個恢復的過程非常緩慢。

總結

AOF這種通過逐一記錄操作命令的日志方式，提供了三種寫回策略保證數據的可靠性，分別是Always、Everysec和No，這三種策略在可靠性上是從高到低，而在性能上則是從低到高。

為了避免日志文件過大，Redis提供了重寫的機制，每次重寫都fork一個子線程，拷貝內存數據進行重寫，將多條命令縮減成一條生成鍵值對的命令，最終重寫的日志作為新的日志。

什么是RDB？

RDB(Redis DataBase)是另外一種持久化方式：內存快照。

❝RDB記錄的是「某一個時刻」的內存數據，并不是操作命令。

這種方式類似于拍照，只保留某一時刻的形象。內存快照是將某一時刻的狀態以文件的形式寫入磁盤。這樣即使宕機了，數據也不會丟失，這個快照文件就稱為RDB文件。

❝由于記錄的是某個時刻的內存數據，數據恢復非常快的，不需要像AOF日志逐一執行記錄的命令。

給哪些數據做快照？

為了保證數據的可靠性，Redis執行的「全量快照」，也就是把內存中的所有數據都寫到磁盤中。

隨著數據量的增大，一次性把全部數據都寫到磁盤中勢必會造成線程阻塞，這就關系到Redis的性能了。

針對線程阻塞的問題Redis提供了兩個命令，如下：

1.  save：在主線程中執行，會導致主線程阻塞。
2.  bgsave：fork一個子進程，專門用于寫入RDB文件，避免了主線程的阻塞，這是Redis的默認配置。

這樣就可以使用bgsave命令執行全量快照，既可以保證數據的可靠性也避免了主線程的阻塞。

快照時能夠修改數據嗎？

子線程執行全量快照的同時，主線程仍然在接受著請求，讀數據肯定沒有問題，但是如果個修改了數據，如何能夠保證快照的完整性呢？

「舉個栗子」：我在T時刻進行全量快照，假設數據量有8G，寫入磁盤的過程至少需要20S，在這20S的時間內，一旦內存中的數據發生了修改，則快照的完整性就破壞了。

但是如果在快照時不能修改數據，則對Redis的性能有巨大的影響，對于這個問題，Redis是如何解決的呢？

❝Redis借助操作系統提供的寫時復制技術（Copy-On-Write, COW），在執行快照的同時，正常處理寫操作。

其實很簡單，bgsave命令會fork一個子線程，這個子線程共享所有內存的數據，子線程會讀取主線程內存中的數據，將他們寫入RDB文件。

寫時復制保證數據可修改

如上圖，對于鍵值對A的讀取并不會影響子線程，但是如果主線程一旦修改內存中一塊數據（例如鍵值對D），這塊數據將會被復制一個副本，然后bgsave子線程會將其寫入RDB文件。

多久做一次快照？

快照只是記錄某一時刻的數據，一旦時間隔離很久，則服務器一旦宕機，則會丟失那段時間的數據。

比如在T1時間做了一次快照，在T1+t時又做了一次快照，如果在t這個時間段內服務器突然宕機了，則快照中只保存了T1時刻的快照，在t時間段內的數據修改未被記錄（丟失）。如下圖：

t時刻宕機，未執行快照

從上圖明顯可以看出，「RDB并不是一個完美的日志記錄方案」，只有讓t時間逐漸縮小，才能保證丟失的數據縮小。

「那么問題來了，時間能夠縮短1秒嗎？」 即是每秒執行一次快照。

❝全量快照是記錄某一個時刻的「全部」內存數據，每秒執行一次的對Redis性能影響巨大，于是「增量快照」就出來了。

增量快照

「增量快照是指做了一次全量快照之后，后續的快照只對修改的數據進行快照記錄」，這樣可以避免每次都全量快照的開銷。

增量快照的前提是Redis能夠記住修改的數據，這個功能其實開銷也是巨大的，需要保存完整的鍵值對，這對內存的消耗是巨大的。

❝為了解決這個問題，Redis使用了AOF和RDB混合使用的方式。

AOF和RDB混合使用

這個概念是在Redis4.0提出的，簡單的說就是「內存快照以一定的頻率執行，比如1小時一次，在兩次快照之間，使用AOF日志記錄這期間的所有命令操作。」

❝混合使用的方式使得內存快照不必頻繁的執行，并且AOF記錄的也不是全部的操作命令，而是兩次快照之間的操作命令，不會出現AOF日志文件過大的情況了，避免了AOF重寫的開銷了。

這個方案既能夠用到的RDB的快速恢復的好處，又能享受都只記錄操作命令的簡單優勢，強烈建議使用。

總結

RDB內存快照記錄的是某一個時刻的內存數據，因此能夠快速恢復；AOF和RDB混合使用能夠使得宕機后數據快速恢復，又能夠避免AOF日志文件過大。 

總結

本文介紹了兩種數據恢復和持久化的方案，分別是AOF和RDB。

AOF介紹了什么？如下：

    1.  AOF是寫后日志，通過記錄操作命令持久化數據。

    2.  由于AOF是在命令執行之后記錄日志，如果在寫入磁盤之前服務器宕機，則會丟失數據；如果寫入磁盤的時候突然阻塞，則會阻塞主線程；為了解決以上問題，AOF機制提供了三種寫回的策略，每種策略都有不同的優缺點。

    3.  AOF日志文件過大怎么辦？AOF通過fork一個子線程重寫一個新的日志文件（共享主線程的內存，記錄最新數據的寫入命令），同時子線程重寫，避免阻塞主線程。

RDB介紹了什么？如下：

1.  RDB是內存快照，記錄某一個時刻的內存數據，而不是操作命令。
2.  Redis提供了兩個命令，分別是save、bgsave來執行全量快照，這兩個命令的區別則是save是在主線程執行，勢必會阻塞主線程，bgsave是在fork一個子線程，共享內存。
3.  RDB通過操作系統的「寫時復制技術」，能夠保證在執行快照的同時主線程能夠修改快照。
4.  由于兩次快照之間是存在間隔的，一旦服務器宕機，則會丟失兩次間隔時刻的數據，Redis4.0開始使用AOF日志記錄兩次快照之間執行的命令（AOF和RDB混合使用）。