Redis 數(shù)據(jù)存儲在內(nèi)存中，如果不想辦法將數(shù)據(jù)保存到硬盤上，一旦Redis重啟(退出/故障)，內(nèi)存的數(shù)據(jù)將會全部丟失。我們肯定不想 Redis 里的數(shù)據(jù)由于某些故障全部丟失(導(dǎo)致所有請求都走 MySQL)，即便發(fā)生了故障也希望可以將Redis原有的數(shù)據(jù)恢復(fù)過來，這就是持久化的作用。

Redis 提供了兩種不同的持久化方法來將數(shù)據(jù)存儲到硬盤里邊：

• **RDB(Redis Database)**，將某一時刻的所有數(shù)據(jù)保存到一個 RDB 文件中。
• **AOF(append-only-file)**，當(dāng)Redis服務(wù)器執(zhí)行寫命令的時候，將執(zhí)行的寫命令保存到 AOF 文件中。

RDB內(nèi)存快照，讓宕機快速恢復(fù)

1.什么是RDB內(nèi)存快照？

在 Redis 執(zhí)行“寫”指令的過程中，內(nèi)存數(shù)據(jù)一直會變化，所謂內(nèi)存快照，指的就是 Redis 內(nèi)存中數(shù)據(jù)在某一時刻的狀態(tài)數(shù)據(jù)，好比時間定格在某一時刻。當(dāng)我們拍照時，通過照片就能把某一時刻的瞬間畫面完全記錄下來。Redis 跟這個類似，就是把某一刻的數(shù)據(jù)以文件的形式拍下來，寫到磁盤上，這個快照文件叫做 RDB 文件，RDB 就是 Redis Database 的縮寫。

2.生成RDB的策略

Redis 并不會在每次執(zhí)行“寫”指令的時候都觸發(fā) RDB 寫磁盤，只需要在執(zhí)行內(nèi)存快照的時候?qū)懘疟P，這樣既保證了唯快不破，還實現(xiàn)了持久化，宕機快速恢復(fù)。

我們知道 Redis 的單線程模型決定了我們要盡可能地避免會阻塞主線程的操作，所以就需要盡可能地避免 RDB 文件生成阻塞主線程。為此Redis提供了兩個指令用于生成 RDB 文件：

• SAVE：會阻塞 Redis 服務(wù)器進程，服務(wù)器不能接收任何請求，直到 RDB 文件創(chuàng)建完畢為止。
• BGSAVE：fork 出一個子進程，由子進程來負責(zé)創(chuàng)建 RDB 文件，服務(wù)器進程可以繼續(xù)接收請求。

除了手動調(diào)用 SAVE 或者 BGSAVE 命令生成 RDB 文件之外，我們可以使用配置的方式來定期執(zhí)行：在默認的配置下，如果以下的條件被觸發(fā)，就會執(zhí)行 BGSAVE 命令。

save 900 1              #在900秒(15分鐘)之后，至少有1個key發(fā)生變化，
save 300 10             #在300秒(5分鐘)之后，至少有10個key發(fā)生變化
save 60 10000           #在60秒(1分鐘)之后，至少有10000個key發(fā)生變化

3.RDB實現(xiàn)原理

在RDB執(zhí)行期間為了保證快照的數(shù)據(jù)一致性，只能處理讀操作，不能修改正在執(zhí)行快照的數(shù)據(jù)，這種場景，Redis 是允許的。那 Redis 是如何實現(xiàn)一邊處理寫請求，同時生成RDB文件的呢？

Redis 使用操作系統(tǒng)的多進程寫時復(fù)制技術(shù) COW（Copy On Write）來實現(xiàn)快照的持久化。

Redis 在持久化是會調(diào)用 glibc 的函數(shù)（linux系統(tǒng)中最底層的api）fork產(chǎn)生一個子進程，快照持久化完全交給子進程來處理，父進程繼續(xù)處理客戶端請求。子進程剛剛產(chǎn)生時，它和父進程共享內(nèi)存里面的代碼段和數(shù)據(jù)段，這時可以將父子進程想象成一個連體嬰兒，共享身體。這是Linux操作系統(tǒng)的機制，為了節(jié)約內(nèi)存資源，所以盡可能讓它們共享起來，在進程分離的一瞬間，內(nèi)存的增長幾乎沒有明顯的變化。

