RDB
把當(dāng)前進(jìn)程數(shù)據(jù)生成快照保存在硬盤
觸發(fā)時機(jī)
- 手動執(zhí)行
dgsave。 - 使用save 相關(guān)配置 ，
save m n。表示m秒內(nèi)數(shù)據(jù)集存在n次修改時，自動觸發(fā)bgsave。 - 從節(jié)點執(zhí)行全量復(fù)制，主節(jié)點自動執(zhí)行
bgsave生成RDB文件并發(fā)送給從節(jié)點。 - 執(zhí)行
debug reload重新加載redis時。 - 在沒有開啟AOF的情況下執(zhí)行
shutdown。 - 執(zhí)行
flushall，在這種情況下，會刪除所有數(shù)據(jù)，即RDB文件也會是空的。謹(jǐn)慎操作
生成流程
- 父進(jìn)程執(zhí)行bgsave，會fork子進(jìn)程，由子進(jìn)程生成RDB文件。
- fork 子進(jìn)程過程中會阻塞，fork完成后，父子進(jìn)程并行，父進(jìn)程可以處理其他操作。
- 子進(jìn)程根據(jù)父進(jìn)程內(nèi)存生成臨時快照文件，完成后對原文件進(jìn)行原子替換。
- 子進(jìn)程發(fā)送信號給父進(jìn)程表示完成，父進(jìn)程更新統(tǒng)計信息
在生成RDB文件過程中產(chǎn)生的數(shù)據(jù)無法備份。
RDB生成流程
文件處理
保存： 保存在dir/dbfilename 下 。 dir、dbfilename為配置項。
壓縮： dbcompression yes 默認(rèn)開啟，采用LZF算法進(jìn)行壓縮。
校驗： 加載RDB文件時，可能存在文件的損壞。 采用 redis-check-dump 工具進(jìn)行檢測。
AOF
- 持久化每次的寫命令，重啟時再執(zhí)行AOF中命令進(jìn)行數(shù)據(jù)恢復(fù)。主要的解決數(shù)據(jù)持久化的實時性。
- 開啟AOF設(shè)置參數(shù)
appendonly yes，默認(rèn)不開啟。 - 文件名設(shè)置參數(shù)
appendfilename指定，默認(rèn)為 appendonly.aof。
處理流程
- 寫命令執(zhí)行，會追加到緩存（命令寫入）
- AOF緩存區(qū)根據(jù)對應(yīng)的策略向硬盤做同步操作（文件同步）
- AOF文件過大，需要定期重寫AOF文件（文件重寫）
- 重啟服務(wù)加載AOF（AOF加載）
文件同步
同步策略
使用 appendfsync 參數(shù)控制，默認(rèn)為 appendfsync everysec
| 可配置項 | 說明 |
|---|---|
| always | 命令寫入緩存后，調(diào)用系統(tǒng)fsync同步數(shù)據(jù)到硬盤AOF文件中，然后線程返回 |
| everysec | 1. 命令寫入緩存后，調(diào)用系統(tǒng)write操作，然后線程返回。 2. fsync同步文件操作由專門線程每秒調(diào)用一次。 3. fsync同步可能失敗或同步時間超過1秒，若主線程判斷距上一次同步成功超過2秒，則會阻塞主線程，直到同步操作完成。 保證了最多可能丟失2秒數(shù)據(jù)。 |
| no | 命令寫入緩存后，調(diào)用系統(tǒng)write操作，然后線程返回。 fsync同步文件操作由操作系統(tǒng)負(fù)責(zé)何時執(zhí)行，通常同步周期最長30秒 |
文件同步
重寫機(jī)制
重寫是通過丟棄進(jìn)程中超時的數(shù)據(jù)、去除舊AOF文件中無效的命令以及將多條寫命令合并為一個的操作。
觸發(fā)時機(jī)
手動觸發(fā)： 直接調(diào)用 bgrewriteaof 命令
自動觸發(fā)： 根據(jù)auto-aof-rewrite-min-size 和 auto-aof-rewrite-percentage 參數(shù)確定觸發(fā)時機(jī)。
auto-aof-rewrite-percentage ，當(dāng)前的aof文件的大小超過上一次文件大小的百分比時，會觸發(fā)重寫。
auto-aof-rewrite-min-size ，限制了允許重寫的最小文件大小，當(dāng)aof文件達(dá)到這個值時，觸發(fā)重寫。
《redis開發(fā)與運維》P159看具體公式
重寫流程
- 若當(dāng)前已經(jīng)存在AOF重寫了，流程返回。 若當(dāng)前正在執(zhí)行
bgsave,重寫命令等待bgsave完成后繼續(xù)執(zhí)行。步驟1） - fork 子進(jìn)程，fork完成后父進(jìn)程繼續(xù)工作。步驟 2）、3.1）
- 由于fork操作運用寫時復(fù)制技術(shù)，子進(jìn)程只能共享fork操作時的內(nèi)存數(shù)據(jù)。aof_rewrite_buf 保存的是fork之后父進(jìn)程新寫入的數(shù)據(jù)。步驟3.2）
- 子進(jìn)程根據(jù)內(nèi)存快照，按照命令合并規(guī)則寫入到新的AOF文件。批量寫入磁盤由
aof-rewrite-incremental-fsync yes控制默認(rèn)32MB。步驟4） - 父進(jìn)程把 ***aof_rewrite_buf *** 中的數(shù)據(jù)追加到新的AOF文件。 步驟5.2）
- 使用新的AOF文件的替換舊的文件，完成AOF重寫。步驟5.3）
重寫流程
重啟加載
- 若開啟了AOF持久化的，優(yōu)先加載AOF文件。
- 若加載過程中發(fā)現(xiàn)AOF文件損壞，可嘗試采用
redis-check-aof --fix命令進(jìn)行修復(fù)，修復(fù)前先備份AOF文件。
重啟加載
混合模式
- redis4.0開始支持
- 開啟方式：
aof-use-rdb-preamble true - 開啟之后，AOF重寫會把內(nèi)存中數(shù)據(jù)以RDB方式寫到AOF中，再將重寫緩存區(qū)的數(shù)據(jù)追加到AOF中，最后將含有RDB格式和AOF格式的AOF文件覆蓋舊的AOF文件。
- 重啟加載時，也是優(yōu)先加載AOF
總結(jié)
| 持久化模式 | 優(yōu)點 | 缺點 | 適用場景 |
|---|---|---|---|
| RDB | 1. 重啟加載速度比AOF快 2. 文件體積比整個實例內(nèi)存小，在傳輸速度上快，適合做容災(zāi)恢復(fù)的備份 |
1. 沒法做到實時持久化、不能保證數(shù)據(jù)完整性 2. 可閱讀性差 3. 由于采用特定的二進(jìn)制格式保存，多個版本之間可能存在兼容性的問題 |
1. 主從全量數(shù)據(jù)同步 2. 數(shù)據(jù)庫備份 3. 對于丟失數(shù)據(jù)不敏感的業(yè)務(wù)場景，實例宕機(jī)后快速恢復(fù) |
| AOF | 1. 能保證數(shù)據(jù)實時持久化，秒級丟失 2. 兼容性好，基于redis通訊協(xié)議（RDSP）的寫命令追加 3. 可閱讀性好 |
1. 數(shù)據(jù)文件體積大，即便有重寫機(jī)制，但在相同數(shù)據(jù)集下,AOF還是比RDB文件大 2. 恢復(fù)速度比RDB慢 |
|
| 混合模式 | 既能快速備份又能避免大量數(shù)據(jù)丟失 | 1. RDB是壓縮格式，AOF文件可讀性差。 2. 不兼容4.0以下的版本 |
