1. Redis提供兩種持久化方式 ： RDB 和AOF

bgsave 命令的運作流程

RDB優點：

是一個緊湊壓縮的二進位制檔案，代表Redis在某個時間點上的資料快照非常實用於備份，全量複製等場景。比如每6小時執行bgsave備份，並吧檔案拷貝到遠端機器或者檔案系統中 hdfs ,用於災難恢復。

RDB恢復資料遠遠快於AOF方式

缺點：

RDB方式資料沒辦法做到實時持久化/秒級持久化。因為bgsave每次執行都要執行fork操作建立子程序，屬於重量級操作，頻繁執行成本過高。

RDB檔案使用特定二進位制格式儲存，Redis版本演進過程中有多個格式的RDB版本，存在老版本Redis服務無法箭筒新版RDB格式的問題。

AOF工作流程

AOF解決了實時性持久化資料問題 採用文字協議格式

原因是： 很好的相容性、開啟AOF後，所有寫入命令都包含追加操作，直接採用協議格式，避免了二次處理開銷、

文字協議具有可讀性，方便直接修改和處理。

AOF為啥把命令追加到aof_bug中？

redis使用單執行緒響應命令，如果每次寫AOF檔案命令都直接加到硬碟，那麼效能完全取決於當前硬碟負載。寫寫入緩衝區aof_bug中，可以提供多種緩衝區同步硬碟的策略，在效能和安全性方面做出平衡。

2.RDB使用一次性生成記憶體快照的方式，無法做到實時持久化，一般用於資料冷備和複製傳輸。

3.AOF通過追加寫命令到檔案實現持久化，通過appendfsync 引數可以控制實時/秒級持久化。因為需要不斷追加寫命令，所以AOF檔案體積逐漸變大，需要定期執行重寫操作來降低檔案體積。

4. save命令會阻塞主執行緒不建議使用，bgsave命令通過fork操作建立子程序生成RDB避免阻塞。

5.AOF重寫可以通過 auto-aof-rewrite-min-size 和 auto-aof-rewrite-percentage 引數控制自動觸發，也可以使用bgrewriteaof命令手動觸發。

 AOF重寫運作流程

6. 子程序執行期間使用copy-on-write 機制與父程序共享記憶體，避免記憶體消耗翻倍。AOF重寫期間還需要維護重寫緩衝區，儲存新的寫入命令避免資料丟失。

7.持久化阻塞主執行緒場景有： fork阻塞 和 AOF 追加阻塞。 fork 阻塞時間跟記憶體量和系統有關，AOF追加阻塞說明硬碟資源緊張。

8..單機下部署多個例項時，為了防止出現多個子程序執行重寫操作，建議做隔離控制，避免CPU和IO資源競爭。

everysec 刷盤策略的過程

輪詢控制AOF重寫