• 1.內存快照
• 2.AOF持久化
• 3.混合持久化
• 4.Redis持久化相關配置
• 5.總結

Redis將數(shù)據(jù)存儲在內存中,宕機或重啟都會使內存數(shù)據(jù)全部丟失, Redis的持久化機制用來保證數(shù)據(jù)不會因為故障而丟失。

Redis提供兩種持久化方式，一種為內存快照方式，生成rdb文件，rdb是某一時間點內存數(shù)據(jù)的全量備份,文件內容是存儲結構非常緊湊的二進制序列化形式；另一種是AOF日志備份方式,日志保存的是基于數(shù)據(jù)的連續(xù)增量備份，日志文件內容是服務端執(zhí)行的每一條指令的記錄文本。

兩種方式各有優(yōu)略，下面的章節(jié)會詳細介紹兩種持久化機制的實現(xiàn)原理和使用技巧。

1.內存快照

Redis進行快照數(shù)據(jù)持久化時，為了不阻塞線上業(yè)務，要能夠響應客戶端請求。快照持久化的工作是將一個時間點內存數(shù)據(jù)序列化后同步到磁盤rdb文件。備份數(shù)據(jù)如何在內存中瞬間凝固，不再改變？文件IO操做怎樣才能不拖累服務端對客戶端的正常響應？這一切都要從Copy On Write說起。

1.1 快照原理——Copy On Write

Copy On Write簡寫為COW，又叫寫時復制，是操作系統(tǒng)為優(yōu)化使用子進程采取的一種策略。

類Unix系統(tǒng)創(chuàng)建進程的主要方式是調用glibc的函數(shù)fork,熟悉Linux的人都知道:Linux操作系統(tǒng)的進程都是通過init進程(pid=1)或者其子進程fork(vfork)出來的。

fork()會產(chǎn)生一個與父進程完全相同的子進程，有兩次返回:將子進程的pid返回給父進程，0返回給子進程。如果小于0，說明創(chuàng)建進程失敗！下面是一個C語言的例子:

#include
#include

intmain(){
pid_tpid;
intcount=0;
pid=fork();
if(pid0)
printf("errorinfork!");
elseif(pid==0){
printf("childprocess,processidis%d/n",getpid());
count++;
}else{
printf("parentprocess,processidis%d/n",getpid());
count++;
}
printf("counttotal:%d/n",count);
return0;
}

輸出結果為:

parentprocess,processidis23049
counttotal:1
childprocess,processidis23050
counttotal:1

當前進程調用fork()，會創(chuàng)建一個跟當前進程完全相同的子進程(除了pid)，所以子進程同樣是會執(zhí)行fork()之后的代碼。父子進程的count變量都是1，說明父子進程使用了各自獨有的棧區(qū)(count變量存放在棧區(qū))。

我們先來看一下CPU執(zhí)行程序的流程。

CPU在加載執(zhí)行程序時，首先按照虛擬地址來尋址，然后通過MMU(內存管理單元)將虛擬地址轉換為物理地址。因為只有程序的一部分加入到內存中(按頁加載)，所以會出現(xiàn)所尋找的地址不在內存中的情況（CPU產(chǎn)生缺頁異常），如果在內存不足的情況下，就會通過頁面調度算法來將內存中的頁面置換出來，然后將在外存中的頁面加入到內存中，使程序繼續(xù)正常運行。

Linux操作系統(tǒng)的每一個進程，都會分配有虛擬地址和物理地址，虛擬地址和物理地址通過MMU保持映射關系。一個進程是一個主體，它有靈魂有身體，靈魂就是其虛擬地址空間(有相應的數(shù)據(jù)結構表示),包括：正文段、數(shù)據(jù)段、堆、棧這四個部分;相應的，內核會為這四個部分分配各自的物理塊（進程的身體）即：正文段塊、數(shù)據(jù)段塊、堆塊、棧塊。

我們再來看一下fork進程時寫時復制的過程:

在 fork產(chǎn)生子進程時，操作系統(tǒng)只為新生成的子進程創(chuàng)建虛擬空間結構，它們復制于父進程的虛擬空間結構，但是不為這些段分配物理內存，它們共享父進程的物理空間，當父子進程中有更改相應段的行為發(fā)生時，再為子進程相應的段分配物理空間，這就是寫時復制。

1.2 快照執(zhí)行流程

Redis在持久化時會調用glibc的函數(shù)fork產(chǎn)生一個子進程，快照持久化完全交給子進程來處理，父進程繼續(xù)處理客戶端請求。

