Redis（數(shù)據(jù)存儲在內(nèi)存中）支持 RDB 和 AOF 兩種持久化（和 MySQL 里的持久性是一回事，把數(shù)據(jù)存儲在硬盤上，重啟進程 / 主機后數(shù)據(jù)仍然存在 —— 持久；把數(shù)據(jù)存儲在內(nèi)存上，重啟進程 / 主機后數(shù)據(jù)消失 —— 不持久）機制，持久化功能有效地避免因進程退出造成數(shù)據(jù)丟失問題，當下次重啟時利用之前持久化的文件即可實現(xiàn)數(shù)據(jù)恢復。

Redis 為了保證速度快，數(shù)據(jù)肯定還得存儲在內(nèi)存中。但是為了持久化，數(shù)據(jù)還得想辦法存儲在硬盤上。所以，最后決定在內(nèi)存中和硬盤上都存儲數(shù)據(jù)，這樣的兩份數(shù)據(jù)在理論上（實際上可能存在一個小的概率有差異，具體取決于如何進行持久化）是完全相同的。當要插入一個新的數(shù)據(jù)時，就需要把這個數(shù)據(jù)同時寫入到內(nèi)存和硬盤。當查詢某個數(shù)據(jù)時，直接從內(nèi)存中讀取，硬盤的數(shù)據(jù)只是在 Redis 重啟時，用來恢復內(nèi)存中的數(shù)據(jù)。代價就是消耗了更多的空間，同一份數(shù)據(jù)存儲了兩遍，但畢竟硬盤價格便宜，開銷不會帶來太大的成本。而且實際上具體怎么寫硬盤還有不同的策略，是可以保證整體的效率足夠高的。

假設我自己的電腦上有很多的學習資料，雖然現(xiàn)在是把這些學習資料保存在硬盤上（持久化保存），但是萬一我的電腦出現(xiàn)故障（相較于 CPU、顯卡、內(nèi)存來說，硬盤是最容易出問題的，尤其是機械硬盤）?？梢阅昧硪粔K移動硬盤來作為備份用的硬盤：

• 定期備份（每個月將電腦硬盤上的學習資料整體的備份到這個備份盤中）—— RDB
• 實時備份（只要下載了一個新的學習資料，就立即把這份學習資料往備份盤中拷貝一份）—— AOF

一、RDB

RDB（Redis DataBase）持久化是把定期的將當前的進程數(shù)據(jù)生成快照保存到硬盤的過程，觸發(fā) RDB 持久化過程分為手動觸發(fā)和自動觸發(fā)。

1、觸發(fā)機制

手動觸發(fā)分別對應 save 和 bgsave 命令：

• save 命令：阻塞當前 Redis 服務器，直到 RDB 過程完成為止，對于內(nèi)存比較大的實例造成長時間阻塞。（一半不建議使用）
• bgsave（background save）命令：Redis 進程執(zhí)行 fork 操作創(chuàng)建子進程，RDB 持久化過程由子進程負責，完成后自動結束。阻塞只發(fā)生在 fork 階段，一般時間很短。不會影響 Redis 服務器處理其他客戶端的請求和命令。（此處 Redis 使用的是 “多進程” 的方式來完成的并發(fā)編程，來完成 bgsave 的實現(xiàn)）

Redis 內(nèi)部的所有涉及 RDB 的操作都采用類似 bgsave 的方式。

如果插入新的 key，而此時不手動執(zhí)行 bgsave，直接重新啟動 Redis 服務器，那么剛剛插入的數(shù)據(jù)在重啟之后仍然存在。所以說，Redis 生成快照操作不僅僅是手動執(zhí)行命令才觸發(fā)，也可以自動觸發(fā)，也就是下面的第 3 點。

除了手動觸發(fā)之外，Redis 運行自動觸發(fā) RDB 持久化機制，這個觸發(fā)機制才是在實戰(zhàn)中有價值的。

