redis持久化詳解
redis是一個支持持久化的內存型數據庫，
由於是在內存中，即使有主從，數據冗餘備份，也難保數據丟失，
redis持久化就是解決這個問題。
redis持久化，是通過把內存裏的數據同步到磁盤上來保證持久化。
redis有兩種持久化方式
一種是快照，snapshotting,也是默認方式，還有一種是隻追加文件，縮寫aof(apppend-only-file)。
快照（snapshotting）：將某一時刻的所有數據都寫入硬盤。
只追加文件（AOF）：在執行寫命令時，將被執行的寫命令複製到硬盤裏。
snapshotting(RDB)機制
創建快照有兩個命令BGSAVE,SAVE。
BGSAVE過程：
1redis通過fork產生子進程
2父進程繼續處理client請求，子進程負責將快照寫入硬盤
3子進程寫完後，用臨時文件代替原來快照文件，然後子進程退出
SAVE過程：
1redis服務器停止接受來自client請求
2在快照創建完成之前將不再響應其他命令。
SAVE和BGSAVE優缺點：
save缺點：快照操作完成之前不再響應其他命令。
save優點：在大數據量的情況下，比bgsave更快速穩定。
運用場景：SAVE一般用在機器沒有足夠內存執行BGSAVE
或是接收到SHUTDOWN關機命令請求時用。
比如寫個腳本，在凌晨3點訪問量很小的時候，執行save快照操作。
bgsave缺點：在大數據量的情況下，BGSAVE的子進程由於要把內存裏的數據寫入到硬盤，
子進程會耗費越來越多時間。
如果達到十幾GB數據量的話，BGSAVE可能會導致系統長時間的停頓
bgsave優點：快照操作時不影響redis服務器繼續接受請求，做出響應。
運用場景：非十幾GB的大數據量情況下都適合。
快照snapshotting配置選項
編輯redis.conf
save 60 1000
//多久執行一次bgsave自動快照操作,當滿足 60秒之內有1000次寫入即觸發。
save 3600 1
//該條配置可以有多個，任意一個滿足一次，執行一次。一小時之內只要有一條寫操作就執行快照操作
stop-writes-on-bgsave-error no
//創建快照失敗後是否繼續寫操作
rdbcompression yes
//是否對快照文件壓縮
dbfilename dump.rdb
//快照寫入文件的名稱
dir ./
//快照文件的指定路徑
snapshotting快照持久化運用場景
快照是將某一時間點在內存裏的數據進行寫入操作到硬盤。
也就是說在本次快照操作完成之後，
下一次時間點快照操作到來之前的這段時間內發生系統崩潰，
或是硬件問題，這段時間內產生的數據將會丟失。
所以快照適合對小數據丟失有一定容忍的應用和場景。
1購物車（查詢簡單|經常變更|數據量級不大|弱化事務|安全級別低）
2促銷活動規則（存儲） | 搶購 緩衝隊列
3和錢無關，支付，銀行
append-only-file(AOF)機制
AOF持久化會將被執行的寫命令追加到原來的AOF文件末尾，
因此redis只要重新執行一遍AOF文件包含的所有寫命令
即可恢復AOF文件所記錄的數據集。
1redis產生fork子進程。
2父進程繼續處理client請求，子進程把aof內容寫入緩衝區。
3子進程寫完退出，父進程接受退出消息，將緩衝區內容寫入AOF文件。
AOF配置選項
編輯redis.conf
appendonly no
//是否啓用aof方式
appendfsync everysec|always|no
//aof文件同步頻率 everysec 每秒執行同步一次，顯示的將多個命令同步到硬盤，也是redis推薦的一
//個。always每個redis寫命令都要同步寫入到硬盤，io操作頻繁影響到redis速度。但是數據最安全的一
//個。no讓操作系統來決定何時該同步。
no-appendfsync-on-rewite no
//再對aof進行壓縮的時候是否執行同步操作
auto-aof-rewrite-percentage 50
//當aof文件大於80MB時並且AOF文件比
auto-aof-rewrite-min-size 80mb
//上次重寫之後體積大了50%,redis將自動執行BGREWRITEAOF命令，
AOF缺陷--aof文件體積問題
表面上看，aof方式既可以把數據丟失降低到1秒（設置成appendfsync everysec），又可以極短時間完成持久化操作，無疑是最好的方式，但是aof有文件過大的問題。隨着redis不斷運行，執行的寫操作越來越多，aof文件不斷追加命令，aof文件將越來越大，極端情況可以用完整個硬盤。另一方面，如果系統崩潰了，在機器重啓後需要執行aof文件來恢復丟失數據，aof文件過大，導致，執行時間會很長。
爲了解決這個問題，就不得不說BGREWRITEAOF命令，
該命令可以移除原有aof文件裏冗餘的寫操作重寫aof文件。但是BGREWRITEAOF命令又出現了快照方式BGSAVE問題，執行BGREWRITEAOF，redis會創建子進程，子進程負責文件重寫，由此帶來的子進程的性能和時間問題同樣存在。
無論使用aof方式還是快照方式來實現持久化都是各有利弊，選用時要因地制宜。
如果有不同見解歡迎大家一起來討論，共同進步@_@。
觀點有參考Josiah L，carlson 所著redis in action。