可以通過在Redis客戶端輸入bgsave命令來觸發(fā)快照保存操作，Redis調用bgsaveCommand函數(shù)，該函數(shù)fork一個子進程，子進程剛剛產(chǎn)生時，它和父進程共享內存里面的代碼段和數(shù)據(jù)段。這時將父子進程比喻成一個連體嬰兒 非常恰當，這是Linux操作系統(tǒng)的機制，為了節(jié)約內存資源，盡可能的將內存資源共享起來。在進程分離的一瞬間，內存的增長幾乎沒有明顯的變化。子進程因為沒有數(shù)據(jù)的變化，它能感知到的內存數(shù)據(jù)在進程產(chǎn)生的一瞬間就凝固了，再也不會改變。父進程可以繼續(xù)處理客戶端請求，當子進程推出后，父進程調用相關函數(shù)處理子進程的善后工作。

基于 Spring Boot + MyBatis Plus + Vue & Element 實現(xiàn)的后臺管理系統(tǒng) + 用戶小程序，支持 RBAC 動態(tài)權限、多租戶、數(shù)據(jù)權限、工作流、三方登錄、支付、短信、商城等功能

• 項目地址：https://gitee.com/zhijiantianya/ruoyi-vue-pro
• 視頻教程：https://doc.iocoder.cn/video/

2.AOF持久化

AOF日志存儲的Redis服務器的順序指令序列，只記錄對內存進行修改的指令記錄。有了AOF文件，就可以通過一個空的Redis實例順序執(zhí)行所有的指令來恢復Redis當前實例的內存數(shù)據(jù)結構的狀態(tài)，這個過程叫做重放。

2.1 AOF日志文件寫入

AOF日志以文件的形式存在，寫文件通過操作系統(tǒng)提供的write函數(shù)執(zhí)行，但是write之后的數(shù)據(jù)只是寫到了內核的一個緩沖區(qū)中，然后內核還需要異步的調用fsync函數(shù)異步的將數(shù)據(jù)刷回磁盤。fsync函數(shù)是一個阻塞并且緩慢的操作，如果機器突然宕機，AOF日志內容可能還沒來的及完全刷到磁盤，這時候就會丟失數(shù)據(jù)。Redis通過appendfsync配置控制執(zhí)行fsync的頻次，具體有如下三種模式:

• no: 永遠不調用fsync，讓操作系統(tǒng)決定何時同步磁盤，這樣做很不安全，但是Redis的性能最高。
• always: 每執(zhí)行一次寫入操作就執(zhí)行一次fsync，雖然數(shù)據(jù)安全性高，會導致執(zhí)行非常緩慢。
• everysec: 每隔1s執(zhí)行一次fsync,這個1s的周期是可以配置的，這是數(shù)據(jù)安全性和性能之間的折中方案，在保證高性能的同時，盡量使數(shù)據(jù)少丟失。推薦在生產(chǎn)環(huán)境中使用。

2.2 AOF執(zhí)行流程

Redis收到客戶端的指令以后，首先進行參數(shù)校驗、邏輯處理，如果沒有問題，會判斷是否開啟AOF，如果開啟，則會將每條命令執(zhí)行完畢后同步寫入aof_buf中，aof_buf是個全局的SDS類型的緩沖區(qū)。

每一條命令的執(zhí)行都會調用call函數(shù)，注意:Redis服務端是先執(zhí)行指令再將命令寫入aof_buf。

2.3 日志瘦身——AOF重寫

Redis服務端在長期運行過程中，AOF日志會越來越長，如果實例宕機或者重啟，重放整個AOF日志會非常耗時，導致Redis長時間無法對外提供服務，所以需要對AOF日志進行瘦身，即：**AOF重寫。**

我們考慮一下AOF和RDB文件的加載過程:RDB只需要把相應的數(shù)據(jù)加載都內存并生成相應的數(shù)據(jù)結構就可以了，有些結構如intset、ziplist，保存的時候直接按照字符串保存，加載速度非常快。但是AOF日志文件的加載需要創(chuàng)建一個偽客戶端，順序執(zhí)行一遍命令，根據(jù)Redis作者做的測試，RDB在10～20秒能加載1GB的文件，AOF的速度是RDB的一半(如果做了AOF重寫會加快)

通過Redis客戶端bgrewriteaof指令對AOF日志進行瘦身過程如下:

