1.RDB：將當前進程數據生成快照保存到硬盤的過程
A.觸發RDB的2種方式：
a.手動觸發：
save命令：阻塞當前redis服務器,直到RDB過程完成爲止,不建議線上使用
bgsave命令：redis進程執行fork操作創建子進程,RDB持久化過程由子進程負責,阻塞只發生在fork階段
b.自動觸發：
使用save相關配置(redis.conf文件),如save m n,則再m秒內數據集存在n次修改時,自動觸發bgsave
若從節點執行全量複製,主節點自動執行bgsave生成RDB文件併發送給從節點
執行debug reload命令重新加載redis時,也會自動觸發save操作
默認情況下執行shutdown命令時,若沒開啓AOF持久化功能則自動執行bgsave
B.RDB運行流程,如圖：
可通過以下命令查看RDB相關信息：
info stats命令的latest_fork_usec選項可查看最近一個fork操作耗時,單位微妙
lastsave命令可以獲取最後一次生成RDB的時間,對應info統計的rdb_last_save_time選項
info persistence下的rdb_*相關選項
C.RDB文件的處理：
a.保存：RDB文件保存在dir配置指定的目錄下,文件名通過dbfilename配置指定,可通過config set dir{newDir}或config set dbfilename{newFileName}動態指定,下次運行時RDB文件會保存到新的目錄(磁盤滿時動態保存,切換目錄後bgsave)
b.壓縮：redis默認對生成的RDB文件進行壓縮,默認開啓,可用config set rdbcompression{yes|no}動態修改(建議開啓)
c.校驗：若redis加載損壞的RDB文件時拒絕啓動,可用redis-check-dump工具檢測
D.RDB的優缺點：
優點：緊湊壓縮,節省空間,適合用於備份、全量複製等場景,redis加載RDB恢復數據遠遠快於AOF的方式
缺點：無法實時持久化/秒級持久化,有些老版本redis服務無法兼容新版RDB格式
2.AOF：以獨立日誌的方式記錄每次寫命令,重啓時再重新執行AOF文件中的命令以達到恢復數據的目的
A.AOF的配置(redis.conf文件)：
開啓AOF配置：appendonly yes,默認不開啓
配置AOF文件名稱：appendfilename,默認爲appendonly.aof 保存路徑與RDB一致,通過dir配置
B.AOF的大體工作流程：
a.所有的寫命令會追加到aof_buf(緩衝區) 中
b.AOF緩衝區根據對應的策略向硬盤做同步操作
c.隨着AOF文件越來越大,需要定期對AOF文件進行重寫,達到壓縮的目的
d.當Redis服務器重啓時,可以加載AOF文件進行數據恢復
C.詳細版的AOF工作流程：
a.命令寫入：寫入的內容採用文本協議格式,兼容性與可讀性(不做介紹)
b.文件同步3種策略：由appendfsync控制
可配置值 | 說明 | 建議 |
|---|---|---|
| always | 命令寫入aof_buf後調用系統fsync操作同步到AOF文件，fsync完成後線程返回 | 每次都同步aof文件,低效,不建議用 |
| everysec | 命令寫入aof_buf後調用系統write操作，write完成後線程返回，fsync同步文件操作由專門線程每秒調用一次 | 提升性能但數據安全無法保證,依賴系統調度,不建議用 |
| no | 命令寫入aof_buf後調用系統write操作，不對AOF文件做fsync同步，同步硬盤操作由操作系統負責，通常同步週期最長30s | 默認配置,理論上發生意外只丟失1s的數據 |
wirte操作：會觸發延遲寫機制,寫入系統緩衝區後直接返回,同步硬盤操作依賴於系統調度機制,若在同步文件之前發生故障,緩衝區數據將丟失
fsync操作：會針對單個文件操作,做強制硬盤同步,fsync將阻塞直到寫入硬盤完成後返回,保證了數據的持久化write操作：會觸發延遲寫機制，寫入系統緩衝區後直接返回，同步硬盤操作依賴於系統調度機制，若在同步文件之前發生故障，緩衝區數據將丟失
c.重寫機制：用於解決不斷寫入造成aof文件越來越大的問題,將redis進程內數據轉化爲寫命令同步到新AOF文件的過程，主要以剔除無效命令、命令合併、超時數據不寫入的方式來縮小AOF文件
觸發重寫機制的2種方式：
手動觸發：直接調用bgrewriteaof命令
自動觸發：根據auto-aof-rewrite-min-size和auto-aof-rewrite-percentage參數確定自動觸發時機(auto-aof-rewrite-min-size表示運行AOF重寫時文件最小體積,默認64M,auto-aof-rewrite-percentage代表當前AOF文件空間與上一次重寫後AOF文件空間的比值)
自動觸發時機=aof_current_size>auto-aof-rewrite-minsize&&(aof_current_size - aof_base_size)/aof_base_size>=auto-aof-rewritepercentage
其中, aof_current_size與aof_base_size可從info persistence的統計信息中查看
d.aof重寫機制：
1.請求aof重寫：若正在執行aof重寫,直接返回,若正在 bgsave,延遲至bgsave完成
2.執行fork操作,開銷等同於bgsave過程
3.1. fork操作完成後,繼續響應其他命令,所有寫命令依然寫入aof緩衝區並根據appendfsync策略同步到硬盤 ,保證原有aof機制正確性
3.2.父進程依然響應命令,redis使用”aof重寫緩衝區”保存新數據,防止新aof文件生成期間丟失新數據(因子進程只能共享fork操作時的內存數據)
4.子進程根據內存快照,按照命令合併規則寫入到新的 aof文件,每次批量寫入硬盤數據量由配置aof-rewrite- incremental-fsync控制,默認爲32MB,防止單次刷盤數據過多造成硬盤阻塞
5.新aof文件寫入完成後,子進程發信號給父進程,父 進程更新統計信息,info persistence下aof_*相關統計
5.1.父進程把aof重寫緩衝區的數據寫入到新aof文件
5.2.使用新aof文件替換老文件,完成aof重寫
e.重啓加載流程：
a.aof持久化開啓且存在aof文件時, 優先加載aof文件
b.aof關閉或者aof文件不存在時,加 載rdb文件
c.加載aof/rdb文件成功後,redis啓動成功
d. aof/rdb文件存在錯誤時,redis啓動失敗並打印錯誤信息
3.問題定位與優化：
A.改善fork操作：
a.優先使用物理機or高效支持fork操作的虛擬技術,避免使用Xen虛擬機
b.控制redis實例最大可用內存(10G以內)
c.合理控制linux的內存分配策略,防止物理內存不足導致fork失敗
d.降低fork操作頻率,避免不必要的全量複製
e.不要做綁定單核cpu操作,避免與其他cpu密集型服務部署在一起
f.儘量保證同一時刻只有一個線程在進行重寫操作
g.避免與其他高硬盤負載服務部署在一起(重寫過程fsync操作會消耗大量硬盤IO)
B.同步策略everysec造成的aof追加阻塞：redis會使用線程每秒執行fsync操作同步硬盤,硬盤資源繁忙時,redis可能會阻塞
a.主線程負責寫入aof緩衝區
b.aof線程負責每秒執行一次同步磁盤操作,並記錄最近一 次同步時間
c.主線程負責對比上次aof同步時間,若距上次同步成功時間在2秒內,主線程直接返回,若距上次同步成功時間超 過2秒,主線程將會阻塞,直到同步操作完成