前言
溫故而知新！學習本來就是一個不斷重複記憶，不斷加深理解的過程。本篇對於已經學習過的redis知識點做個記錄。
兩種不同的持久化方法
- 快照方式
優點：它將存在於某一時刻的所有數據都寫入到硬盤裏面。在創建快照之後，用戶可以對快照進行備份，可以將快照複製到其他服務器作爲副本，還可以將快照留在原地以便重啓服務器時使用。
缺點：由於創建快照是有時間間隔的，如果在某一次創建快照期間，系統，redis或者硬件發生崩潰，那麼Redis將丟失最近一次創建快照之後寫入的所有數據。
創建快照的方法：
1.客戶端向Redis發送BGSAVE命令來創建一個快照，Redis會調用fork來創建一個子進程，然後子進程負責將快照寫入硬盤，而父進程則繼續處理命令請求。
2.客戶端可以向Redis發送SAVE命令創建快照，但是在創建快照期間不再響應其他任何命令。一般不常用這個命令。
3.可以通過設置save配置選項，比如save 60 1000，表示從第一次創建快照之後開始算起，當60秒之內有1000次寫入時，Redis就會自動觸發BGSAVE命令。如果設置多個save配置，那麼當任意一個save配置選項條件被滿足時，Redis就會觸發一次BGSAVE命令。
4.當Redis通過SHUTDOWN命令接收到關閉服務器的請求時，或者接收到標準TERM信號時，會執行一個SAVE命令，阻塞所有客戶端，SAVE命令執行完畢後關閉服務器。
5.當一個Redis服務器連接另一個Redis服務器，並向對方發送SYNC命令來開始一次複製操作的時候，如果主服務器目前沒有在執行BGSAVE操作，或者主服務器並非剛剛執行完BGSAVE操作，那麼主服務器就會執行BGSAVE命令。
常用配置：
//當60秒內，執行至少1000條寫操作會執行BGSAVE命令
save 60 1000
//即當bgsave快照操作出錯時是否停止寫數據到磁盤，如果爲yes這樣後面寫錯做均會失敗，爲了不影響後續寫操作，故需將該項值改爲no
stop-writes-on-bgsave-error no
//指定存儲至本地數據庫時是否壓縮數據，默認是yes，redis採用LZF壓縮，如果爲了節省CPU時間可以關閉該選項，但會導致數據庫文件變的巨大
rdbcompression yes
//設置持久化文件名
dbfilename dump.rdb
- AOF持久化
如果不能忍受快照所造成的短期數據丟失，那麼可以使用AOF儘快的將數據保存到硬盤裏面。AOF是將被執行的命令寫入到AOF文件的末尾，因此，只要Redis從頭到尾執行一遍文件所包含的所有命令，就可以恢復所有的數據。
//打開AOF
appendonly yes
//配置保存命令的頻率
appendfsync always 每個redis寫命令都要寫入硬盤，但會嚴重降低Redis速度
appendfsync everysec 每秒進行一次同步，將多個寫命令寫入到磁盤
appendfsync no 讓操作系統決定該何時同步
如果使用appendfsync always，那麼對於固態硬盤來說可能會發生寫入放大問題，因爲要不斷對硬盤進行寫入操作，所以會使Redis速度大大降低，所以建議一般使用appendfsync everysec比較好。
重寫/壓縮AOF文件
既然AOF速度又快，丟失文件數量也小，那麼爲什麼不直接使用這種而不把快照方式捨去呢？那是因爲AOF因爲一直將寫命令拼寫到文件末尾，導致文件一直增大，甚至會佔滿整個磁盤。並且，當Redis使用AOF文件進行數據恢復的時候，由於文件太大，導致恢復時間非常長。
- 解決方式
用戶可以向Redis發送BGREWRITEAOF命令，該命令會移除AOF中冗餘的命令，使文件儘可能的小。同時它的機制和BGSAVE命令相似：fork()出一個子進程用來處理相關操作。
相關配置如下：
//在開啓aof前提下，如果aof文件大於64mb並且比上一次增長了100%，那麼會進行一次BGREWRITEAOF操作
//auto-aof-rewrite-percentage可以設置大於100，防止rewriete過於頻繁，但是恢復時間會變長
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
最後儘管有這兩種自動持久化方案，但是還是需要經常手動備份數據到多個地方！