Redis服務端調用bgrewriteaofCommand命令創(chuàng)建管道，創(chuàng)建管道對作用是AOF重寫過程中批量接收服務端累積的命令;創(chuàng)建完管道以后,fork進程，子進程調用rewriteAppendOnlyFile執(zhí)行AOF重寫操作；父進程記錄一些統(tǒng)計指標后繼續(xù)進入主循環(huán)處理客戶端請求，待子進程結束以后，處理一些善后工作。瘦身工作就是子進程對所有數(shù)據(jù)庫中的鍵各自生成一條相應的執(zhí)行命令，最后將重寫開始后父進程繼續(xù)執(zhí)行的命令進行回放，生成一個新的AOF文件。

例如執(zhí)行了下面的命令:

127.0.0.1:6379>lpushlistguozhaoran
(integer)3
127.0.0.1:6379>lpoplist
"ran"
127.0.0.1:6379>lpoplist
"zhao"
127.0.0.1:6379>lpushlistzhao
(integer)2

AOF文件會保存對list操作的4條命令，但是list現(xiàn)在內存中的元素是這樣的:

127.0.0.1:6379>lrangelist0-1
1)"zhao"
2)"guo"

AOF重寫以后就日志文件內容直接就變?yōu)榱?code style="font-size:14px;padding:2px 4px;margin:0 2px;color:#1e6bb8;background-color:rgba(27,31,35,.05);font-family:'Operator Mono', Consolas, Monaco, Menlo, monospace;">lpush list zhao guo。日志瘦身既可以減小文件大小，又可以提高加載速度。

基于 Spring Cloud Alibaba + Gateway + Nacos + RocketMQ + Vue & Element 實現(xiàn)的后臺管理系統(tǒng) + 用戶小程序，支持 RBAC 動態(tài)權限、多租戶、數(shù)據(jù)權限、工作流、三方登錄、支付、短信、商城等功能

• 項目地址：https://gitee.com/zhijiantianya/yudao-cloud
• 視頻教程：https://doc.iocoder.cn/video/

3.混合持久化

RDB和AOF實現(xiàn)持久化的方式各有優(yōu)缺點，我們來簡單總結一下:

RDB 保存的是一個時間的快照，如果發(fā)生故障，丟失的是最后一次RDB執(zhí)行時間點到故障發(fā)生的時間間隔之內產(chǎn)生的數(shù)據(jù)。如果Redis數(shù)據(jù)量很大，QPS很高，執(zhí)行一次RDB需要的時間會相應增加，發(fā)生故障時丟失的數(shù)據(jù)也會增多。

AOF 保存的是一條條的命令，理論上可以做到發(fā)生故障時只丟失一條命令。但是由于操作系統(tǒng)中執(zhí)行寫文件操作代價很大，Redis提供了配置參數(shù)，可以對完全性和性能取折中，設置不同的配置策略。但是重放AOF日志相對于使用RDB來說還是慢很多。

Redis4.0為了解決這個問題，帶來了一個新的持久化選項——混合持久化。混合持久化是指進行AOF重寫時子進程將當前時間點的數(shù)據(jù)快照保存為RDB文件格式，而后將父進程累積命令保存為AOF格式，最終生成的格式如下圖所示:

將RDB文件內容和增量AOF日志文件存在一起，這里的AOF日志不再是全量日志，通常這部分AOF日志很小。于是在Redis重啟的時候，可以先加載rdb內容，然后再重放增量AOF日志，就可以完全替代之前的AOF全量文件重放，重啟效率會得到大幅度提升。

4.Redis持久化相關配置

下面總結一下Redis4.0版持久化相關的配置及其含義。

5.總結

Redis是內存數(shù)據(jù)庫，機器故障或重啟之后，內存數(shù)據(jù)全部丟失，所以需要持久化來保證數(shù)據(jù)安全。

Redis提供了快照RDB和AOF日志同步兩種方式進行數(shù)據(jù)持久化,快照RDB實現(xiàn)原理是Copy On Write,優(yōu)點是機器加載速度快，缺點是執(zhí)行緩慢，QPS高的情況下會丟失大量數(shù)據(jù);AOF則是將命令一條條的有序存放到日志文件中,優(yōu)點是盡可能少的丟失數(shù)據(jù)，缺點是日志文件重放緩慢，日志文件會很大，可以通過重寫AOF日志來實現(xiàn)，另外提供了這種的配置方案異步執(zhí)行fsync操作。

生產(chǎn)環(huán)境中推薦使用混合持久化,這種方式綜合了RDB和AOF兩種方式的優(yōu)點。文章最后總結了一下Redis持久化配置項。本文是筆者學習Redis持久化的總結，希望能對讀者有所幫助。

審核編輯：湯梓紅