博客鏈接：http://www.cnblogs.com/zhenghongxin/p/8669913.html redis 本地持久化到硬碟有兩種方式,一是快照(snapshotting),二是只追加文件(append-only file AOF) 快照 快照，顧名思義可以理解為拍照一樣，把整個記憶體 ...
博客鏈接：http://www.cnblogs.com/zhenghongxin/p/8669913.html
redis 本地持久化到硬碟有兩種方式,一是快照(snapshotting),二是只追加文件(append-only file AOF)
快照
快照，顧名思義可以理解為拍照一樣，把整個記憶體數據映射到硬碟中，保存一份到硬碟，因此恢複數據起來比較快，把數據映射回去即可，不像AOF，一條條的執行操作命令。產生快照的過程：
1 執行bgsave命令(此時redis會fork一個子進程,子進程負責生成硬碟文件,父進程負責繼續接受命令)
2 或執行save命令(和bgsave命令不同,發送save命令後,到系統創建快照完成之前系統不會再接收新的命令,換句話說save命令會阻塞後面的命令,而bgsave不會)
3 用戶在配置文件了配置了類似這樣的命令
save 900 1 // 900內,有1條寫入,則產生快照
save 300 1000 // 如果300秒內有1000次寫入,則產生快照
save 60 10000 // 如果60秒內有10000次寫入,則產生快照
(這3個選項都屏蔽,則rdb禁用)
4 用戶發送shutdown,系統會先導員save命令阻塞客戶端,然後關閉伺服器
5 當有主從架構時,從伺服器向主伺服器發送sync命令來執行複製操作時,只有主伺服器當時沒有進行bgsave操作,那麼主伺服器就會執行bgsave操作。
我們可以在redis目錄下查看redis.conf配置，其中某些重要配置：
stop-writes-on-bgsave-error yes // 後臺備份進程出錯時,主進程停不停止寫入?
rdbcompression yes // 導出的rdb文件是否壓縮
Rdbchecksum yes // 導入rbd恢復時數據時,要不要檢驗rdb的完整性
dbfilename dump.rdb //導出來的rdb文件名
dir ./ //rdb的放置路徑
快照的優勢
1） 通過合理的配置，可以讓Redis每隔一段時間就保存一次資料庫副本，也可以很方便地將數據還原到特定的時間點。
2）RDB文件相比AOF占用的空間更小，恢複數據的速度也更快。
3）如果創建RDB文件時出現了錯誤，Redis不會將它用於替換原來的文件，所以出錯時不會影響到之前保存的版本。
快照的缺點
1） 如果硬體、系統、Redis三者其中之一齣現問題而崩潰，Redis會丟失全部數據，保留下來的數據只有上一個時間點創建的快照。如果數據對於應用程式來說非常重要，那麼出現錯誤時的損失會非常大。
2）fork子進程占用的記憶體隨著資料庫中數據的增加而增加，耗費的時間也會越來越多
一些問答：
問: 在dump rdb過程中,aof如果停止同步,會不會丟失?
答: 不會,所有的操作緩存在記憶體的隊列里, dump完成後,統一操作.
問: aof重寫是指什麼?
答: aof重寫是指把記憶體中的數據,逆化成命令,寫入到.aof日誌里.以解決 aof日誌過大的問題.
問: 如果rdb文件,和aof文件都存在,優先用誰來恢複數據?
答: aof
問: 2種是否可以同時用?
答: 可以,而且推薦這麼做
一般來說,如果想達到足以媲美 PostgreSQL 的數據安全性， 你應該同時使用兩種持久化功能。如果你非常關心你的數據,但仍然可以承受數分鐘以內的數據丟失， 那麼你可以只使用 RDB 持久化。有很多用戶都只使用 AOF 持久化， 但我們並不推薦這種方式： 因為定時生成 RDB 快照（snapshot）非常便於進行資料庫備份， 並且 RDB 恢複數據集的速度也要比 AOF 恢復的速度要快， 除此之外， 使用 RDB 還可以避免之前提到的 AOF 程式的 bug 。因為以上提到的種種原因， 未來我們可能會將 AOF 和 RDB 整合成單個持久化模型。 （這是一個長期計劃。）
問: 恢復時rdb和aof哪個恢復的快
