一：Redis持久化概述
持久化的功能：Redis是內存數據庫，數據都是存儲在內存中，為了避免進程退出導致數據的永久丟失，需要定期將Redis中的數據以某種形式(數據或命令)從內存保存到硬盤；當下次Redis重啟時，利用持久化文件實現數據恢復。除此之外，為了進行災難備份，可以將持久化文件拷貝到一個遠程位置
1：RDB持久化方式
RDB（Redis DataBase）持久化是在設置的某個時間點內，將當前進程中的數據生成快照(Snapshot)保存到硬盤(因此也稱作快照持久化)，保存的文件后綴是rdb；當Redis重新啟動時，會自動讀取快照文件恢復數據；也可以通過 save 和 bgsave 命令實現手動持久化
注：RDB方式是將我們存儲的 數據 保存到硬盤上
2：AOF持久化方式
AOF（append only file）持久化：以獨立日志的方式記錄每次增刪改命令，重啟時再重新執行AOF文件中的命令達到恢復數據的目的。AOF的主要作用是解決了數據持久化的實時性，目前已經是Redis持久化的主流方式。當我們下次重啟Redis服務時會先執行AOF文件來恢復數據
注：RDB方式是將我們存儲的 增刪改命令 保存到硬盤上
二：RDB持久化
1：RDB持久化觸發方式
手動觸發：
save 命令：
執行此命令會阻塞當前Redis服務器，直到持久化完成，生產環境一般禁止使用（因為會阻塞其它客戶端的訪問操作）。
bgsave 命令：
該觸發方式會fork一個子進程，由子進程負責持久化過程，因此阻塞只會發生在fork子進程的時候。
自動觸發：
①：根據我們在配置文件配置的 save m n 的規則來自動觸發（后面介紹）
②：執行退出shutdown命令時會自動觸發（前提是我們配置的持久化機制為RDB）
執行退出shutdown nosave命令時不會自動觸發
③：執行flushAll會自動觸發持久化（但是沒有數據，只有一個空的.rdb文件）
執行flushdb不會觸發持久化
④：執行debug reload會自動觸發持久化
①：執行bgsave命令，Redis父進程判斷當前是否存在正在執行的子進程，如RDB/AOF子進程，如果存在bgsave命令直接返回。
②：父進程執行fork操作創建子進程，fork操作過程中父進程會阻塞，通過info stats命令查看latest_fork_usec選項，
可以獲取最近一個fork操作的耗時，單位為微秒。
③：父進程fork完成后，bgsave命令返回“Background saving started”信息並不再阻塞父進程，可以繼續響應其他命令。
④：子進程創建RDB文件，根據父進程內存生成臨時快照文件，完成后對原有文件進行原子替換。執行lastsave命令可以獲取最后
一次生成RDB的時間，對應info統計的rdb_last_save_time選項。
⑤：進程發送信號給父進程表示完成，父進程更新統計信息。
2：RDB配置文件
Redis常用配置： # 默認情況下Redis將自動保存數據： # 3600 秒（1 小時）后，如果至少更改了 1 個鍵 # 300 秒（5 分鍾）后，如果至少更改了 100 個鍵 # 60 秒（1 分鍾）后，如果至少更改了10000個鍵 # 您可以通過取消注釋以下三行來顯式設置這些（可自定義save 秒 鍵） save 3600 1 save 300 100 save 60 10000 # 當bgsave出現錯誤時，Redis是否停止執行寫命令； # yes：則當硬盤出現問題時，可以及時發現，避免數據的大量丟失； # no：則Redis無視bgsave的錯誤繼續執行寫命令，當對Redis服務器的系統(尤其是硬盤)使用了監控時，該選項考慮設置為no stop-writes-on-bgsave-error yes # 是否開啟RDB文件壓縮 rdbcompression yes # 是否開啟RDB文件的校驗，在寫入文件和讀取文件時都起作用；關閉checksum在寫入文件和啟動文件時大約能帶來10%的性能提升， # 但是數據損壞時無法發現 rdbchecksum yes # 存儲后的RDB文件名 默認dump.rdb dbfilename dump.rdb # 是否刪除主從復制時創建的RDB文件（在沒有開啟持久化的實例中，最好將其刪除） rdb-del-sync-files no # 存儲持久化文件的目錄 以上使用“dbfilename”配置指令，附加文件也將在此目錄中創建 dir ./
3：基本操作演示
# 執行save 客戶端： 127.0.0.1:6379> save OK 服務端： 910:M 12 Dec 2021 14:59:31.373 * DB saved on disk # 執行bgsave 客戶端： 127.0.0.1:6379> bgsave Background saving started 服務端： 910:M 12 Dec 2021 15:00:44.755 * Background saving started by pid 913 913:C 12 Dec 2021 15:00:44.777 * DB saved on disk 910:M 12 Dec 2021 15:00:44.825 * Background saving terminated with success # 執行flushall 客戶端： 127.0.0.1:6379> FLUSHALL OK 服務端： 910:M 12 Dec 2021 15:01:55.217 * DB saved on disk # 自動存儲（save 30 2）當30秒內執行2次命令則會在30秒后執行自動持久化RDB 客戶端： 127.0.0.1:6379> set name zhangsan OK 127.0.0.1:6379> set age 22 OK 服務端： 245:M 12 Dec 2021 15:06:09.045 * 2 changes in 30 seconds. Saving... 245:M 12 Dec 2021 15:06:09.092 * Background saving started by pid 247 247:C 12 Dec 2021 15:06:09.118 * DB saved on disk 245:M 12 Dec 2021 15:06:09.200 * Background saving terminated with success # 在有RDB文件的情況下打開Redis服務 服務端： 1240:M 12 Dec 2021 15:06:35.975 * Loading RDB produced by version 6.2.5 1240:M 12 Dec 2021 15:06:35.975 * RDB age 26 seconds 1240:M 12 Dec 2021 15:06:35.975 * RDB memory usage when created 0.48 Mb 1240:M 12 Dec 2021 15:06:35.976 * DB loaded from disk: 0.001 seconds 1240:M 12 Dec 2021 15:06:35.976 * Ready to accept connections
4：save m n自動持久化原理
Redis的save m n，是通過serverCron函數、dirty計數器、和lastsave時間戳來實現的。
serverCron：
是Redis服務器的周期性操作函數，默認每隔100ms執行一次；該函數對服務器的狀態進行維護，其中一項工作就是
檢查 save m n 配置的條件是否滿足，如果滿足就執行bgsave。
dirty：
計數器是Redis服務器維持的一個狀態，記錄了上一次執行bgsave/save命令后，服務器狀態進行了多少次修改(包括增刪改)；
而當save/bgsave執行完成后，會將dirty重新置為0。
例如：如果Redis執行了set name jack，則dirty值會+1；如果執行了sadd myset v1 v2 v3，則dirty值會+3；
注意dirty記錄的是服務器進行了多少次修改，而不是客戶端執行了多少修改數據的命令。
lastsave時間戳也是Redis服務器維持的一個狀態，記錄的是上一次成功執行save/bgsave的時間。
save m n的原理如下：
每隔100ms，執行serverCron函數；在serverCron函數中，遍歷save m n配置的保存條件，只要有一個條件滿足，
就進行bgsave。對於每一個save m n條件，只有下面兩條同時滿足時才算滿足：
lastsave > m
dirty >= n
5：RDB文件處理及修復
保存：RDB文件保存在dir配置指定的目錄下，文件名通過dbfilename配置指定。
config set dir {newDir} 臨時設置 rdb文件儲存目錄（注：日志和AOF文件存儲目錄也是引用此配置）
config set dbfilename {newFileName} 臨時設置rdb文件存儲的文件名稱（設置后下次自動持久化刷新啟用）
壓縮：Redis默認采用LZF算法對生成的RDB文件做壓縮處理，壓縮后的文件遠遠小於內存大小，
默認開啟，可以通過參數 config set rdbcompression {yes|no} 動態修改。
注：上面修改的配置若想永久修改則去配置文件更改！！
校驗：如果Redis加載損壞的RDB文件時拒絕啟動，並打印如下日志：
# Short read or OOM loading DB. Unrecoverable error, aborting now.
這時可以使用Redis提供的redis-check-dump工具檢測RDB文件並獲取對應的錯誤報告
三：AOF持久化
1：AOF持久化執行方式
默認都是自動觸發RDB持久化方式的，若想AOF持久化方式我們首先得去配置文件開啟此功能；appendonly yes 默認是未開啟；而AOF持久化的文件名則需要通過 appendfilename 來配置，默認AOF文件名稱為appendonly.aof；保存路徑同RDB持久化方式一致，通過dir配置指定。
AOF的執行方式是：只要執行增刪改命令就會執行一次追加操作，往 appendonly.aof 文件內追加增刪改命令
流程：
①：所有的增刪改命令會追加到aof_buf（AOF緩沖區）中。
②：根據不同的同步策略將aof_buf中的內容同步到硬盤。
③：隨着AOF文件越來越大，需要定期對AOF文件進行重寫，達到壓縮的目的。
④：當Redis服務器重啟時，可以加載AOF文件進行數據恢復。
AOF命令追加方式（append）：
Redis先將寫命令追加到緩沖區，而不是直接寫入文件，主要是為了避免每次有寫命令都直接寫入硬盤，導致硬盤IO成為Redis負載的瓶頸
命令追加的格式是Redis命令請求的協議格式，它是一種純文本格式，具有兼容性好、可讀性強、容易處理、操作簡單避免二次開銷等優點
具體格式略。在AOF文件中，除了用於指定數據庫的select命令（如select 0 為選中0號數據庫）是由Redis添加的，
其他都是客戶端發送來的寫命令。
2：AOF配置文件
# 是否開啟AOF日志記錄，默認redis使用的是rdb方式持久化，這種方式在許多應用中已經足夠用了，但是redis如果中途宕機， # 會導致可能有幾分鍾的數據丟失(取決於dump數據的間隔時間)，根據save來策略進行持久化， # Append Only File是另一種持久化方式， 可以提供更好的持久化特性，Redis會把每次寫入的數據在接收后都寫入 # appendonly.aof文件，每次啟動時Redis都會先把這個文件的數據讀入內存里，先忽略RDB文件。默認不啟用此功能 appendonly yes # 文本文件AOF的文件名，存放目錄在dir配置中配置 appendfilename "appendonly.aof" # aof持久化策略的配置（appendfsync屬性說明） # always： # 命令寫入aof_buf后立即調用系統fsync操作同步到AOF文件，fsync完成后線程返回。這種情況下，每次增刪改命令都要同步到AOF文件， # 這硬盤IO會成為性能瓶頸，Redis只能支持大約幾百TPS寫入，嚴重降低了Redis的性能；即便是使用固態硬盤（SSD），每秒大約也只能 # 處理幾萬個命令，而且會大大降低SSD的壽命。 # 總結：每次增刪改都執行fsync，以保證數據同步到磁盤,安全性高,但性能較差 # no： # 命令寫入aof_buf后調用系統write操作，不對AOF文件做fsync同步；同步由操作系統負責，通常同步周期為30秒。這種情況下， # 文件同步的時間不可控，且緩沖區中堆積的數據會很多，數據安全性無法保證。 # 總結：由操作系統保證數據同步到磁盤,Linux的默認fsync策略是30秒，最多會丟失30s的數據 # everysec： # 命令寫入aof_buf后調用系統write操作，write完成后線程返回；fsync同步文件操作由專門的線程每秒調用一次。 # everysec是前述兩種策略的折中，是性能和數據安全性的平衡，因此是Redis的默認配置，也是我們推薦的配置。 # appendfsync always appendfsync everysec # appendfsync no # 在AOF rewrite期間,是否對aof新記錄的append暫緩使用文件同步策略,主要考慮磁盤IO開支和請求阻塞時間 # no： # 表示"不暫緩",新的aof記錄仍然會被立即同步到磁盤，是最安全的方式，不會丟失數據，但是要忍受阻塞的問題 # yes： # 相當於將appendfsync設置為no，這說明並沒有執行磁盤操作，只是寫入了緩沖區，因此這樣並不 # 會造成阻塞（因為沒有競爭磁盤），但是如果這個時候redis掛掉，就會丟失數據。丟失多少數據呢？Linux # 的默認fsync策略是30秒，最多會丟失30s的數據,但由於yes性能較好而且會避免出現阻塞因此比較推薦rewrite # 即對aof文件進行整理,將空閑空間回收,從而可以減少恢復數據時間 no-appendfsync-on-rewrite no
# aof_current_size 和 aof_base_size 可以執行 info persistence 或直接 info # 執行AOF重寫時，當前AOF大小(即aof_current_size)和上一次重寫時AOF大小(aof_base_size)的比值；文件重寫觸發條件之一 auto-aof-rewrite-percentage 100 # 執行AOF重寫時，文件的最小體積，默認值為64MB。文件重寫觸發條件之一 auto-aof-rewrite-min-size 64mb # 是否加載由於某些原因導致的末尾異常的AOF文件(主進程被kill/斷電等)，建議yes aof-load-truncated yes # redis4.0新增RDB-AOF混合持久化格式，在開啟了這個功能之后，AOF重寫產生的文件將同時包含RDB格式的內容和AOF格式的內容， # 其中RDB格式的內容用於記錄已有的數據，而AOF格式的內容則用於記錄最近發生了變化的數據，這樣Redis就可以同時兼有RDB持 # 久化和AOF持久化的優點（既能夠快速地生成重寫文件，也能夠在出現問題時，快速地載入數據）,默認為no,即不啟用此功能 aof-use-rdb-preamble yes
3：AOF文件重寫（rewrite）
隨着時間流逝，Redis服務器執行的寫命令越來越多，AOF文件也會越來越大；過大的AOF文件不僅會影響服務器的正常運行，
也會導致數據恢復需要的時間過長。
文件重寫是指定期重寫AOF文件，減小AOF文件的體積。需要注意的是，AOF重寫是把Redis進程內的數據轉化為寫命令，
同步到新的AOF文件；不會對舊的AOF文件進行任何讀取、寫入操作!
關於文件重寫需要注意的另一點是：對於AOF持久化來說，文件重寫雖然是強烈推薦的，但並不是必須的；即使沒有文件重寫，
數據也可以被持久化並在Redis啟動的時候導入；因此在一些實現中，會關閉自動的文件重寫，然后通過定時任務在每天的某一時刻定時執行。
文件重寫之所以能夠壓縮AOF文件，原因在於：
①：過期的數據不再寫入文件
②：無效的命令不再寫入文件：如有些數據被重復設值(set name jack, set name tom)、
有些數據被刪除了(sadd myset v1, del myset)等等
③：多條命令可以合並為一個：如sadd myset v1, sadd myset v2, sadd myset v3可以合並為sadd myset v1 v2 v3
不過為了防止單條命令過大造成客戶端緩沖區溢出，對於list、set、hash、zset類型的key，並不一定只使用一條命令；
而是以某個常量為界將命令拆分為多條。
這個常量在redis.h/REDIS_AOF_REWRITE_ITEMS_PER_CMD中定義，不可更改，3.0版本中值是64。
通過上述內容可以看出，由於重寫后AOF執行的命令減少了，文件重寫既可以減少文件占用的空間，也可以加快恢復速度
4：文件重寫的觸發（手動觸發）
直接調用bgrewriteaof命令，該命令的執行與bgsave有些類似，都是fork子進程進行具體工作，且都只有在fork時阻塞
執行手動觸發AOF文件重寫 客戶端： 127.0.0.1:6379> bgrewriteaof Background append only file rewriting started 服務端： 1751:M 12 Dec 2021 20:33:45.401 * Background append only file rewriting started by pid 1753 1751:M 12 Dec 2021 20:33:45.736 * AOF rewrite child asks to stop sending diffs. 1753:C 12 Dec 2021 20:33:45.752 * Parent agreed to stop sending diffs. Finalizing AOF... 1753:C 12 Dec 2021 20:33:45.754 * Concatenating 0.00 MB of AOF diff received from parent. 1753:C 12 Dec 2021 20:33:45.769 * SYNC append only file rewrite performed 1751:M 12 Dec 2021 20:33:45.845 * Background AOF rewrite terminated with success 1751:M 12 Dec 2021 20:33:45.848 * Residual parent diff successfully flushed to the rewritten AOF (0.00 MB) 1751:M 12 Dec 2021 20:33:45.863 * Background AOF rewrite finished successfully
5：文件重寫的觸發（自動觸發）
自動觸發是根據auto-aof-rewrite-min-size和auto-aof-rewrite-percentage配置參數，以及aof_current_size和aof_base_size狀態確定觸發時機
auto-aof-rewrite-min-size：
執行AOF重寫時，文件的最小體積，默認值為64MB。
auto-aof-rewrite-percentage：
執行AOF重寫時，當前AOF大小(即aof_current_size)和上一次重寫時AOF大小(aof_base_size)的比值
可以通過config get命令查看：
127.0.0.1:6379[12]> config get auto-aof-rewrite-percentage 1) "auto-aof-rewrite-percentage" 2) "100" -- 百分比 100% 127.0.0.1:6379[12]> config get auto-aof-rewrite-min-size 1) "auto-aof-rewrite-min-size" 2) "67108864" -- 大小 64M
狀態可以通過info persistence查看：(其它狀態這里不介紹了)
aof_base_size：上一次重寫后AOF文件空間
aof_current_size：當前AOF文件空間
只有當auto-aof-rewrite-min-size和auto-aof-rewrite-percentage兩個參數同時滿足時，
才會自動觸發AOF重寫，即bgrewriteaof操作
自動觸發條件：
aof_current_size > auto-aof-rewrite-min-size && (aof_current_size - aof_base_size) / aof_base_size >= auto-aof-rewrite-percentage
為了看執行效果我修改參數： auto-aof-rewrite-percentage 1 auto-aof-rewrite-min-size 1mb 當AOF達到大小峰值則會自動執行重寫；然會重寫后的aof文件會壓縮的特別小 Redis服務器觸發 自動重寫 日志： 1611:M 13 Dec 2021 13:51:45.941 * Starting automatic rewriting of AOF on 105343400% growth 1611:M 13 Dec 2021 13:51:45.986 * Background append only file rewriting started by pid 1621 1611:M 13 Dec 2021 13:51:46.594 * AOF rewrite child asks to stop sending diffs. 1621:C 13 Dec 2021 13:51:46.610 * Parent agreed to stop sending diffs. Finalizing AOF... 1621:C 13 Dec 2021 13:51:46.610 * Concatenating 0.02 MB of AOF diff received from parent. 1621:C 13 Dec 2021 13:51:46.616 * SYNC append only file rewrite performed 1611:M 13 Dec 2021 13:51:46.671 * Background AOF rewrite terminated with success 1611:M 13 Dec 2021 13:51:46.674 * Residual parent diff successfully flushed to the rewritten AOF (0.00 MB) 1611:M 13 Dec 2021 13:51:46.681 * Background AOF rewrite finished successfully
6：文件重寫流程
文件重寫的流程，注意點：
①：重寫由父進程fork出一個子進程進行持久化
②：重寫期間Redis執行的寫命令，需要追加到新的AOF文件中，為此Redis引入了aof_rewrite_buf緩存
對照上圖，文件自動重寫的流程如下：
1：Redis父進程首先判斷當前是否存在正在執行 bgsave/bgrewriteaof的子進程，如果存在則bgrewriteaof命令直接返回，
如果存在bgsave命令則等bgsave執行完成后再執行。前面曾介紹過，這個主要是基於性能方面的考慮。
如果當前進程正在執行AOF（bgrewriteaof）重寫，請求不執行並返回如下響應：
ERR Background append only file rewriting already in progress
如果當前進程正在執行bgsave操作，重寫命令延遲到bgsave完成之后再執行，返回如下響應：
Background append only file rewriting scheduled
2：父進程執行fork操作創建子進程，這個過程中父進程是阻塞的（開銷等同於bgsave過程）
3.1：父進程fork后，bgrewriteaof命令返回”Background append only file rewrite started”信息；
同時不再阻塞父進程，並可以繼續響應其它命令；所有增刪改命令依然寫入AOF緩沖區並根據appendfsync策略同步到硬盤， 保證原有AOF機制正確性。
3.2：由於fork操作使用寫時復制技術，子進程只能共享fork操作時的內存數據。由於父進程依然在響應命令，因此Redis使用AOF重寫 緩沖區(圖中的aof_rewrite_buf)保存這部分數據，防止新AOF文件生成期間丟失這部分數據。也就是說，bgrewriteaof執行期間 Redis的寫命令同時追加到aof_buf和aof_rewirte_buf兩個緩沖區。
4：子進程根據內存快照，按照命令合並規則寫入到新的AOF文件。每次批量寫入硬盤數據量由配置aof-rewrite-incremental-fsync控制
默認為32MB，防止單次刷盤數據過多造成硬盤阻塞。
5.1：子進程寫完新的AOF文件后，向父進程發信號，父進程更新統計信息，具體可以通過info persistence查看。
5.2：父進程把AOF重寫緩沖區的數據寫入到新的AOF文件，這樣就保證了新AOF文件所保存的數據庫狀態和服務器當前狀態一致。
5.3：使用新的AOF文件替換老文件，完成AOF重寫
8：文件校驗與AOF文件修復
文件校驗啟動：
127.0.0.1:6379> config get aof-load-truncated -- 跳過AOF文件末尾不完整
1) "aof-load-truncated"
2) "yes"
AOF和RDB文件載入類似，Redis載入AOF文件時會對AOF文件進行校驗，若發現文件損壞時（就是被修改了），則日志會打印
錯誤，Redis啟動也就失敗了;
若AOF文件是因為文件結尾不完整（Redis服務器突然宕機斷電），且AOF配置的 aof-load-truncated 為yes(默認)時，
則會忽略文件結尾的不完整，並在日志中輸出警告；（注意：只能是結尾+行被損壞，不能修改或者跳行刪除）
450:M 14 Dec 2021 09:40:41.141 # Server initialized
450:M 14 Dec 2021 09:40:41.142 # !!! Warning: short read while loading the AOF file !!!
450:M 14 Dec 2021 09:40:41.142 # !!! Truncating the AOF at offset 90 !!!
450:M 14 Dec 2021 09:40:41.144 # AOF loaded anyway because aof-load-truncated is enabled
450:M 14 Dec 2021 09:40:41.145 * DB loaded from append only file: 0.003 seconds
450:M 14 Dec 2021 09:40:41.146 * Ready to accept connections
若aof文件被損壞到無法啟動則需要AOF文件修復：
注：AOF文件修復會定位到出錯的那一行知道最后一行全部剔除刪掉（備份后妥善操作）
使用Redis 附帶的 redis-check-aof 程序，對原來的 AOF 文件進行修復，進而再啟動redis
Linux下操作：redis-check-aof --fix 待修復的AOF文件
Windows下操作：
PS C:\Users\redis-x64-6.2.5> .\redis-check-aof.exe --fix .\appendonly.aof
0x 56: Expected \r\n, got: 3233
AOF analyzed: size=113, ok_up_to=60, ok_up_to_line=19, diff=53
This will shrink the AOF from 113 bytes, with 53 bytes, to 60 bytes
Continue? [y/N]: y
Successfully truncated AOF
四：重啟加載
AOF和RDB文件都可以用於Redis服務器重啟時的數據恢復；但是Redis啟動時會優先載入AOF文件來恢復數據，只有當AOF關閉時，才會載入RDB文件恢復數據
當AOF持久化關閉時，且無 .RDB持久化文件
1775:M 13 Dec 2021 18:07:47.923 # Server initialized
1775:M 13 Dec 2021 18:07:47.924 * Ready to accept connections
當AOF持久化關閉時，且有 .RDB持久化文件 -- 沒有文件則不讀取
80:M 13 Dec 2021 18:08:38.896 # Server initialized
80:M 13 Dec 2021 18:08:38.897 * Loading RDB produced by version 6.2.5
80:M 13 Dec 2021 18:08:38.897 * RDB age 5 seconds
80:M 13 Dec 2021 18:08:38.897 * RDB memory usage when created 0.51 Mb
80:M 13 Dec 2021 18:08:38.897 * DB loaded from disk: 0.001 seconds
80:M 13 Dec 2021 18:08:38.898 * Ready to accept connections
當AOF持久化開啟時，且無 .AOF持久化文件 -- 沒有文件則不讀取
515:M 13 Dec 2021 18:09:36.702 # Server initialized
1515:M 13 Dec 2021 18:09:36.704 * Ready to accept connections
當AOF持久化開啟時，且有 .AOF持久化文件(注：若.AOF文件為空則和無.AOF文件一樣不執行) 178:M 13 Dec 2021 18:10:08.803 # Server initialized
178:M 13 Dec 2021 18:10:08.804 * DB loaded from append only file: 0.001 seconds
178:M 13 Dec 2021 18:10:08.804 * Ready to accept connections
五：AOF和RDB優缺點
RDB持久化：
優點：RDB文件緊湊，體積小，網絡傳輸快，適合全量復制；恢復速度比AOF快很多。當然，與AOF相比，RDB最重要的優點之一是對性能的影響相對較小。
缺點：RDB文件的致命缺點在於其數據快照的持久化方式決定了必然做不到實時持久化，而在數據越來越重要的今天，數據的大量丟失很多時候是無法接受的，因此AOF持久化成為主流。此外，RDB文件需要滿足特定格式，兼容性差（如老版本的Redis不兼容新版本的RDB文件）。
AOF持久化：
與RDB持久化相對應，AOF的優點在於支持秒級持久化、兼容性好，缺點是文件大、恢復速度慢、對性能影響大。