BGSAVE 子進程可以共享主線程的所有內(nèi)存數(shù)據(jù)，讀取主線程的數(shù)據(jù)并寫入到 RDB 文件。當(dāng)主線程執(zhí)行寫指令修改數(shù)據(jù)的時候，這個數(shù)據(jù)就會復(fù)制一份副本，BGSAVE 子進程讀取這個副本數(shù)據(jù)寫到 RDB 文件。

在執(zhí)行 SAVE 或 BGSAVE 命令創(chuàng)建一個新的 RDB 文件時，程序會對數(shù)據(jù)庫中的鍵進行檢查，已過期的鍵不會被保存到新創(chuàng)建的RDB 文件中。這既保證了快照的完整性，也允許主線程同時對數(shù)據(jù)進行修改，避免了對正常業(yè)務(wù)的影響。

4.RDB的優(yōu)缺點

優(yōu)點

• RDB 文件是一個很簡潔的單文件，采用 二進制 + 數(shù)據(jù)壓縮 的方式寫磁盤，文件體積小，數(shù)據(jù)恢復(fù)速度快。
• RDB 的性能很好，需要進行持久化時，主進程會 fork 一個子進程出來，然后把持久化的工作交給子進程，自己不會有相關(guān)的I/O操作。

缺點

• RDB 容易造成數(shù)據(jù)的丟失。假設(shè)每5分鐘保存一次快照，如果 Redis 因為某些原因不能正常工作，那么從上次產(chǎn)生快照到 Redis 出現(xiàn)問題這段時間的數(shù)據(jù)就會丟失了。
• RDB 使用 fork() 產(chǎn)生子進程進行數(shù)據(jù)的持久化，會阻塞主線程，如果數(shù)據(jù)比較大的話可能就會花費點時間，造成 Redis 停止服務(wù)幾毫秒。如果數(shù)據(jù)量很大且CPU性能不是很好的時候，停止服務(wù)的時間甚至?xí)?秒。

另外，過于頻繁的執(zhí)行全量數(shù)據(jù)快照，有兩個嚴重的性能開銷：

• 頻繁生成 RDB 文件寫入磁盤，磁盤壓力過大。可能會出現(xiàn)上一個 RDB 還未完成，下一個又開始生成，陷入死循環(huán)。
• fork 出 BGSAVE 子進程這個動作本身會阻塞主線程，主線程的內(nèi)存越大，阻塞時間越長。

AOF寫后日志，避免宕機數(shù)據(jù)丟失

1.什么是AOF寫后日志？

AOF（Append Only File）寫后日志，AOF 持久化就是將修改數(shù)據(jù)庫狀態(tài)的命令保存到 AOF 文件中，被寫入的命令都是以 Redis 的命令請求協(xié)議格式保存的，Redis 的命令請求協(xié)議是純文本格式。

假設(shè) AOF 日志記錄了 Redis 實例創(chuàng)建以來所有的修改指令序列，那么就可以通過一個空的 Redis 實例順序執(zhí)行所有的指令，也就是“重放”，來恢復(fù)Redis當(dāng)前實例的內(nèi)存數(shù)據(jù)結(jié)構(gòu)的狀態(tài)。

寫后日志和寫前日志的對比

寫前日志（WAL，Write Ahead Log）：在實際寫數(shù)據(jù)之前，將修改的數(shù)據(jù)寫到日志文件中，故障恢復(fù)得以保證。比如 MySQL Innodb 存儲引擎中的 redo log（重做日志）便是記錄修改的數(shù)據(jù)日志，在實際修改數(shù)據(jù)前先記錄修改日志再執(zhí)行修改數(shù)據(jù)。

寫后日志：先執(zhí)行“寫”指令請求，將數(shù)據(jù)寫入內(nèi)存，再記錄日志。

日志格式

當(dāng) Redis 接收到 “set key value” 命令將數(shù)據(jù)寫入到內(nèi)存之后，會按照如下格式寫入 AOF 文件：