1. 使用 save 配置。如 "save m n" 表示 m 秒內(nèi)數(shù)據(jù)集發(fā)生了 n 次修改，自動 RDB 持久化。
2. 從節(jié)點進行全量復制（主從復制）操作時，主節(jié)點自動進行 RDB 持久化生成快照，隨后將 RDB 快照文件內(nèi)容發(fā)送給從節(jié)點。
3. 如果執(zhí)行 shutdown 命令（service redis-server restart，正常關閉）關閉 Redis 時，或者通過正常流程重新啟動 Redis 服務器，那么此時 Redis 服務器會在退出時自動執(zhí)行 RDB 持久化。但如果是異常重啟（kill -9 或者服務器掉電），那么此時 Redis 服務器來不及生成 rdb，內(nèi)存中尚未保存到快照中的數(shù)據(jù)，就會隨著重啟而丟失。

并不是說 Redis 客戶端這邊插入了數(shù)據(jù)，rdb 文件中的數(shù)據(jù)就會立即更新的。插入幾個鍵值對后，沒有運行手動觸發(fā)的命令，也達不到自動觸發(fā)的條件，那么就不會更新。

如果修改成如下內(nèi)容：

對于 Redis 來說，配置文件發(fā)生修改后，一定要重新啟動服務器才能生效。（當然，如果想要立即生效，也可以通過命令的方式進行修改）

同時滿足兩個條件即可觸發(fā)快照的生成：

如果是修改成以下內(nèi)容：

那么將會關閉自動生成快照這個功能。

如果把 rdb 文件故意改壞會怎么樣？

手動把 rdb 文件內(nèi)容改壞，如果是通過 service redis-server restart 重啟，就會在 Redis 服務器退出時重新生成 rdb 快照，那么剛才改壞的文件就會被替換掉。

而如果是通過 kill 進程的方式，再重新啟動 Redis 服務器，此時 rdb 文件就還是錯的。但看起來 Redis 好像沒有受到什么影響，還是能正常啟動，能正確獲取到 key。那是因為剛才修改的位置應該正好是文件的末尾，對前面的內(nèi)容沒有什么影響。但如果是修改了中間位置的內(nèi)容，那么 Redis 服務器就啟動不了了。 

此時，Redis 服務器掛了，可以看看 Redis 日志，了解一下發(fā)生了什么。

打開該文件，可以看到：

也就是在 rdb 恢復數(shù)據(jù)的過程中出現(xiàn)了問題。

rdb 文件是二進制的，如果直接把壞了的 rdb 文件交給 Redis 服務器去使用，那么得到的結果是不可預期的。

所以，Redis 也提供了 rdb 文件的檢查工具，可以先通過檢查工具來檢查一下 rdb 文件格式是否符合要求。

5.0 版本中，檢查工具和 Redis 服務器是同一個可執(zhí)行程序，可以在運行時加入不同的選項，從而使用其中不同的功能。

運行時加入 rdb 文件作為命令行參數(shù)，那么此時就是以檢查工具的方式來運行，不會真的啟動 Redis 服務器。

2、流程說明

bgsave 是主流的 RDB 持久化方式，根據(jù)下圖來了解它的運作流程。

bgsave 命令的運作流程：

