redis的持久化機制 (RDB&AOF)

爲了可以重用Redis數據，或者防止系統故障，咱們須要將Redis中的數據寫入到磁盤空間中，即持久化。Redis提供了兩種不一樣的持久化方法能夠將數據存儲在磁盤中，一種叫快照RDB，另外一種叫只追加文件AOF

RDB

是什麼

  在指定的時間間隔內將內存中的數據集快照寫入磁盤(Snapshot)，它恢復時是將快照文件直接讀到內存裏。

  Redis會單首創建（fork）一個子進程來進行持久化，會先將數據寫入到一個臨時文件中，待持久化過程都結束了，再用這個臨時文件替換上次持久化好的文件。整個過程當中，主進程是不進行任何IO操做的，這就確保了極高的性能若是須要進行大規模數據的恢復，且對於數據恢復的完整性不是很是敏感，那RDB方式要比AOF方式更加的高效。RDB的缺點是最後一次持久化後的數據可能丟失。

Fork

  Fork的做用是複製一個與當前進程同樣的進程。新進程的全部數據（變量、環境變量、程序計數器等）數值都和原進程一致，可是是一個全新的進程，並做爲原進程的子進程。Rdb 保存的是dump.rdb文件。

配置位置

   Redis的配置主要放置在redis.conf，能夠經過修改配置文件實現Redis許多特性，好比複製，持久化，集羣等。

如何觸發RDB快照

• 配置文件中默認的快照配置
• 命令save或者是bgsave

Save：save時只管保存，其它無論，所有阻塞。
BGSAVE：Redis會在後臺異步進行快照操做，快照同時還能夠響應客戶端請求。
        能夠經過lastsave命令獲取最後一次成功執行快照的時間。
複製代碼

• 執行flushall命令，也會產生dump.rdb文件

如何恢復

將備份文件dump.rdb移動到redis安裝目錄並啓動服務便可

優點

適合大規模的數據恢復
對數據完整性和一致性要求不高

劣勢

在必定間隔時間作一次備份，因此若是redis意外down掉的話，就會丟失最後一次快照後的全部修改。

如何中止

動態全部中止RDB保存規則的方法：redis-cli config set save " "

AOF(Append Only File)

是什麼

  以日誌的形式來記錄每一個寫操做，將Redis執行過的全部寫指令記錄下來(讀操做不記錄)，只許追加文件但不能夠改寫文件，redis啓動之初會讀取該文件從新構建數據，換言之，redis重啓的話就根據日誌文件的內容將寫指令從前到後執行一次以完成數據的恢復工做。AOF保存的是appendonly.aof文件

AOF啓動/修復/恢復

• 正常恢復:
  • 啓動：設置yes;修改默認的appendonly no，改成yes
  • 將有數據的aof文件複製一份保存到對應目錄(config get dir)
  • 恢復：重啓redis而後從新加載
• 異常恢復:
  • 啓動：設置yes;修改默認的appendonly no，改成yes
  • 備份被寫壞的AOF文件
  • 修復：Redis-check-aof --fix進行修復
  • 恢復：重啓redis而後從新加載

Rewrite

• 是什麼:

AOF採用文件追加方式，文件會愈來愈大爲避免出現此種狀況，新增了重寫機制,當AOF文件的大小超過所設定的閾值時，
Redis就會啓動AOF文件的內容壓縮，只保留能夠恢復數據的最小指令集.可使用命令bgrewriteaof
複製代碼

• 重寫原理:

AOF文件持續增加而過大時，會fork出一條新進程來將文件重寫(也是先寫臨時文件最後再rename)，遍歷新進程的內存中數據，
每條記錄有一條的set語句。重寫aof文件的操做，並無讀取舊的aof文件，
而是將整個內存中的數據庫內容用命令的方式重寫了一個新的aof文件，這點和快照有點相似。
複製代碼

• 觸發機制：

Redis會記錄上次重寫時的AOF大小，默認配置是當AOF文件大小是上次rewrite後大小的一倍且文件大於64M時觸發。
複製代碼

優點

• 每修改同步：appendfsync always 同步持久化,每次發生數據變動會被當即記錄到磁盤,性能較差但數據完整性比較好
• 每秒同步：appendfsync everysec 異步操做，每秒記錄,若是一秒內宕機，有數據丟失
• 不一樣步：appendfsync no 從不一樣步

劣勢

• 相同數據集的數據而言aof文件要遠大於rdb文件，恢復速度慢於rdb
• aof運行效率要慢於rdb,每秒同步策略效率較好，不一樣步效率和rdb相同

總結(Which one)

  RDB持久化方式可以在指定的時間間隔能對你的數據進行快照存儲。

  AOF持久化方式記錄每次對服務器寫的操做,當服務器重啓的時候會從新執行這些命令來恢復原始的數據,AOF命令以redis協議追加保存每次寫的操做到文件末尾.Redis還能對AOF文件進行後臺重寫,使得AOF文件的體積不至於過大。

  只作緩存：若是你只但願你的數據在服務器運行的時候存在,你也能夠不使用任何持久化方式。

同時開啓兩種持久化方式

  在這種狀況下,當redis重啓的時候會優先載入AOF文件來恢復原始的數據,由於在一般狀況下AOF文件保存的數據集要比RDB文件保存的數據集要完整.   RDB的數據不實時，同時使用二者時服務器重啓也只會找AOF文件。那要不要只使用AOF呢？做者建議不要，由於RDB更適合用於備份數據庫(AOF在不斷變化很差備份)，快速重啓，並且不會有AOF可能潛在的bug，留着做爲一個萬一的手段。

性能建議

  由於RDB文件只用做後備用途，建議只在Slave上持久化RDB文件，並且只要15分鐘備份一次就夠了，只保留save 900 1這條規則。

  若是Enalbe AOF，好處是在最惡劣狀況下也只會丟失不超過兩秒數據，啓動腳本較簡單隻load本身的AOF文件就能夠了。代價一是帶來了持續的IO，二是AOFrewrite的最後將rewrite過程當中產生的新數據寫到新文件形成的阻塞幾乎是不可避免的。只要硬盤許可，應該儘可能減小AOFrewrite的頻率，AOF重寫的基礎大小默認值64M過小了，能夠設到5G以上。默認超過原大小100%大小時重寫能夠改到適當的數值。

  若是不Enable AOF，僅靠Master-Slave Replication 實現高可用性也能夠。能省掉一大筆IO也減小了rewrite時帶來的系統波動。代價是若是Master/Slave同時倒掉，會丟失十幾分鐘的數據，啓動腳本也要比較兩個Master/Slave中的RDB文件，載入較新的那個,新浪微博就選用了這種架構。