Redis提供兩種主要的持久化機制：RDB（Redis Database）和AOF（Append Only File），它們在數據持久化方式、性能影響及恢復策略上各有特點。以下是兩者的對比分析及使用建議：
RDB（快照持久化）
工作原理
定期生成內存數據的二進制快照（默認保存為dump.rdb），觸發方式包括手動命令（SAVE/BGSAVE）或配置自動觸發規則（如save 900 1表示900秒內至少1個鍵被修改）。
優點
- 高性能：通過fork子進程生成快照，主進程無阻塞，適合大規模數據備份。
- 快速恢復：二進制文件體積小，加載速度遠快于AOF。
- 緊湊存儲：適合災難恢復與歷史版本備份。
缺點
- 數據丟失風險：兩次快照間的數據可能丟失（取決于觸發間隔）。
- 大內存fork延遲：數據量大時，fork子進程可能導致短暫性能抖動。
配置示例
save 900 1 # 15分鐘至少1次修改觸發
save 300 10 # 5分鐘至少10次修改觸發
save 60 10000 # 1分鐘至少10000次修改觸發
AOF（日志追加持久化）
工作原理
記錄每個寫操作命令到日志文件（默認appendonly.aof），重啟時重放命令恢復數據。支持日志重寫（壓縮冗余命令）和同步策略配置。
優點
- 高數據安全：默認每秒同步（
appendfsync everysec），最多丟失1秒數據；always策略則零丟失（性能代價高）。 - 可讀性強：文本格式日志便于人工分析或修復。
缺點
- 文件體積大：日志文件通常比RDB大，需定期重寫優化。
- 恢復速度慢：重放所有命令較RDB直接加載慢。
配置示例
appendonly yes
appendfsync everysec # 默認策略，平衡性能與安全
auto-aof-rewrite-percentage 100 # 文件增長100%時觸發重寫
auto-aof-rewrite-min-size 64mb # 最小文件重寫閾值
對比總結
| 特性 | RDB | AOF |
|---|---|---|
| 數據安全性 | 可能丟失最后一次快照后的數據 | 通常最多丟失1秒數據（默認配置） |
| 文件體積 | 緊湊，適合備份 | 較大，但重寫后優化 |
| 恢復速度 | 快速加載二進制數據 | 較慢（需重放命令） |
| 寫性能影響 | fork可能延遲主進程 | 取決于同步策略（always影響最大） |
| 適用場景 | 容災備份、快速恢復 | 高數據安全要求、可容忍較低性能 |
使用建議
-
混合持久化（推薦）
同時啟用RDB和AOF（Redis 4.0+默認支持），兼顧安全性與恢復速度：- AOF用于保證日常數據完整性。
- RDB用于定期備份和快速恢復。
appendonly yes aof-use-rdb-preamble yes # 混合模式（AOF文件包含RDB格式前綴） -
純RDB
適用場景：- 允許分鐘級數據丟失。
- 需要頻繁備份或快速重啟（如緩存服務）。
-
純AOF
適用場景：- 數據安全性優先，容忍恢復時間較長。
- 需記錄詳細操作日志（如審計需求）。
運維注意事項
- 監控磁盤空間：AOF文件可能快速增長，需設置重寫規則。
- 備份策略：定期將RDB/AOF文件拷貝至異地容災。
- 性能調優：根據服務器配置調整
save規則和appendfsync策略。
通過合理配置RDB與AOF，可在數據安全性與性能之間取得平衡，適應不同業務場景需求。
)
：常見網絡故障排查)