1. 執(zhí)行 bgsave 命令，Redis 父進程（Redis 服務器）判斷當前進是否存在其他正在執(zhí)行的子進程，比如：RDB / AOF 子進程，如果存在 bgsave 命令直接返回。
2. 如果沒有其它的工作子進程，父進程通過執(zhí)行 fork 這樣的系統(tǒng)調用來創(chuàng)建一個子進程（該場景中的絕大部分內(nèi)存數(shù)據(jù)是不需要改變的，所以在短時間內(nèi)父進程中不會有大批的內(nèi)存數(shù)據(jù)變化，因此子進程的 “寫時拷貝” 并不會觸發(fā)很多次），fork 過程中父進程會阻塞，通過 info stats 命令查看 latest_fork_usec 選項，可以獲取最近一次 fork 操作的耗時，單位為微秒。
3. 父進程 fork 完成后，bgsave 命令返回 "Background saving started" 信息，并不再阻塞父進程，可以繼續(xù)響應其他命令。
4. 子進程創(chuàng)建 RDB 文件，根據(jù)父進程內(nèi)存生成臨時快照文件，完成后對原有文件進行原子替換。執(zhí)行 lastsave 命令可以獲取最后一次生成 RDB 的時間，對應 info 統(tǒng)計的 rdb_last_save_time 選項。
5. 進程發(fā)送信號給父進程表示完成，父進程更新統(tǒng)計信息，子進程就可以結束銷毀了。

bgsave 操作流程是創(chuàng)建子進程，子進程完成持久化操作（持久化速度太快了（數(shù)據(jù)少），難以觀察到子進程），持久化會把數(shù)據(jù)寫入到新的文件中，然后使用新的文件替換舊的文件（這個容易觀察）。

可以通過 Linux 的 stat 命令來查看文件的 inode 編號：

這兩個文件不再是同一個文件了，只不過文件內(nèi)容是一樣的。inode 編號就相當于文件的身份標識。如果是直接使用 save 命令，那么此時是不會觸發(fā)子進程和文件替換邏輯的，會直接在當前進程中往剛才的同一文件中寫入數(shù)據(jù)。

文件系統(tǒng)典型的組織方式（ext4）主要是把整個文件系統(tǒng)分成三個大的部分：

1. 超級塊（存放一些管理信息）
2. inode 區(qū)（存放 inode 節(jié)點，每個文件都會分配一個 inode 數(shù)據(jù)結構，包含文件的各種元數(shù)據(jù)）
3. block 區(qū)（存放文件的數(shù)據(jù)內(nèi)容）

3、RDB 文件的處理

保存：RDB 文件（把內(nèi)存中的數(shù)據(jù)以壓縮（需要消耗一定的 cpu 資源，但是能節(jié)省存儲空間）的形式保存到這個二進制文件中）保存在 dir 配置指定的目錄（默認 /var/lib/redis/）下，文件名通過 dbfilename 配置（默認 dump.rdb）指定。

可以通過執(zhí)行 config set dir {newDir} 和 config set dbfilename {newFilename} 運行期間動態(tài)執(zhí)行，當下次運行時 RDB 文件會保存到新目錄。

• 壓縮：Redis 默認采用 LZF 算法對生成的 RDB 文件做壓縮處理，壓縮后的文件遠遠小于內(nèi)存大小，默認開啟，可以通過參數(shù) config set rdbcompression {yes|no} 動態(tài)修改。

雖然壓縮 RDB 會消耗 CPU，但可以大幅降低文件的體積，方便保存到硬盤或通過網(wǎng)絡發(fā)送到從節(jié)點，因此建議開啟。

• 校驗：如果 Redis 啟動時加載到損壞的 RDB 文件會拒絕啟動。這時可以使用 Redis 提供的 redis-check-dump 工具檢測 RDB 文件并獲取對應的錯誤報告。

當執(zhí)行生成 rdb 鏡像操作時，此時就會把要生成的快照數(shù)據(jù)先保存到一個臨時文件中。當這個快照生成完畢后，再刪除之前的 rdb 文件，把新生成的臨時 rdb 文件名改成剛才的 dump.rdb。也就保證了，rdb 文件自始至終只有一個。

 執(zhí)行 flushall 命令會自動情況 rdb 文件。

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

（1）優(yōu)點

