我們都知道 Redis 的資料全部都在記憶體裡，如果突然宕機，資料就會全部遺失，那該怎麼解決呢？
因此必須有一個機制來確保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資料庫使用入門教學欄位學習！
以上是redis宕機了怎麼辦的詳細內容。更多資訊請關注PHP中文網其他相關文章！
