前言：Redis的數據都存放在內存中，若沒有配置持久化，Redis重啟后對丟失數據，所以需要開啟Redis的持久化功能，將數據保存在磁盤，當Redis重啟后，就能從磁盤中恢復數據
Redis的兩種持久化方式
- RDB持久化
- AOF持久化
AOF（append only file）持久化記錄每次對服務器的寫操作，當服務器重啟后會重新執行這些命令來恢復原始的數據
3.1 RDB持久化
RDB持久化：在指定的時間間隔對數據進行快照存儲（以二進制進行存儲，磁盤占用小，加載速度快）
客戶端直接通過命令BGSAVE或者SAVE來創建一個內存快照
RDB持久化方式能夠在指定的時間間隔對你的數據進行快照存儲。
客戶端直接通過命令BGSAVE或者SAVE來創建一個內存快照
- BGSAVE：BGSAVE調用fork創建一個子進程，子進程負責將快照寫入磁盤，而父進程仍然能夠繼續處理命令（但是調用Fork函數時也會阻塞）
- SAVE：Redis在執行SAVE指令的過程中，不會fork子進程，所以此時Redis不能響應其它指令
bgsave的寫時復制機制
通過查看后臺進程能查看到主進程fork出了名為redis-rdb-bgsave的子進程，bgsave子進程借助操作系統提供的寫時復制（Copy-On-Write），在生成快照的同時，主進程依舊可以正常處理寫入指令；
大概過程：**子進程共享父進程的所有內存數據，若持久化RDB過程中都是讀操作，則父子進程互不影響；若有寫操作，子進程是先將數據寫入一個臨時文件，待持久化結束再用臨時文件替換掉持久化好的文件，整個過程中主進程不進行任何文件IO，確保主服務的性能
注意：Redis單線程，并不是說Redis服務端只會啟動一個進程干活，實際上會有其它的后臺進程進行其它操作
還有兩種情況會觸發RDB持久化
1）shutdown（在沒開啟AOF的情況下）
2）flushall
Redis持久化策略配置
默認情況下，RDB持久化將數據保存在名為dump.rdb的二進制文件中
在redis.conf中可調整RDB的持久化策略，當規定時間內，Redis發生了寫操作的個數滿足條件就會觸發BGSAVE命令（上生產優化時，一般留一條即可）
# The filename where to dump the DB
dbfilename "dump.rdb"
# rdb文件保存在dir指定的目錄
dir "./"
# 900秒內至少1次增刪改操作
save 900 1
# 300秒內至少10次增刪改操作
save 300 10
# 60秒內至少10000次增刪改操作
save 60 10000
# 若想禁用RDB持久化，則將save全都注釋掉，或者save “”也行，進行主從復制時無法關閉RDB持久化，因為主節點是通過發送RDB文件發給從節點進行主從復制的
數據丟失的情況是假設當前這樣的配置，60秒只有幾次數據的插入不超過10000次寫操作，此時Redis被kill掉了，這時候數據就不會被記錄下來。重新啟動數據就已經丟失了。
RDB持久化的優缺點
| 優點 | 缺點 |
|---|---|
| 對性能影響最小 | 同步時丟失數據 |
| RDB文件進行數據恢復比使用AOF要快很多 | 如果數據集非常大且CPU不夠強（比如單核CPI），Redis在fork子進程的時候可能會消耗相對較長的時間，影響Redis對外提供服務的能力 |
3.2 AOF持久化
為什么有了RDB持久化還需要AOF持久化？
因為RDB持久化不可靠，沒有達到RDB持久化的要求，所以丟失會較多
為了解決RDB持久化的不可靠問題，Redis官方提供了AOF持久化是將Redis的操作日志以日志追加的方式寫入文件，讀操作不需要進行記錄，這樣大大減少數據的丟失
bgrewriteaof
使用bgrewriteaof能夠將一系列指令進行合并（如set count 10 set count 20直接合并為set count 20）
AOF核心配置
# 開啟AOF持久化
appendonly yes
# AOF策略
# 只要有數據修改發生時都會寫入AOF文件（缺點：影響性能，但丟失數據少）
appendfsync always
# 每秒鐘同步一次，該策略為AOF的缺省策略（最多丟失1秒的數據）（推薦使用）
appendfsync everysec
# 等操作系統進行數據緩存同步到磁盤（快，但持久化沒保障）（生產不建議用）
appendfsync no
AOF持久化的優缺點
| 優點 | 缺點 |
|---|---|
| 最安全 | 文件體積大 |
| 容災 | 性能消耗比RDB大 |
| 文件內容易讀，可修改 | 數據恢復速度比RDB慢 |
開啟AOF持久化后實現效果
*2：表示接下來有兩個元素（此處指的是select 和 0）
$6：表示命令的長度是6個char（此處指的select）
兩種持久化機制是可以同時開啟的，但是會優先加載AOF文件，加載過程如下
3.2 AOF的混合持久化機制
為了解決AOF文件重新加載慢的問題，Redis 4.0之后引入了混合持久化機制，對AOF持久化進行了增強。
# 開啟混合持久化機制（Redis 4.0后混合持久化默認關閉，redis 5.0之后默認開啟）
aof-use-rdb-preamble yes
混合持久化是通過bgrewriteaof完成，不同的是當開啟混合持久化時，fork出的子進程先將共享的內存副本全量以RDB方式寫入AOF文件中，然后將重寫緩沖區的增量命令以AOF文件替換舊的AOF文件，簡單說，即新的AOF文件前半段是以RDB格式的全量數據后半段則是AOF格式的增量數據（重寫也會fork子進程）
何時進行bgrewriteaof？
當AOF文件增長到一定的程度時進行重寫，有兩個配置可以控制
# 當后面AOF文件大小增長比例大于以下配置時進行重寫
auto-aof-rewrite-percentage 100
# 第一次，當AOF文件增長到以下大小（默認64mb，生產建議改為3gb）
auto-aof-rewrite-min-size 64mb
混合持久化模式的優缺點
優點：混合持久化結合了RDB持久化和AOF持久化的有點，由于大部分都是RDB格式，所以加載速度快，同時結合AOF，以增量的方式保存，數據丟失更少
缺點：兼容性差，一旦開啟混合持久化，在4.0之前的版本不能識別該AOF文件，且前半部分的AOF文件的可讀性差