• RDB 是?個緊湊壓縮的二進制文件，代表 Redis 在某個時間點上的數(shù)據(jù)快照。非常適用于備份，全量復制等場景。比如每 6 小時執(zhí)行 bgsave 備份，并把 RDB 文件復制到遠程機器或者文件系統(tǒng)中（如 hdfs）用于災備。
• Redis 加載 RDB 恢復數(shù)據(jù)遠遠快于 AOF 的方式。 （二進制的方式則直接將數(shù)據(jù)讀取到內(nèi)存中，按照字節(jié)的格式取出來放到結構體 / 對象即可，文本方式組織數(shù)據(jù)則需要進行一系列的字符串切分操作）

（2）缺點

• RDB 方式數(shù)據(jù)沒辦法做到實時持久化 / 秒級持久化（在兩次生成快照之間，實時數(shù)據(jù)可能會隨著重啟而丟失），這就導致快照里的數(shù)據(jù)和當前實時的數(shù)據(jù)情況可能存在偏差。因為 bgsave 每次運行都要執(zhí)行 fork 創(chuàng)建子進程，屬于重量級操作，頻繁執(zhí)行成本過高。
• RDB 文件使用特定二進制格式保存，Redis 版本演進過程中有多個 RDB 版本，兼容性可能有風險（舊版本的 Redis 的 rdb 文件放到新版本的 Redis 中不一定能實現(xiàn)。但一般來說，實際工作中 Redis 版本都是統(tǒng)一的，實在不行也可以通過寫一個程序的方式來直接遍歷舊的 Redis 中的所有 key，把數(shù)據(jù)取出來插入到新的 Redis 服務器中即可）。

二、AOF

AOF（Append Only File）持久化（類似于 MySQL 中的 binlog，會把用戶的每個操作都記錄到文件中）：以獨立日志的方式記錄每次寫命令，重啟時再重新執(zhí)行 AOF 文件中的命令達到恢復數(shù)據(jù)的目的。AOF 的主要作用是解決了數(shù)據(jù)持久化的實時性，目前已經(jīng)是 Redis 持久化的主流方式。

Redis 重新啟動時，又讀 RDB、又讀 AOF，到底以哪個為準呢？

當開啟 AOF 時，rdb 就不生效了，啟動的時候就不再讀取 rdb 文件內(nèi)容。

1、使用 AOF

開啟 AOF 功能需要設置配置：appendonly yes，默認是關閉狀態(tài)。AOF 文件名通過 appendfilename 配置（默認是 appendonly.aof）設置。

保存目錄同 RDB 持久化方式一致，通過 dir 配置指定（/var/lib/redis）。AOF 的工作流程操作：命令寫入（append）、文件同步（sync）、文件重寫（rewrite）、重啟加載（load），如下圖所示：

AOF 工作流程：

1. 所有的寫入命令會追加到 aof_buf（內(nèi)存中的緩沖區(qū)，大大降低了寫硬盤的次數(shù)）中。
2. AOF 緩沖區(qū)根據(jù)對應的策略向硬盤做同步操作。
3. 隨著 AOF 文件越來越大，需要定期對 AOF 文件進行重寫，達到壓縮的目的。
4. 當 Redis 服務器啟動時，可以加載 AOF 文件進行數(shù)據(jù)恢復。

注意：寫硬盤的時候，寫入硬盤數(shù)據(jù)的多少對于性能的影響不是很大，但是寫入硬盤的次數(shù)則影響很大了。

硬盤上讀寫數(shù)據(jù)，順序讀寫的速度還是比較快的（但還是比內(nèi)存要慢很多），隨機訪問則速度比較慢。AOF 是每次將新的數(shù)據(jù)寫入到原有文件的末尾，屬于順序寫入。

2、命令寫入

AOF 命令寫入的內(nèi)容直接是文本協(xié)議格式。

每次進行的操作都會被記錄到文本文件中，通過一些特殊符號作為分隔符，來對命令的細節(jié)做出區(qū)分。

此處遵守 Redis 格式協(xié)議，Redis 選擇文本協(xié)議可能的原因：

• 文本協(xié)議具備較好的兼容性。
• 實現(xiàn)簡單。
• 具備可讀性。  

