爬蟲和轉載請注明原文位址;部落格園蝸牛：http://www.cnblogs.com/tdws/p/5754706.html
Redis的持久化過程中并不需要我們開發人員過多的參與，我們要做的是什麼呢？除了深入了解RDB和AOF的作用原理，剩下的就是根據實際情況來制定合适的政策了，再複雜一點，也就是定制一個高可用的，資料安全的政策了。
先來看RDB持久化方式：
在RDB方式下，你有兩種選擇，一種是手動執行持久化資料指令來讓redis進行一次資料快照，另一種則是根據你所配置的配置檔案 的 政策，達到政策的某些條件時來自動持久化資料。而手動執行持久化指令，你依然有兩種選擇，那就是save指令和bgsave指令。
save操作在Redis主線程中工作，是以會阻塞其他請求操作，應該避免使用。
（預設下，持久化到dump.rdb檔案，并且在redis重新開機後，自動讀取其中檔案，據悉，通常情況下一千萬的字元串類型鍵，1GB的快照檔案，同步到記憶體中的 時間是20-30秒）
bgSave則是調用Fork,産生子程序，父程序繼續處理請求。子程序将資料寫入臨時檔案，并在寫完後，替換原有的.rdb檔案。Fork發生時，父子程序記憶體共享，是以為了不影響子程序做資料快照，在這期間修改的資料，将會被複制一份，而不進共享記憶體。是以說，RDB所持久化的資料，是Fork發生時的資料。在這樣的條件下進行持久化資料，如果因為某些情況當機，則會丢失一段時間的資料。如果你的實際情況對資料丢失沒那麼敏感，丢失的也可以從傳統資料庫中擷取或者說丢失部分也無所謂，那麼你可以選擇RDB持久化方式。
再談一下配置檔案的政策，實際上它和bgsave指令持久化原理是相同的。
這是配置檔案預設的政策，他們之間的關系是或，每隔900秒，在這期間變化了至少一個鍵值，做快照。或者每三百秒，變化了十個鍵值做快照。或者每六十秒，變化了至少一萬個鍵值，做快照。
下面再來說一說AOF快照方式：
AOF,append only file。
配置檔案中的appendonly修改為yes。開啟AOF持久化後，你所執行的每一條指令，都會被記錄到appendonly.aof檔案中。但事實上，并不會立即将指令寫入到硬碟檔案中，而是寫入到硬碟緩存，在接下來的政策中，配置多久來從硬碟緩存寫入到硬碟檔案。是以在一定程度一定條件下，還是會有資料丢失，不過你可以大大減少資料損失。
這裡是配置AOF持久化的政策。redis預設使用everysec，就是說每秒持久化一次，而always則是每次操作都會立即寫入aof檔案中。而no則是不主動進行同步操作，是預設30s一次。當然always一定是效率最低的，個人認為everysec就夠用了，資料安全性能又高。
Redis也允許我們同時使用兩種方式，再重新開機redis後會從aof中恢複資料，因為aof比rdb資料損失小嘛。
差別和深入了解：
RDB每次進行快照方式會重新記錄整個資料集的所有資訊。RDB在恢複資料時更快，可以最大化redis性能，子程序對父程序無任何性能影響。
AOF有序的記錄了redis的指令操作。意外情況下資料丢失甚少。他不斷地對aof檔案添加記錄檔記錄，你可能會說，這樣的檔案得多麼龐大呀。是的，的确會變得龐大，但redis會有優化的政策，比如你對一個key1鍵的操作，set key1 001 , set key1 002, set key1 003。那優化的結果就是将前兩條去掉咯，那具體優化的配置在配置檔案中對應的是
前者是指超過上一次aof重寫aof檔案大小的百分之多少，會再次優化，如果沒有重寫過，則以啟動時為主。後者是限制了允許重寫的最小aof檔案大小。bgrewriteaof指令是手動重寫指令，會fork子程序，在臨時檔案中重建資料庫狀态，對原aof無任何影響，當重建舊的狀态後，也會把fork發生後的一段時間内的資料一并追加到臨時檔案，最後替換原有aof檔案，新的指令繼續向新的aof檔案中追加。