因此必須有壹種機制來保證Redis的數據不會因為故障而丟失，這種機制就是Redis的持久化機制。（推薦學習：Redis視頻教程）
Redis 的持久化機制有兩種，第壹種是快照，第二種是 AOF 日誌。快照是壹次全量備份，AOF 日誌是連續的增量備份。快照是內存數據的二進制序列化形式，在存儲上非常緊湊，而 AOF 日誌記錄的是內存數據修改的指令記錄文本。AOF 日誌在長期的運行過程中會變得無比龐大，數據庫重啟時需要加載 AOF 日誌進行指令重放，這個時間就會無比漫長，所以需要定期進行 AOF 重寫，給 AOF 日誌進行瘦身。
快照原理
我們知道 Redis 是單線程程序，這個線程要同時負責多個客戶端套接字的並發讀寫操作和內存數據結構的邏輯讀寫。
在服務線上請求的同時，Redis 還需要進行內存快照，內存快照要求 Redis 必須進行文件 IO 操作，可文件 IO 操作是不能使用多路復用 API。
這意味著單線程在服務線上請求的同時，還要進行文件 IO 操作，而文件 IO 操作會嚴重拖累服務器請求的性能。
還有個重要的問題，為了不阻塞線上的業務，Redis 就需要壹邊持久化，壹邊響應客戶端的請求。持久化的同時，內存數據結構還在改變，比如壹個大型的 hash 字典正在持久化，結果壹個請求過來把它給刪掉了，可是還沒持久化完呢，這該怎麽辦呢？
Redis 使用操作系統的多進程 COW（Copy On Write）機制來實現快照持久化，這個機制很有意思，也很少人知道。
AOF原理
AOF 日誌存儲的是 Redis 服務器的順序指令序列，AOF 日誌只記錄對內存進行修改的指令記錄。
假設 AOF 日誌記錄了自 Redis 實例創建以來所有的修改性指令序列，那麽就可以通過對壹個空的 Redis 實例順序執行所有的指令——也就是“重放”，來恢復 Redis 當前實例的內存數據結構的狀態。
Redis 會在收到客戶端修改指令後，進行參數校驗、邏輯處理，如果沒問題，就立即將該指令文本存儲到 AOF 日誌中，也就是說，先執行指令才將日誌存盤。這點不同於 leveldb、hbase 等存儲引擎，它們都是先存儲日誌再做邏輯處理。
Redis 在長期運行的過程中，AOF 的日誌會越變越長。如果實例宕機重啟，重放整個 AOF 日誌會非常耗時，導致長時間 Redis 無法對外提供服務。所以需要對 AOF 日誌瘦身。
更多Redis相關技術文章，請訪問Redis數據庫使用入門教程欄目進行學習！