why：
redis一般作為緩存使用，從而提供系統的整體性能。redis是以內存請求為主的nosql DB，在重啟、或者宕機的情況，如何確保數據不丟失，並且快速恢復，是redis的一大挑戰。
How：
redis主要有兩大方案保障數據的安全，分別是：RDB(redis data base)和AOF(append only file)。
what:
RDB:
就是所謂的“內存快照”，記錄了redis某個時間點的內存數據，並以文件的形式存儲在磁盤中。在redis重啟是，能夠使用RDB直接恢復內存數據。執行流程如下：
這樣就可以不用每次寫操作，都需要寫磁盤，只需要在某個時間點寫一次數據就可以了，同時RDB 采用二進制 + 數據壓縮的方式寫磁盤，文件體積小，數據恢復速度快。但是會出現數據丟失的問題（2次快照之間的數據，並沒有落到磁盤上）。如果RDB的頻率很高，例如1S1次，會加重磁盤的負擔，從而降低性能。
執行方式：有同步(save)和異步(bgsave)。
save是主線程執行的，會阻塞redis；
bgsave主線程會fork一個子線程來完成，剛fork出的子線程和主線程是數據和代碼共享的（所以在進程分離的一瞬間，內存的增長幾乎沒有明顯變化），只有在主線程有寫操作時，才會產生不同的數據。如圖：
為了確保子線程做快照時，主線程還能寫入數據。采用的方案是COW（copy on write），即：當主線程執行寫指令修改數據的時候，這個數據就會復制一份副本， bgsave 子進程讀取這個副本數據寫到 RDB 文件。
AOF：
只記錄了redis中寫操作的順序指令。這樣恢復時，只需將寫操作執行一遍（也叫重放），數據就可以恢復了。
redis采用記錄方案：
采用“寫后日志”，即：先執行寫操作，內存寫成功后，再記錄日志（對比是：寫前日志（Write Ahead Log, WAL），即： 在實際寫數據之前，將修改的數據寫到日志文件中，故障恢復得以保證）。操作流程如下：
“寫后日志”好處是：不需要做指令檢查，對當前指令沒有阻塞(但是寫磁盤動作，可能影響下1條指令)。
日志格式：
「*3」：表示當前指令分為三個部分，每個部分都是 「$ + 數字」開頭，緊跟后面是該部分具體的「指令、鍵、值」。數字」：表示這部分的命令、鍵、值占用多少字節大小。比如 「$3」表示這部分包含 3 個字節，也就是 「set」指令。具體如下圖：
數據落盤方案：
always：同步寫回，寫指令執行完畢立馬將 aof_buf緩沖區中的內容刷寫到 AOF 文件。
everysec：每秒寫回，寫指令執行完，日志只會寫到 AOF 文件緩沖區，每隔一秒就把緩沖區內容同步到磁盤。
no： 操作系統控制，寫執行執行完畢，把日志寫到 AOF 文件內存緩沖區，由操作系統決定何時刷寫到磁盤。
where（方向）：
1、AOF文件過大，影響恢復效率：
引入“AOF重寫”機制。redis使用bgrewriteaof指令對AOF日志文件進行瘦身。
原理：redis啟動一個子線程（bgrewriteaof）對內存進行遍歷，從而生成一系列的操作指令，並將這些操作指令序列化到新AOF文件中（新的aof文件，是防止AOF重寫失敗污染了原來的數據）。序列化完畢后，會將開始序列化到當前時間的增量AOF文件，追加到新的AOF文件中。然后替換就的AOF文件。
在整個過程中，會產生2個AOF文件和1個內存數據拷貝。
操作過程：Redis 會將重寫過程中的接收到的「寫」指令操作同時記錄到舊的 AOF 緩沖區和 AOF 重寫緩沖區。等到拷貝數據的所有操作記錄重寫完成后，重寫重寫緩沖區中的最新操作記錄也會寫入新的AOF文件中。具體的流程如下：
適應場景：對於重復寫操作多的場景尤其效果明顯。如下圖：三條 LPUSH 指令，經過 AOF 重寫后生成一條。
2、RDB和AOF的混合方案（redis 4.0開始使用）
將 rdb 文件的內容和增量的 AOF 日志文件存在一起，AOF 日志文件中只記錄RDB后的增量操作記錄，則該文件會很小，方便redis快速恢復。
該種模式下，RDB的頻率就可以變小了，增量使用AOF來記錄。