轉載： http://blog.163.com/xychenbaihu@yeah/blog/static/1322296552013391942692/
Redis雖然是基於內存的存儲系統，但是它本身是支持內存數據的持久化的，而且提供兩種主要的持久化策略：
RDB快照和AOF日誌。
下面分別介紹這兩種不同的持久化策略::
1、Redis的RDB快照
Redis支持將當前數據的快照存成一個數據文件的持久化機制，即RDB快照。這種方法是非常好理解的，但是一個持續寫入的數據庫如何生成快照呢？
Redis藉助了fork命令的copy on write機制（私有內存非共享內存）。在生成快照時，將當前進程fork出一個子進程，然後在子進程中循環所有的數據，將數據寫成爲RDB文件。
我們可以通過Redis的save指令來配置RDB快照生成的時機，比如你可以配置當10分鐘以內有100次寫入就生成快照，也可以配置當1小時內有 1000次寫入就生成快照，也可以多個規則一起實施。這些規則的定義就在Redis的配置文件中，你也可以通過Redis的CONFIG SET命令在Redis運行時設置規則，不需要重啓Redis。
在redis中配置：
1、save 900 1 #當900秒內有一條Keys數據被改變時，生成RDB；
2、save 300 10 #當300秒內有10條Keys數據被改變時，生成RDB；
3、save 60 10000 #當60秒內有10000條Keys數據被改變時，生成RDB；
RDB文件會壞掉嗎？
Redis的RDB文件不會壞掉，因爲其寫操作是在一個新進程中進行的，當生成一個新的RDB文件時，Redis生成的子進程會先將數據寫到一個臨時文件中，然後通過原子性rename系統調用將臨時文件重命名爲RDB文件，這樣在任何時候出現故障，Redis的RDB文件都總是可用的。
(
同時，Redis 的RDB文件也是Redis主從同步內部實現中的一環。
第一次、Slave向Master同步的實現是：
Slave向Master發出同步請求，Master先dump出rdb文件，然後將rdb文件全量傳輸給slave，然後Master把緩存的寫命令轉發給Slave，初次同步完成。
第二次、以及以後的同步實現是：
Master將變量的快照直接實時依次發送給各個Slave。
但不管什麼原因導致Slave和Master斷開重連都會重複以上兩個步驟的過程。
Redis的主從複製是建立在內存快照的持久化基礎上的，只要有Slave就一定會有內存快照發生。
)
但是，我們可以很明顯的看到，RDB有他的不足，就是一旦Redis出現問題，那麼我們的RDB文件中保存的數據並不是全新的，從上次RDB文件生成到 Redis停機這段時間的數據全部丟掉了。在某些業務下，這是可以忍受的，我們也推薦這些業務使用RDB的方式進行持久化，因爲開啓RDB的代價並不高。 但是對於另外一些對數據安全性要求極高的應用，無法容忍數據丟失的應用，RDB就無能爲力了，所以Redis引入了另一個重要的持久化機制：AOF日誌。
2、 Redis的AOF日誌
AOF日誌的全稱是append only file，從名字上我們就能看出來，它是一個追加寫入的日誌文件。與一般數據庫的binlog不同的是，AOF文件是可識別的純文本，它的內容就是一個個 的Redis標準命令。當然，並不是發送到Redis的所有命令都要記錄到AOF日誌裏面，只有那些會導致數據發生修改的命令纔會追加到AOF文件。
那麼每一條修改數據的命令都生成一條日誌，那麼AOF文件是不是會很大？
答案是肯定的，AOF文件會越來越大，所以Redis又提供了一個功能，叫做AOF rewrite（使用Redis提供了bgrewriteaof命令就可以）。其功能就是重新生成一份AOF文件，新的AOF文件中一條記錄的操作只會有一次，而不像一份老文件那樣，可能記錄了對同一個值的多次操作。其生成過程和RDB類似，也是fork一個進程，直接遍歷數據，寫入新的AOF臨時文件（這個過程和RDB類似，但是是將數據拆分成一條一條寫命令的形式的）。在寫入新文件的過程中，所有的寫操作日誌還是會寫到原來老的
AOF文件中，同時還會記錄在內存緩衝區中。當重完操作完成後，會將所有緩衝區中的日誌一次性寫入到臨時文件中。然後調用原子性的rename命令用新的 AOF文件取代老的AOF文件。(這樣的操作，老的AOF可以恢復內存，如果產生新的AOF，老的就不存在了，可用新的AOF文件恢復內存，這樣同時解決了AOF不斷增長的問題。)AOF是一個寫文件操作，其目的是將操作日誌寫到磁盤上，所以它也同樣會遇到我們上面說的寫操作的5個流程。
那麼寫AOF的操作安全性又有多高呢？
實際上這是可以設置的，在Redis中對AOF調用write(2)寫入後，何時再調用fsync將其寫到磁盤上，通過appendfsync選項來控制，下面 appendfsync的三個設置項，安全強度逐漸變強。
1）appendfsync no
當設置appendfsync爲no的時候，Redis不會主動調用fsync去將AOF日誌內容同步到磁盤，所以這一切就完全依賴於操作系統的調試了。對大多數Linux操作系統，是每30秒進行一次fsync，將緩衝區中的數據寫到磁盤上。
2）appendfsync everysec
當設置appendfsync爲everysec的時候，Redis會默認每隔一秒進行一次fsync調用，將緩衝區中的數據寫到磁盤。但是當這一次的fsync調用時長超過1秒時。Redis會採取延遲fsync的策略，再等一秒鐘。也就是在兩秒後再進行fsync，這一次的fsync就不管會執行多 長時間都會進行。這時候由於在fsync時文件描述符會被阻塞，所以當前的寫操作就會阻塞。
結論就是，在絕大多數情況下，Redis會每隔一秒進行一 次fsync。在最壞的情況下，兩秒鐘會進行一次fsync操作。這一操作在大多數數據庫系統中被稱爲group commit，就是組合多次寫操作的數據，一次性將日誌寫到磁盤。
3）appendfsync always
置appendfsync爲always時，每一次寫操作都會調用一次fsync，這時數據是最安全的，當然，由於每次都會執行fsync，
所以其性能也會受到影響。
Redis數據恢復：
RDB的啓動時間會更短，原因有兩個：
一、RDB文件中每一條數據只有一條記錄，不會像AOF日誌那樣可能有一條數據的多次操作記錄。所以每條數據只需要寫一次就行了。
二、RDB文件的存儲格式和Redis數據在內存中的編碼格式是一致的，不需要再進行數據編碼工作，所以在CPU消耗上要遠小於AOF日誌的加載。
