redis持久化詳解

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關機命令請求時用。

                   比如寫個腳本，在凌晨5點訪問量很小的時候，執行save快照操作。

bgsave缺點：在大數據量的情況下，BGSAVE的子進程由於要把內存裏的數據寫入到硬盤，子進程會耗費越來越多時間。

                       如果達到十幾GB數據量的話，BGSAVE可能會導致系統長時間的停頓

bgsave優點：快照操作時不影響redis服務器繼續接受請求，做出響應。

運用場景：非十幾GB的大數據量情況下一般都適合用bgsave命令執行快照操作。

快照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 每秒執行同步一次，顯示的將多個命令同步到硬盤，也是推薦的一個

                                                      //always每個redis寫命令都要同步寫入到硬盤，io操作頻繁影響到redis速度。

                                                      // 但是數據最安全的一個。

                                                      //no讓操作系統來決定何時該同步。

                                                       

no-appendfsync-on-rewite no          //再對aof進行壓縮的時候是否執行同步操作

auto-aof-rewrite-percentage 50       //當aof文件大於80MB時並且AOF文件比上次重寫之後體積大了50%

auto-aof-rewrite-min-size 80mb       //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。