Redis持久化實踐及災難恢複類比(上)

參考資料：
Redis Persistence http://redis.io/topics/persistence
Google Groups https://groups.google.com/forum/?fromgroups=#!forum/redis-db

一、對Redis持久化的探討與理解

目前Redis持久化的方式有兩種： RDB 和 AOF

首先，我們應該明確持久化的資料有什麼用，答案是用於重啟後的資料恢複。
Redis是一個記憶體資料庫，無論是RDB還是AOF，都只是其保證資料恢複的措施。
所以Redis在利用RDB和AOF進行恢複的時候，都會讀取RDB或AOF檔案，重新載入到記憶體中。

RDB就是Snapshot快照儲存，是預設的持久化方式。
可理解為半持久化模式，即按照一定的策略周期性的將資料儲存到磁碟。
對應產生的資料檔案為dump.rdb，通過設定檔中的save參數來定義快照的周期。
下面是預設的快照設定：

save 900 1    #當有一條Keys資料被改變時，900秒重新整理到Disk一次save 300 10   #當有10條Keys資料被改變時，300秒重新整理到Disk一次save 60 10000 #當有10000條Keys資料被改變時，60秒重新整理到Disk一次

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有它的不足，就是一旦資料庫出現問題，那麼我們的RDB檔案中儲存的資料並不是全新的。
從上次RDB檔案產生到Redis停機這段時間的資料全部丟掉了。

AOF(Append-Only File)比RDB方式有更好的持久化性。
由於在使用AOF持久化方式時，Redis會將每一個收到的寫命令都通過Write函數追加到檔案中，類似於MySQL的binlog。
當Redis重啟是會通過重新執行檔案中儲存的寫命令來在記憶體中重建整個資料庫的內容。
對應的設定參數為：
$ vim /opt/redis/etc/redis.conf

appendonly yes       #啟用AOF持久化方式appendfilename appendonly.aof #AOF檔案的名稱，預設為appendonly.aof# appendfsync always #每次收到寫命令就立即強制寫入磁碟，是最有保證的完全的持久化，但速度也是最慢的，一般不推薦使用。appendfsync everysec #每秒鐘強制寫入磁碟一次，在效能和持久化方面做了很好的折中，是受推薦的方式。# appendfsync no     #完全依賴OS的寫入，一般為30秒左右一次，效能最好但是持久化最沒有保證，不被推薦。

AOF的完全持久化方式同時也帶來了另一個問題，持久化檔案會變得越來越大。
比如我們調用INCR test命令100次，檔案中就必須儲存全部的100條命令，但其實99條都是多餘的。
因為要恢複資料庫的狀態其實檔案中儲存一條SET test 100就夠了。
為了壓縮AOF的持久化檔案，Redis提供了bgrewriteaof命令。
收到此命令後Redis將使用與快照類似的方式將記憶體中的資料以命令的方式儲存到臨時檔案中，最後替換原來的檔案，以此來實現控制AOF檔案的增長。
由於是類比快照的過程，因此在重寫AOF檔案時並沒有讀取舊的AOF檔案，而是將整個記憶體中的資料庫內容用命令的方式重寫了一個新的AOF檔案。
對應的設定參數為:
$ vim /opt/redis/etc/redis.conf

no-appendfsync-on-rewrite yes   #在日誌重寫時，不進行命令追加操作，而只是將其放在緩衝區裡，避免與命令的追加造成DISK IO上的衝突。auto-aof-rewrite-percentage 100 #當前AOF檔案大小是上次日誌重寫得到AOF檔案大小的二倍時，自動啟動新的日誌重寫過程。auto-aof-rewrite-min-size 64mb  #當前AOF檔案啟動新的日誌重寫過程的最小值，避免剛剛啟動Reids時由於檔案尺寸較小導致頻繁的重寫。

到底選擇什麼呢。下面是來自官方的建議：
通常，如果你要想提供很高的資料保障性，那麼建議你同時使用兩種持久化方式。
如果你可以接受災難帶來的幾分鐘的資料丟失，那麼你可以僅使用RDB。
很多使用者僅使用了AOF，但是我們建議，既然RDB可以時不時的給資料做個完整的快照，並且提供更快的重啟，所以最好還是也使用RDB。
因此，我們希望可以在未來（長遠計劃）統一AOF和RDB成一種持久化模式。

在資料恢複方面：
RDB的啟動時間會更短，原因有兩個：
一是RDB檔案中每一條資料只有一條記錄，不會像AOF日誌那樣可能有一條資料的多次操作記錄。所以每條資料只需要寫一次就行了。
另一個原因是RDB檔案的儲存格式和Redis資料在記憶體中的編碼格式是一致的，不需要再進行資料編碼工作，所以在CPU消耗上要遠小於AOF日誌的載入。