• *3：表示當(dāng)前指令分為三個部分，每部分都是 “$ + 數(shù)字” 開頭，緊跟后面是該部分具體的命令、鍵、值
• 數(shù)字：表示這部分的命令、鍵、值占用的字節(jié)大小。比如 “$3” 表示這部分包含三個字節(jié)，也就是 set 指令。

寫后日志的好處

寫后日志避免了額外的檢查開銷，不需要對執(zhí)行的命令進行語法檢查。如果使用寫前日志的話，就需要先檢查語法是否有誤，否則日志記錄了錯誤的命令，在使用日志恢復(fù)的時候就會報錯。另外，寫后記錄日志，避免了阻塞當(dāng)前“寫”指令的執(zhí)行。

2.寫回策略

使用 AOF 也不是萬無一失的，假如 Redis 剛執(zhí)行完指令，還沒記錄日志就宕機了，就有可能丟失這個命令的相關(guān)數(shù)據(jù)；還有， AOF 避免了當(dāng)前命令的阻塞，但是可能會給下一個命令帶來阻塞的風(fēng)險。AOF 日志是主線程執(zhí)行的，將日志寫入磁盤過程中，如果磁盤壓力過大就會導(dǎo)致磁盤寫操作很慢，導(dǎo)致后續(xù)的“寫”指令阻塞。

發(fā)現(xiàn)了沒，這兩個問題與磁盤寫回有關(guān)，如果能合理控制“寫”指令執(zhí)行完后 AOF 日志寫回磁盤的時機，問題就可以迎刃而解。

為了提高文件的寫入效率，當(dāng)用戶調(diào)用 write 函數(shù)，將一些數(shù)據(jù)寫入到文件時候，操作系統(tǒng)通常會將寫入數(shù)據(jù)暫時保存在一個內(nèi)存緩沖區(qū)里，等到緩沖區(qū)的空間被填滿或者超過了制定的限制之后，才真正將緩沖區(qū)中的數(shù)據(jù)寫入到磁盤里面。

這種做法雖然提高了效率，但也為寫入數(shù)據(jù)帶來了安全問題，因為如果計算機發(fā)生停機，那么保存在內(nèi)存緩沖區(qū)里的寫入數(shù)據(jù)將會丟失。為此系統(tǒng)提供了 fsync 和 fdatasync 兩個同步函數(shù)，它們可以強制讓操作系統(tǒng)立即將緩沖區(qū)中的數(shù)據(jù)寫入到硬盤里，從而確保寫入數(shù)據(jù)的安全性。

與之相對應(yīng) Redis 提供了 AOF 配置項 appendfsync 寫回策略來控制 AOF 持久化功能的效率和安全性。

appendfsync always     # 同步寫回，寫指令執(zhí)行完畢立即將 aof_buf 緩沖區(qū)中的內(nèi)容寫到 AOF 文件。
appendfsync everysec   # 每秒寫回，寫指令執(zhí)行完畢，把日志寫到 aof_buf 緩沖區(qū)，每隔一秒同步到磁盤，該策略為AOF的默認策略。
appendfsync no         # 操作系統(tǒng)控制，寫指令執(zhí)行完畢，把日志寫到 aof_buf 緩沖區(qū)，由操作系統(tǒng)決定何時寫回磁盤。

3.AOF重寫機制

由于 AOF 記錄的是一個個指令的內(nèi)容，這就會導(dǎo)致保存的文件太大，另外，故障恢復(fù)的時候需要執(zhí)行每一個指令，如果日志文件太大，整個恢復(fù)過程就會非常慢。為此，Reids 設(shè)計了 AOF 重寫機制，提供了 bgrewriteaof 命令用于對 AOF 文件進行瘦身。

其原理就是開辟一個子進程對內(nèi)存進行遍歷轉(zhuǎn)換成一系列 Redis 的操作指令，序列化到一個新的 AOF 日志文件中，序列化完畢后再將操作期間發(fā)生的增量 AOF 日志追加到這個新的 AOF 日志文件中，追加完畢后立即替換舊的 AOF 日志文件。瘦身工作就完成了。