AOF 過程中為什么需要 aof_buf 這個緩沖區(qū)？

Redis 雖然是使用單線程響應命令，但是速度很快，因為它只是操作內(nèi)存。引入 AOF 之后，又要寫內(nèi)存，又要寫硬盤，同時還要保持之前的速度。實際上，這并沒有影響到 Redis 處理請求的速度。

AOF 機制并非是直接讓工作線程把數(shù)據(jù)寫入硬盤，而是先寫入一個內(nèi)存中的緩沖區(qū)，積累一波之后再統(tǒng)一寫入。如果每次寫 AOF 文件都直接同步硬盤，性能從內(nèi)存的讀寫變成 IO 讀寫，必然會下降。先寫入緩沖區(qū)可以有效減少 IO 次數(shù)，同時，Redis 還可以提供多種緩沖區(qū)同步（刷新）策略，讓用戶根據(jù)自己的實際情況和需求來做出合理的平衡。

如果把數(shù)據(jù)寫入到緩沖區(qū)中，其本質還是在內(nèi)存中。萬一此時突然進程掛了或者主機掉點了，那緩沖區(qū)中的數(shù)據(jù)是否就丟了呢？

是的。緩沖區(qū)中沒來得及寫入硬盤的數(shù)據(jù)是會丟失的。

• 緩沖區(qū)刷新頻率越高，性能影響就越大，同時數(shù)據(jù)的可靠性就越高。
• 緩沖區(qū)刷新頻率越低，性能影響就越小，同時數(shù)據(jù)的可靠性就越低。 

3、文件同步

Redis 提供了多種 AOF 緩沖區(qū)同步文件策略，由參數(shù) appendfsync 控制，不同值的含義如下表所示。

AOF 緩沖區(qū)同步文件策略：

默認采用 everysec 配置：

系統(tǒng)調用 write 和 fsync 說明：

• write 操作會觸發(fā)延遲寫（delayed write）機制。Linux 在內(nèi)核提供頁緩沖區(qū)用來提供硬盤 IO 性能。write 操作在寫入系統(tǒng)緩沖區(qū)后立即返回。同步硬盤操作依賴于系統(tǒng)調度機制，例如：緩沖區(qū)頁空間寫滿或達到特定時間周期。同步文件之前，如果此時系統(tǒng)故障宕機，緩沖區(qū)內(nèi)數(shù)據(jù)將丟失。
• Fsync 針對單個文件操作，做強制硬盤同步，fsync 將阻塞直到數(shù)據(jù)寫入到硬盤。
• 配置為 always 時，每次寫入都要同步 AOF 文件，性能很差，在?般的 SATA 硬盤上，只能?持大約幾百 TPS 寫入。除非是非常重要的數(shù)據(jù)，否則不建議配置。
• 配置為 no 時，由于操作系統(tǒng)同步策略不可控，雖然提高了性能，但數(shù)據(jù)丟失風險大增，除非數(shù)據(jù)重要程度很低，一般不建議配置。
• 配置為 everysec，是默認配置，也是推薦配置，兼顧了數(shù)據(jù)安全性和性能。理論上最多丟失 1s 的數(shù)據(jù)。

4、重寫機制

隨著命令不斷寫入 AOF，文件持續(xù)增長，體積會越來越大，會影響到 Redis 下次啟動的啟動時間（Redis 在啟動時需要讀取 AOF 文件內(nèi)容，該文件記錄了中間的過程，但實際上 Redis 在重啟時只關注最終結果）。

為了解決這個問題，Redis 引入 AOF 重寫機制（能夠針對 AOF 文件進行整理操作，剔除其中的冗余操作并合并一些操作，以此達到給文件 “瘦身” 的效果）壓縮文件體積。

AOF 文件重寫是把 Redis 進程內(nèi)的數(shù)據(jù)轉化為寫命令同步到新的 AOF 文件。

重寫后的 AOF 為什么可以變?。?/strong>