redis是一個記憶體資料庫，一旦伺服器當機，記憶體中的資料將全部丟失。所以，對 Redis 來說，實現資料的持久化，避免從後端資料庫中進行恢復，是至關重要的。
目前，Redis 的持久化主要有兩大機制，即 AOF（Append Only File）日誌和 RDB 快照。
一、AOF日誌的實現
我們知道資料庫的寫前日誌（Write Ahead Log, WAL）是在在實際寫資料前，先把修改的資料記到日誌檔案中，以便故障時進行恢復。不過，AOF 日誌正好相反，它是寫後日志，“寫後”的意思是 Redis 是先執行命令，把資料寫入記憶體，然後才記錄日誌，如下圖所示：
那 AOF 為什麼要先執行命令再記日誌呢？
傳統資料庫的日誌，例如 redo log（重做日誌），記錄的是修改後的資料，而 AOF 裡記錄的是 Redis 收到的每一條命令，這些命令是以文字形式儲存的。我們以 Redis 收到“set testkey testvalue”命令後記錄的日誌為例，看看 AOF 日誌的內容。其中，“*3”表示當前命令有三個部分，每部分都是由“$+數字”開頭，後面緊跟著具體的命令、鍵或值。這裡，“數字”表示這部分中的命令、鍵或值一共有多少位元組。例如，“$3 set”表示這部分有 3 個位元組，也就是“set”命令。
但是，為了避免額外的檢查開銷，Redis 在向 AOF 裡面記錄日誌的時候，並不會先去對這些命令進行語法檢查。所以，如果先記日誌再執行命令的話，日誌中就有可能記錄了錯誤的命令，Redis 在使用日誌恢復資料時，就可能會出錯。
而寫後日志這種方式，就是先讓系統執行命令，只有命令能執行成功，才會被記錄到日誌中，否則，系統就會直接向客戶端報錯。所以，Redis 使用寫後日志這一方式的一大好處是，可以避免出現記錄錯誤命令的情況。除此之外，AOF 還有一個好處：它是在命令執行後才記錄日誌，所以不會阻塞當前的寫操作。
AOF 也有兩個潛在的風險：
首先，如果剛執行完一個命令，還沒有來得及記日誌就當機了，那麼這個命令和相應的資料就有丟失的風險。如果此時 Redis 是用作快取，還可以從後端資料庫重新讀入資料進行恢復，但是，如果 Redis 是直接用作資料庫的話，此時，因為命令沒有記入日誌，所以就無法用日誌進行恢復了。
其次，AOF 雖然避免了對當前命令的阻塞，但可能會給下一個操作帶來阻塞風險。這是因為，AOF 日誌也是在主執行緒中執行的，如果在把日誌檔案寫入磁碟時，磁碟寫壓力大，就會導致寫盤很慢，進而導致後續的操作也無法執行了。
這兩個風險都是和 AOF 寫回磁碟的時機相關的。這也就意味著，如果我們能夠控制一個寫命令執行完後 AOF 日誌寫回磁碟的時機，這兩個風險就解除了。
AOF的回寫策略
AOF 機制給我們提供了三個選擇，也就是 AOF 配置項 appendfsync 的三個可選值。
Always，同步寫回：每個寫命令執行完，立馬同步地將日誌寫回磁碟；
Everysec，每秒寫回：每個寫命令執行完，只是先把日誌寫到 AOF 檔案的記憶體緩衝區，每隔一秒把緩衝區中的內容寫入磁碟；
No，作業系統控制的寫回：每個寫命令執行完，只是先把日誌寫到 AOF 檔案的記憶體緩衝區，由作業系統決定何時將緩衝區內容寫回磁碟。
針對避免主執行緒阻塞和減少資料丟失問題，這三種寫回策略都無法做到兩全其美。我們來分析下其中的原因。
“同步寫回”可以做到基本不丟資料，但是它在每一個寫命令後都有一個慢速的落盤操作，不可避免地會影響主執行緒效能；
雖然“作業系統控制的寫回”在寫完緩衝區後，就可以繼續執行後續的命令，但是落盤的時機已經不在 Redis 手中了，只要 AOF 記錄沒有寫回磁碟，一旦當機對應的資料就丟失了；
“每秒寫回”採用一秒寫回一次的頻率，避免了“同步寫回”的效能開銷，雖然減少了對系統效能的影響，但是如果發生當機，上一秒內未落盤的命令操作仍然會丟失。所以，這隻能算是，在避免影響主執行緒效能和避免資料丟失兩者間取了個折中。
總結一下就是：想要獲得高效能，就選擇 No 策略；如果想要得到高可靠性保證，就選擇 Always 策略；如果允許資料有一點丟失，又希望效能別受太大影響的話，那麼就選擇 Everysec 策略。
按照系統的效能需求選定了寫回策略，並不是“高枕無憂”了。畢竟，AOF 是以檔案的形式在記錄接收到的所有寫命令。隨著接收的寫命令越來越多，AOF 檔案會越來越大。這也就意味著，我們一定要小心 AOF 檔案過大帶來的效能問題。
這裡的“效能問題”，主要在於以下三個方面：
一是，檔案系統本身對檔案大小有限制，無法儲存過大的檔案；
二是，如果檔案太大，之後再往裡面追加命令記錄的話，效率也會變低；
三是，如果發生當機，AOF 中記錄的命令要一個個被重新執行，用於故障恢復，如果日誌檔案太大，整個恢復過程就會非常緩慢，這就會影響到 Redis 的正常使用。
因此我們需要AOF重寫機制
簡單來說，AOF 重寫機制就是在重寫時，Redis 根據資料庫的現狀建立一個新的 AOF 檔案，也就是說，讀取資料庫中的所有鍵值對，然後對每一個鍵值對用一條命令記錄它的寫入。
為什麼重寫機制可以把日誌檔案變小呢?
實際上，重寫機制具有“多變一”功能。所謂的“多變一”，也就是說，舊日誌檔案中的多條命令，在重寫後的新日誌中變成了一條命令。
AOF 檔案是以追加的方式，逐一記錄接收到的寫命令的。當一個鍵值對被多條寫命令反覆修改時，AOF 檔案會記錄相應的多條命令。但是，在重寫的時候，是根據這個鍵值對當前的最新狀態，為它生成對應的寫入命令。這樣一來，一個鍵值對在重寫日誌中只用一條命令就行了，而且，在日誌恢復時，只用執行這條命令，就可以直接完成這個鍵值對的寫入了。
下面這張圖就是一個例子：
當我們對一個列表先後做了 6 次修改操作後，列表的最後狀態是[“D”, “C”, “N”]，此時，只用 LPUSH u:list “N”, “C”, "D"這一條命令就能實現該資料的恢復，這就節省了五條命令的空間。對於被修改過成百上千次的鍵值對來說，重寫能節省的空間當然就更大了。
不過，雖然 AOF 重寫後，日誌檔案會縮小，但是，要把整個資料庫的最新資料的操作日誌都寫回磁碟，仍然是一個非常耗時的過程。這時，我們就要繼續關注另一個問題了：重寫會不會阻塞主執行緒？
AOF 重寫會阻塞嗎?
和 AOF 日誌由主執行緒寫回不同，重寫過程是由後臺子程式 bgrewriteaof 來完成的，這也是為了避免阻塞主執行緒，導致資料庫效能下降。
我把重寫的過程總結為“一個拷貝，兩處日誌”。
“一個拷貝”就是指，每次執行重寫時，主執行緒 fork 出後臺的 bgrewriteaof 子程式。此時，fork 會把主執行緒的記憶體拷貝一份給 bgrewriteaof 子程式，這裡面就包含了資料庫的最新資料。然後，bgrewriteaof 子程式就可以在不影響主執行緒的情況下，逐一把拷貝的資料寫成操作，記入重寫日誌。
“兩處日誌”又是什麼呢？
因為主執行緒未阻塞，仍然可以處理新來的操作。此時，如果有寫操作，第一處日誌就是指正在使用的 AOF 日誌，Redis 會把這個操作寫到它的緩衝區。這樣一來，即使當機了，這個 AOF 日誌的操作仍然是齊全的，可以用於恢復。
而第二處日誌，就是指新的 AOF 重寫日誌。這個操作也會被寫到重寫日誌的緩衝區。這樣，重寫日誌也不會丟失最新的操作。等到拷貝資料的所有操作記錄重寫完成後，重寫日誌記錄的這些最新操作也會寫入新的 AOF 檔案，以保證資料庫最新狀態的記錄。此時，我們就可以用新的 AOF 檔案替代舊檔案了。
總結來說，每次 AOF 重寫時，Redis 會先執行一個記憶體拷貝，用於重寫；然後，使用兩個日誌保證在重寫過程中，新寫入的資料不會丟失。而且，因為 Redis 採用額外的執行緒進行資料重寫，所以，這個過程並不會阻塞主執行緒。
AOF 日誌重寫的時候，是由 bgrewriteaof 子程式來完成的，不用主執行緒參與，我們今天說的非阻塞也是指子程式的執行不阻塞主執行緒。但是，你覺得，這個重寫過程有沒有其他潛在的阻塞風險呢？如果有的話，會在哪裡阻塞？
1.fork子程式，fork這個瞬間一定是會阻塞主執行緒的（注意，fork時並不會一次性拷貝所有記憶體資料給子程式），fork採用作業系統提供的寫實複製(Copy On Write)機制，就是為了避免一次性拷貝大量記憶體資料給子程式造成的長時間阻塞問題，但fork子程式需要拷貝程式必要的資料結構，其中有一項就是拷貝記憶體頁表（虛擬記憶體和實體記憶體的對映索引表），這個拷貝過程會消耗大量CPU資源，拷貝完成之前整個程式是會阻塞的，阻塞時間取決於整個例項的記憶體大小，例項越大，記憶體頁表越大，fork阻塞時間越久。拷貝記憶體頁表完成後，子程式與父程式指向相同的記憶體地址空間，也就是說此時雖然產生了子程式，但是並沒有申請與父程式相同的記憶體大小。那什麼時候父子程式才會真正記憶體分離呢？“寫實複製”顧名思義，就是在寫發生時，才真正拷貝記憶體真正的資料，這個過程中，父程式也可能會產生阻塞的風險，就是下面介紹的場景。
2.fork出的子程式指向與父程式相同的記憶體地址空間，此時子程式就可以執行AOF重寫，把記憶體中的所有資料寫入到AOF檔案中。但是此時父程式依舊是會有流量寫入的，如果父程式操作的是一個已經存在的key，那麼這個時候父程式就會真正拷貝這個key對應的記憶體資料，申請新的記憶體空間，這樣逐漸地，父子程式記憶體資料開始分離，父子程式逐漸擁有各自獨立的記憶體空間。因為記憶體分配是以頁為單位進行分配的，預設4k，如果父程式此時操作的是一個bigkey，重新申請大塊記憶體耗時會變長，可能會產阻塞風險。另外，如果作業系統開啟了記憶體大頁機制(Huge Page，頁面大小2M)，那麼父程式申請記憶體時阻塞的概率將會大大提高，所以在Redis機器上需要關閉Huge Page機制。Redis每次fork生成RDB或AOF重寫完成後，都可以在Redis log中看到父程式重新申請了多大的記憶體空間。
AOF 重寫也有一個重寫日誌，為什麼它不共享使用 AOF 本身的日誌呢？
AOF重寫不復用AOF本身的日誌，一個原因是父子程式寫同一個檔案必然會產生競爭問題，控制競爭就意味著會影響父程式的效能。二是如果AOF重寫過程中失敗了，那麼原本的AOF檔案相當於被汙染了，無法做恢復使用。所以Redis AOF重寫一個新檔案，重寫失敗的話，直接刪除這個檔案就好了，不會對原先的AOF檔案產生影響。等重寫完成之後，直接替換舊檔案即可。
二、RDB記憶體快照
所謂記憶體快照，就是指記憶體中的資料在某一個時刻的狀態記錄。這就類似於照片，當你給朋友拍照時，一張照片就能把朋友一瞬間的形象完全記下來。
對 Redis 來說，它實現類似照片記錄效果的方式，就是把某一時刻的狀態以檔案的形式寫到磁碟上，也就是快照。這樣一來，即使當機，快照檔案也不會丟失，資料的可靠性也就得到了保證。這個快照檔案就稱為 RDB 檔案，其中，RDB 就是 Redis DataBase 的縮寫。
和 AOF 相比，RDB 記錄的是某一時刻的資料，並不是操作，所以，在做資料恢復時，我們可以直接把 RDB 檔案讀入記憶體，很快地完成恢復。聽起來好像很不錯，但記憶體快照也並不是最優選項。為什麼這麼說呢？
我們還要考慮兩個關鍵問題：
對哪些資料做快照？這關係到快照的執行效率問題；
做快照時，資料還能被增刪改嗎？這關係到 Redis 是否被阻塞，能否同時正常處理請求。
對哪些資料做快照？
Redis 的資料都在記憶體中，為了提供所有資料的可靠性保證，它執行的是全量快照，也就是說，把記憶體中的所有資料都記錄到磁碟中，這樣做的好處是，一次性記錄了所有資料，一個都不少。
給記憶體的全量資料做快照，把它們全部寫入磁碟也會花費很多時間。而且，全量資料越多，RDB 檔案就越大，往磁碟上寫資料的時間開銷就越大。
對於 Redis 而言，它的單執行緒模型就決定了，我們要儘量避免所有會阻塞主執行緒的操作，所以，針對任何操作，我們都會提一個靈魂之問：“它會阻塞主執行緒嗎?”RDB 檔案的生成是否會阻塞主執行緒，這就關係到是否會降低 Redis 的效能。
Redis 提供了兩個命令來生成 RDB 檔案，分別是 save 和 bgsave。
save：在主執行緒中執行，會導致阻塞；
bgsave：建立一個子程式，專門用於寫入 RDB 檔案，避免了主執行緒的阻塞，這也是 Redis RDB 檔案生成的預設配置。
好了，這個時候，我們就可以通過 bgsave 命令來執行全量快照，這既提供了資料的可靠性保證，也避免了對 Redis 的效能影響。
快照期間，是否可以對資料進行改動？
舉個例子。我們在時刻 t 給記憶體做快照，假設記憶體資料量是 4GB，磁碟的寫入頻寬是 0.2GB/s，簡單來說，至少需要 20s（4/0.2 = 20）才能做完。如果在時刻 t+5s 時，一個還沒有被寫入磁碟的記憶體資料 A，被修改成了 A’，那麼就會破壞快照的完整性，因為 A’不是時刻 t 時的狀態。因此，和拍照類似，我們在做快照時也不希望資料“動”，也就是不能被修改。
如果快照執行期間資料不能被修改，是會有潛在問題的。對於剛剛的例子來說，在做快照的 20s 時間裡，如果這 4GB 的資料都不能被修改，Redis 就不能處理對這些資料的寫操作，那無疑就會給業務服務造成巨大的影響。
為了快照而暫停寫操作，肯定是不能接受的。所以這個時候，Redis 就會藉助作業系統提供的寫時複製技術（Copy-On-Write, COW），在執行快照的同時，正常處理寫操作。
簡單來說，bgsave 子程式是由主執行緒 fork 生成的，可以共享主執行緒的所有記憶體資料。bgsave 子程式執行後，開始讀取主執行緒的記憶體資料，並把它們寫入 RDB 檔案。
此時，如果主執行緒對這些資料也都是讀操作（例如圖中的鍵值對 A），那麼，主執行緒和 bgsave 子程式相互不影響。但是，如果主執行緒要修改一塊資料（例如圖中的鍵值對 C），那麼，這塊資料就會被複制一份，生成該資料的副本（鍵值對 C’）。然後，主執行緒在這個資料副本上進行修改。同時，bgsave 子程式可以繼續把原來的資料（鍵值對 C）寫入 RDB 檔案。
這既保證了快照的完整性，也允許主執行緒同時對資料進行修改，避免了對正常業務的影響。到這裡，我們就解決了對“哪些資料做快照”以及“做快照時資料能否修改”這兩大問題：Redis 會使用 bgsave 對當前記憶體中的所有資料做快照，這個操作是子程式在後臺完成的，這就允許主執行緒同時可以修改資料。
如果頻繁地執行全量快照，也會帶來兩方面的開銷。
一方面，頻繁將全量資料寫入磁碟，會給磁碟帶來很大壓力，多個快照競爭有限的磁碟頻寬，前一個快照還沒有做完，後一個又開始做了，容易造成惡性迴圈。
另一方面，bgsave 子程式需要通過 fork 操作從主執行緒建立出來。雖然，子程式在建立後不會再阻塞主執行緒，但是，fork 這個建立過程本身會阻塞主執行緒，而且主執行緒的記憶體越大，阻塞時間越長。如果頻繁 fork 出 bgsave 子程式，這就會頻繁阻塞主執行緒了（所以，在 Redis 中如果有一個 bgsave 在執行，就不會再啟動第二個 bgsave 子程式）。那麼，有什麼其他好方法嗎？
此時，我們可以做增量快照，所謂增量快照，就是指，做了一次全量快照後，後續的快照只對修改的資料進行快照記錄，這樣可以避免每次全量快照的開銷。
在第一次做完全量快照後，T1 和 T2 時刻如果再做快照，我們只需要將被修改的資料寫入快照檔案就行。但是，這麼做的前提是，我們需要記住哪些資料被修改了。你可不要小瞧這個“記住”功能，它需要我們使用額外的後設資料資訊去記錄哪些資料被修改了，這會帶來額外的空間開銷問題。如下圖所示：
如果我們對每一個鍵值對的修改，都做個記錄，那麼，如果有 1 萬個被修改的鍵值對，我們就需要有 1 萬條額外的記錄。而且，有的時候，鍵值對非常小，比如只有 32 位元組，而記錄它被修改的後設資料資訊，可能就需要 8 位元組，這樣的畫，為了“記住”修改，引入的額外空間開銷比較大。這對於記憶體資源寶貴的 Redis 來說，有些得不償失。
到這裡，你可以發現，雖然跟 AOF 相比，快照的恢復速度快，但是，快照的頻率不好把握，如果頻率太低，兩次快照間一旦當機，就可能有比較多的資料丟失。如果頻率太高，又會產生額外開銷，那麼，還有什麼方法既能利用 RDB 的快速恢復，又能以較小的開銷做到儘量少丟資料呢？
Redis 4.0 中提出了一個混合使用 AOF 日誌和記憶體快照的方法。
簡單來說，記憶體快照以一定的頻率執行，在兩次快照之間，使用 AOF 日誌記錄這期間的所有命令操作。這樣一來，快照不用很頻繁地執行，這就避免了頻繁 fork 對主執行緒的影響。而且，AOF 日誌也只用記錄兩次快照間的操作，也就是說，不需要記錄所有操作了，因此，就不會出現檔案過大的情況了，也可以避免重寫開銷。
如下圖所示，T1 和 T2 時刻的修改，用 AOF 日誌記錄，等到第二次做全量快照時，就可以清空 AOF 日誌，因為此時的修改都已經記錄到快照中了，恢復時就不再用日誌了。
這個方法既能享受到 RDB 檔案快速恢復的好處，又能享受到 AOF 只記錄操作命令的簡單優勢，頗有點“魚和熊掌可以兼得”的感覺，建議你在實踐中用起來。
場景：我們使用一個 2 核 CPU、4GB 記憶體、500GB 磁碟的雲主機執行 Redis，Redis 資料庫的資料量大小差不多是 2GB，我們使用了 RDB 做持久化保證。當時 Redis 的執行負載以修改操作為主，寫讀比例差不多在 8:2 左右，也就是說，如果有 100 個請求，80 個請求執行的是修改操作。你覺得，在這個場景下，用 RDB 做持久化有什麼風險嗎？
記憶體資源風險：Redis fork子程式做RDB持久化，由於寫的比例為80%，那麼在持久化過程中，“寫實複製”會重新分配整個例項80%的記憶體副本，大約需要重新分配1.6GB記憶體空間，這樣整個系統的記憶體使用接近飽和，如果此時父程式又有大量新key寫入，很快機器記憶體就會被吃光，如果機器開啟了Swap機制，那麼Redis會有一部分資料被換到磁碟上，當Redis訪問這部分在磁碟上的資料時，效能會急劇下降，已經達不到高效能的標準（可以理解為武功被廢）。如果機器沒有開啟Swap，會直接觸發OOM，父子程式會面臨被系統kill掉的風險。
CPU資源風險：雖然子程式在做RDB持久化，但生成RDB快照過程會消耗大量的CPU資源，雖然Redis處理處理請求是單執行緒的，但Redis Server還有其他執行緒在後臺工作，例如AOF每秒刷盤、非同步關閉檔案描述符這些操作。由於機器只有2核CPU，這也就意味著父程式佔用了超過一半的CPU資源，此時子程式做RDB持久化，可能會產生CPU競爭，導致的結果就是父程式處理請求延遲增大，子程式生成RDB快照的時間也會變長，整個Redis Server效能下降。
另外，可以再延伸一下，Redis程式是否繫結了CPU，如果繫結了CPU，那麼子程式會繼承父程式的CPU親和性屬性，子程式必然會與父程式爭奪同一個CPU資源，整個Redis Server的效能必然會受到影響！所以如果Redis需要開啟定時RDB和AOF重寫，程式一定不要繫結CPU。