上篇我們主要從分析了redis的線程模型，本篇我們來看看redis的持久化。
一起探討redis持久化
爲什麼要持久化
前面說過redis是一個內存數據庫，那東西放在內存好好的爲什麼要持久化呢？想想如果宕機了咋辦，重啓一下，啥也沒了，雪崩了，所有的流量打到DB，後果難以想象。關於緩存雪崩、穿透、擊穿的話題後面的文章會講到，謝謝大家。
怎麼持久化
啓動redis
./redis-server /usr/local/redis-5.0.8/etc/redis.conf
3473:C 10 Apr 2020 21:36:52.521 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
3473:C 10 Apr 2020 21:36:52.521 # Redis version=5.0.8, bits=64, commit=00000000, modified=0, pid=3473, just started
3473:C 10 Apr 2020 21:36:52.521 # Configuration loaded
[root@localhost bin]# ./redis-cli
127.0.0.1:6379> set rdbvalue value
OK
127.0.0.1:6379> shutdown
not connected> quit
客戶端主動shutdown的時候會主動保存一次dump.rdb
save 900 1
save 300 10
save 60 10000
save <指定時間間隔> <執行指定次數更新操作>，滿足條件就將內存中的數據同步到硬盤中。官方出廠配置默認是 900秒內有1個更改，300秒內有10個更改以及60秒內有10000個更改，則將內存中的數據快照寫入磁盤。
若不想用RDB方案，可以把 save “” 的註釋打開，下面三個註釋。
RDB有阻塞式save（不能接受其他命令）和非阻塞式bgsave（Redis進程執行fork操作創建子進程，RDB持久化過程由子進程負責）
優勢
1.RDB是一個非常緊湊(compact)的文件，它保存了redis 在某個時間點上的數據集。這種文件非常適合用於進行備份和災難恢復。
2.生成RDB文件的時候，redis主進程會fork()一個子進程來處理所有保存工作，主進程不需要進行任何磁盤IO操作。
3.RDB 在恢復大數據集時的速度比 AOF 的恢復速度要快。
劣勢
1、RDB方式數據沒辦法做到實時持久化/秒級持久化。因爲bgsave每次運行都要執行fork操作創建子進程，屬於重量級操作，如果不採用壓縮算法(內存中的數據被克隆了一份，大致2倍的膨脹性需要考慮)，頻繁執行成本過高(影響性能)
2、RDB文件使用特定二進制格式保存，Redis版本演進過程中有多個格式的RDB版本，存在老版本Redis服務無法兼容新版RDB格式的問題(版本不兼容)
3、在一定間隔時間做一次備份，所以如果redis意外down掉的話，就會丟失最後一次快照後的所有修改(數據有丟失)
企業中一般會每天夜間拷貝一份rdb文件到另一臺主機以備容災，文件名字爲當天日期
RDB如果redis意外down掉的話，就會丟失最後一次快照後的所有修改，那怎麼辦。
我們瞭解一下另一種持久化方式AOF
appendonly yes
appendfilename "appendonly.aof"
appendfsync everysec
看，已經有命令追加在aof文件裏面了。
appendonly：是否打開 AOF 持久化功能
appendfilename：AOF 文件名稱
appendfsync：同步頻率
對於同步頻率有三種方式
always：redis執行每個寫命令時，都同步寫入硬盤，這樣會嚴重降低redis性能；
everysec：每秒執行一次，顯示的在這一秒內執行的寫命令同步到硬盤；
no：不同步到硬盤（讓操作系統來決定何時進行同步）。
AOF原理主要是兩塊
1、AOF追加網絡協議格式的文本內容
aof_buf來延遲同步磁盤，加快相應。
always阻塞式同步。
everysec啓用子進程同步。
2、AOF重寫
合併命令，多條變一條來壓縮aof文件。
aof_rewrite_buf保證當前正在執行的命令也不丟失
子進程重寫，只有在下面a、b這兩步阻塞主進程。
a.將 AOF 重寫緩存中的內容全部寫入到新 AOF 文件中。
b.對新的 AOF 文件進行改名，覆蓋原有的 AOF 文件。
這兩種方式選哪一種呢？？？
企業中一般同時使用，你單獨用RDB你會丟失很多數據，你單獨用AOF，你數據恢復沒RDB來的快，真出什麼時候第一時間用RDB恢復，然後AOF做數據補全。
持久化雖然保證了單機宕機後的恢復能力，但是仍然會導致一段時間服務不可用。那該如何是好呢？