Redis持久化機制:

RDB快照
AOF日誌

一.RDB快照

1.概念

RDB是把當前程序資料生成快照儲存到硬碟的過程(以二進位制方式寫入磁碟)

2.觸發機制:手動和自動

【1】手動觸發分別對應save和bgsave命令

·save命令：阻塞當前Redis伺服器，直到RDB過程完成為止，對於記憶體 比較大的例項會造成長時間阻塞，線上環境不建議使用
·bgsave命令：Redis程序執行fork操作建立子程序，RDB持久化過程由子 程序負責，完成後自動結束。阻塞只發生在fork階段，一般時間很短

【2】自動觸發就是在配置檔案中使用save相關配置，如“save m n”。表示m秒內資料集存在n次修改 時，自動觸發bgsave

3.優缺點

產生的檔案小，恢復速度快, 由於每次生成RDB開銷較大(需要fork子程序,屬於重量級操作,會導致redis卡頓若干秒)，無法做到實時持久化

4.禁用持久化

命令 config set save ""

二. AOF日誌

1.概念

以獨立日誌的方式記錄每次命令， 重啟時再重新執行AOF檔案中的命令達到恢復資料的目的。AOF的主要作用 是解決了資料持久化的實時性

2.開啟方式

查詢aof是否開啟: 
命令 config get appendonly

開啟AOF:
1)命令列(實時生效,但重啟後失效):
config set appendonly

2)配置檔案(需重啟生效):
appendonly yes，預設不開啟
 

3.觸發策略

手動觸發:
執行命令 bgrewriteaof

3種自動觸發:
（1）每修改同步always：同步持久化 每次發生資料變更會被立即記錄到磁碟 效能較差但資料完整性比較好
（2）每秒同步everysec：非同步操作，每秒記錄 如果一秒內宕機，有資料丟失(推薦)
（3）不同no：從不同步

4.AOF工作流程

1.所有寫入命令追加到aof_buf緩衝區(redis是單執行緒響應命令,如果每次命令都直接追加到磁碟,會影響磁碟的負載)

2.aof緩衝區根據對應的策略向磁碟做同步操作

3.隨著aof檔案越來越大,需要定期對aof檔案進行重寫,達到壓縮目的

4.redis重啟時,可以載入aof檔案進行資料恢復

5.AOF重寫機制

原因: 
AOF的工作原理是將寫操作追加到檔案中，檔案的冗餘內容會越來越多.當AOF檔案的大小超過所設定的閾值時，Redis就會對AOF檔案的內容壓縮

重寫原理: 
Redis 會fork出一條新程序，讀取記憶體中的資料，並重新寫到一個臨時檔案中...最後替換舊的aof檔案

觸發機制：
當AOF檔案大小是上次rewrite後大小的一倍且檔案大於64M時觸發。這裡的“一倍”和“64M” 可以通過配置檔案修改

手動觸發：
直接呼叫bgrewriteaof命令。
自動觸發：
根據auto-aof-rewrite-min-size和auto-aof-rewrite-percentage引數確定自動觸發時機

·auto-aof-rewrite-min-size：表示執行AOF重寫時檔案最小體積，預設 為64MB。
·auto-aof-rewrite-percentage：代表當前AOF檔案空間 （aof_current_size）和上一次重寫後AOF檔案空間（aof_base_size）的比值。
自動觸發時機=aof_current_size > auto-aof-rewrite-minsize &&（aof_current_size-aof_base_size）/aof_base_size>=auto-aof-rewritepercentage

三.RDB和AOF同時開啟可能存在的坑

場景: 如果redis以rdb模式運行了,然後關閉redis,配置檔案配置開啟aof,重啟redis,此時會發現redis中沒有資料

原因: redis會優先基於aof去恢復,,即使沒有.aof檔案,,他會建立一個新的空的.aof檔案....

解決方案:
停止redis，關閉aof，拷貝rdb備份，重啟redis，確認資料恢復，
直接在命令列熱修改redis配置(redis的客戶端執行命令:    config set appendonly yes)，開啟aof，
這時redis就會將記憶體中的資料對應的日誌，寫入aof檔案中, 此時aof和rdb兩份資料檔案的資料就同步了