redis持久化篇-04
redis的持久化即redis提供的RDB持久化和AOF持久化。
RDB
RDB即redis database。redis會在從配置檔案中(redis.conf)讀取資料，然後按照配置檔案中指定的時間間隔，指定的觸發條件，然後將記憶體中的資料集快照寫入磁碟，即為snapshot快照。恢復時將快照檔案直接讀取到記憶體中。
執行流程：
- Redis會單獨建立（fork）一個子程序來進行持久化，會先將記憶體中的所有資料寫入到 一個臨時檔案中。
- 整個過程中，主程序是不進行任何IO操作的，繼續處理client請求。
- 待持久化過程都結束了，再用這個臨時檔案替換上次持久化好的檔案。
所以！！RDB持久化機制每次快照持久化都是將記憶體資料完整寫入到磁碟一次，並不 是增量的只同步髒資料！！大量的寫操作可能影響效能
什麼是Fork？
Fork的作用是複製一個與當前程序一樣的程序。新程序的所有資料（變數、環境變數、程式計數器等）數值都和原程序一致，但是是一個全新的程序，並作為原程序的子程序
所以！！RDB持久化機制有子程序和父程序
RDB的相關知識：
redis會從配置檔案中的SNAPSHOTTING模組讀取對於RDB持久化機制的相關配置。
RDB預設儲存的資料檔案是dump.rdb,預設當前路徑下
RDB的預設觸發條件是：
1). save 900 1 即900秒內，如果有1個key被修改，即進行快照操作
2). save 300 10 即300秒內，如果有10個key被修改，即進行快照操作
3).save 60 10000 即60秒內，如果有10000個key被修改，即進行快照操作使用者可以通過save命令和bgsave命令進行提前觸發RDB機制
1). save命令是在主執行緒上儲存快照的。redis的主執行緒是用來幹嘛的？用來處理redis client請求的。save儲存到只管儲存，其他不管，這樣必將會堵塞其他所有client請求
2). bgsave命令：Redis會在後臺非同步進行快照操作，快照同時還可以響應客戶端請求。可以通過lastsave命令獲取最後一次成功執行快照的時間執行flushall命令後，也會觸發RDB機制，會產生dump.rdb檔案覆蓋掉原本的持久化檔案，但是這個持久化檔案是空的，沒有任何資料！
RDB持久化檔案如何恢復？
當client到來，redis會根據配置檔案中配置的地址和檔名找到rdb持久化檔案,自動將其掃描進記憶體，所以只需要把rdb持久化檔案放置到配置檔案中指定的位置，命名為指定的檔名即可進行恢復。
預設：redis安裝目錄當前位置下的dump.rdb檔案。為了防止產生意外，備份了一份rdb檔案。在恢復的時候只需要放置在這個位置即可
RDB優勢和劣勢？
優勢
- 方便備份，RDB的執行原理意味著會產生一份資料RDB檔案，可以很簡單容易的歸檔，整理，或者移動位置。
- 適合大規模的資料恢復，因為是直接讀取到記憶體中的，相比AOF機制要快
- 最大化redis的效能；有父子程序，各自負責不同的方面
- 對資料完整性和一致性要求不高
劣勢
- RDB的持久化機制是一段時間做一次備份(儲存點)，如果在最後一次還沒備份的話，redis產生意外，那麼會丟失最後一次快照的所有修改操作
- RDB是有父程序和子程序的。子程序的所有東西都和父程序一模一樣，那就意味著在記憶體中的資料會被克隆一份。同樣的資料會有兩份，兩倍的膨脹量。
AOF
aof即Append Only File。相關配置在redis的Append Only File模組中有。AOF持久化機制是以日誌的形式來記錄每個寫操作，將Redis執行過的所有寫指令記錄下來(讀操作不記錄)，只許追加檔案但不可以改寫檔案！！
注意，是追加操作，與RDB全部資料重新覆蓋不同
執行流程：
redis啟動之初會讀取日誌檔案中的寫命令在記憶體中重新構造資料。換言之，redis重啟的話就根據日誌檔案的內容將寫指令從前到後執行一次以完成資料的恢復工作。所以這也是AOF在資料恢復上不如RDB快的原因
AOF的相關知識：
AOF預設儲存的日誌檔案是appendonly.aof,預設當前路徑下
AOF觸發同步寫入日誌檔案的條件：AOF有三種觸發策略，根據你在配置檔案配置項的不同，會重新整理日誌檔案，追加更改資料的命令
1).appendfsync always 每修改同步，同步持久化 每次發生資料變更會被立即記錄到磁碟 效能較差但資料完整性比較好
2).appendfsync everysec 每秒同步，非同步持久化 如果一秒內宕機，有資料丟失
3).appendfsync no 從不同步redis的AOF持久化機制預設是關閉的，需要在配置檔案中將appendonly屬性設為yes將AOF機制啟動
- AOF的恢復預設只需要在當前路徑下存在一個appendonly.aof這個檔案，即可。redis會根據日誌檔案中的修改命令重構整個資料機構。
- 如果AOF檔案或者RDB檔案遭受損壞，或者在檔案中語句有錯，無法排查。可以使用命令進行異常修復。同理RDB也有一條命令可以進行異常修復
redis-check-aof --flx AOF檔名redis-check-dump --flx dump檔名這兩個命令實際是呼叫兩個檔案，這兩個檔案在你當前目錄存在，與AOF檔案和ROB檔案同個目錄下
AOF的rewrite（重寫）機制
AOF採用檔案追加方式，檔案會越來越大為避免出現此種情況，新增了重寫機制.
當AOF檔案的大小超過所設定的閾值時，Redis就會啟動AOF檔案的內容壓縮，只保留可以恢復資料的最小指令集.可以使用命令bgrewriteaof提前觸發
重寫原理：
AOF檔案持續增長而過大時，會fork出一條新程序來將檔案重寫(也是先寫臨時檔案最後再rename)，
遍歷新程序的記憶體中資料，每條記錄有一條的Set語句。重寫aof檔案的操作，並沒有讀取舊的aof檔案，而是將整個記憶體中的資料庫內容用命令的方式重寫了一個新的aof檔案，這點和快照有點類似
觸發機制
Redis會記錄上次重寫時的AOF大小，預設配置是當AOF檔案大小是上次rewrite後大小的一倍且檔案大於64M時觸發
AOF優勢和劣勢？
優勢
- 相較RDB，AOF對資料的一致性和完整性的支援更高，但仍然可能丟失最後一秒的資料
劣勢
- 相同的資料集，AOF檔案大小要大於RDB檔案，恢復速度也要慢於ROB
- AOF的每修改同步策略執行效率低於RDB，因為RDB是父子程序，非同步。但每秒同步策略效率較高，不同步策略與RDB相同
持久化篇總結
- RDB持久化方式能夠在指定的時間間隔能對你的資料進行快照儲存
- AOF持久化方式記錄每次對伺服器寫的操作,當伺服器重啟的時候會重新執行這些命令來恢復原始的資料,AOF命令以redis協議追加儲存每次寫的操作到檔案末尾.Redis還能對AOF檔案進行後臺重寫,使得AOF檔案的體積不至於過大
- 支援同時開啟兩種持久化方式
- 在這種情況下,當redis重啟的時候會優先載入AOF檔案來恢復原始的資料,因為在通常情況下AOF檔案儲存的資料集要比RDB檔案儲存的資料集要完整
- DB的資料不實時，同時使用兩者時伺服器重啟也只會找AOF檔案。那要不要只使用AOF呢？建議不要，因為RDB更適合用於備份資料庫