redis快照和AOF簡介

數據持久化到硬盤：一是快照(snapshotting),二是隻追加文件(append-only file AOF)

快照

核心原理：redis某個時間內存內的全部數據寫入硬盤

場景：redis快照內存裏面的數據

1. 用戶發送bgsave命令  (此時redis會fork一個子進程,子進程負責生成硬盤文件,父進程負責繼續接受命令)
2. 用戶發送save命令  (和bgsave命令不一樣,發送save命令後,到系統建立快照完成以前系統不會再接收新的命令,換句話說save命令會阻塞後面的命令,而bgsave不會)
  例如 ：save 60 1000
  知足"60秒內有1000次寫入"這個條件,系統就自動調用bgsave,若是配置文件裏有多個save命令,只有知足一個就調   用bgsave命令
3.用戶發送shutdown,系統會先導員save命令阻塞客戶端,而後關閉服務器
4.當有主從架構時,從服務器向主服務器發送sync命令來執行復制操做時,只有主服務器當時沒有進行bgsave操做,那麼主服務器就會執行bgsave操做

快照的劣勢

可能會丟失數據
save 60 1000,若是我在60秒內只更新了800條數據,而後系統崩潰了,那麼這800條數據就沒了

AOF

核心原理：全部的redis數據寫操做的命令記錄到硬盤上,這樣一來恢復的時候,再執行一次命令就OK了

設置屬性：

appendonly no                   

#是否開啓aof  
appendfsync everysec  通常使用

#always,everysec,no
always就是每次有一個寫命令,就把命令存的硬盤文件裏
everysec就是每秒寫入硬盤一次
no就是由操做系統來確認何時寫
no-appendfsync-on-rewrite no

#設置在rewrite的時候是否對新的寫操做進行fsync(將緩存中的命令寫入硬盤)。no表示進行fsync，yes表示不進行默認是設置爲no

aof優點在於:

就算出問題了,最多丟失1秒內的更新數據 aof的劣勢: aof文件的體積可能會很大(可能比快照文件還大),另外一方面,系統重啓的時候回從aof裏讀命令,若是aof文件太大,讀命令也就要還好久