重寫機制有“多變一”的功能，將舊日志中的多條指令，在重寫后就變成了一條指令。如下所示：三條 lpush 命令，經(jīng)過 AOF 重寫后生成一條，對于多次修改的場景，縮減效果明顯。

重寫過程

和 AOF 日志由主線程寫回不同，重寫過程實際是由后臺子進程 bgrewriteof 完成的，這也是為了避免阻塞主線程，導(dǎo)致性能下降。

總的來說，一共出現(xiàn)兩個日志，一次內(nèi)存數(shù)據(jù)拷貝，分別是舊的 AOF 日志和新的 AOF 重寫日志和Redis 數(shù)據(jù)拷貝。大致流程如下圖所示：

在上圖中，Redis 會將重寫過程中接收到的“寫”指令操作同時記錄到舊的 AOF 緩沖區(qū)和新的 AOF 重寫緩沖區(qū)，這樣重寫日志也保存了最新的操作，等到拷貝數(shù)據(jù)的所有操作記錄重寫完成后，重寫緩沖區(qū)記錄的最新操作也會寫到新的 AOF 文件中。

每次 AOF 重寫時，Redis 會先執(zhí)行一次內(nèi)存拷貝，用于遍歷數(shù)據(jù)生成重寫記錄。防止 AOF 重寫過程失敗，導(dǎo)致原 AOF 文件被污染，無法做恢復(fù)使用。

使用兩個日志可以保證在重寫過程中，新寫入的數(shù)據(jù)不會丟失，并且保持數(shù)據(jù)的一致性。

4.AOF 的優(yōu)點和缺點

優(yōu)點

• AOF比RDB可靠。可以靈活制定不同的fsync策略。
• AOF日志文件是一個純追加的文件。就算是遇到突然停電的情況，也不會出現(xiàn)日志的定位或者損壞問題。
• 當(dāng)AOF文件過大時，Redis會自動在后臺進行重寫。
• AOF以命令格式存儲于文件中，在數(shù)據(jù)恢復(fù)時，AOF文件比RDB文件更容易讓開發(fā)人員看懂，并加以修改。

缺點

• 在相同的數(shù)據(jù)集下，AOF文件的大小一般會比RDB文件大。
• 在某些fsync策略下，AOF的速度會比RDB慢。通常fsync設(shè)置為每秒一次就能獲得比較高的性能，而在禁止fsync的情況下速度可以達到RDB的水平。

混合日志模型

重啟 Redis 時，我們很少使用 RDB 來恢復(fù)內(nèi)存狀態(tài)，因為可能丟失大量數(shù)據(jù)。通常采用 AOF 日志重放，但是重放 AOF 日志性能相對 RDB 來說要慢很多，在Redis實例很大的情況下，啟動需要花費很長時間。

Redis 4.0 為了解決這個問題，提供了一個新的持久化選項--混合持久化，將 RDB 文件的內(nèi)容和增量 AOF 日志文件存放到一起，這里的 AOF 日志不再是全量的日志，而是自持久化開始到持久化結(jié)束的這段時間發(fā)生的增量 AOF 日志，通常這部分日志很小。

在 Redis 重啟的時候，先加載 RDB 的內(nèi)容，然后再重放增量 AOF 日志，這樣的操作既保證了 Redis 重啟速度，又降低數(shù)據(jù)丟失風(fēng)險。

總結(jié)

• Redis 提供 RDB 快照持久化方案，記錄某一時刻數(shù)據(jù)狀態(tài)
• Redis 通過寫時復(fù)制技術(shù)設(shè)計了BGSAVE，避免執(zhí)行快照期間對讀寫指令的影響。
• Redis 提供了 AOF 寫后日志持久化方案，記錄每一條操作指令。
• Redis 通過 AOF 重寫方案，避免 AOF文件過大。
• Redis 提供了混合持久化的方案，RDB + AOF 實現(xiàn)持久化保證數(shù)據(jù)可靠性，同時支持故障后的數(shù)據(jù)快速恢復(fù)。

參考

Redis設(shè)計與實（https://weread.qq.com/web/reader/d35323e0597db0d35bd957bk73532580243735b90b45ac8）

Redis核心技術(shù)與實戰(zhàn)（https://time.geekbang.org/column/intro/329）