Redis 是內存數據庫，如果不將內存中的數據庫狀態保存到磁盤，那么一旦服務器進程退出，服務器中的數據庫狀態也會消失。所以Redis 提供了持久化功能！

RDB（Redis DataBase）

什么是RDB

在指定的時間間隔內將內存中的數據集快照寫入磁盤，也就是行話講的Snapshot快照，它恢復時是將快照文件直接讀到內存里。

Redis會單獨創建（fork）一個子進程來進行持久化，會先將數據寫入到一個臨時文件中，待持久化過程都結束了，再用這個臨時文件替換上次持久化好的文件。

整個過程中，主進程是不進行任何IO操作的。這就確保了極高的性能。如果需要進行大規模數據的恢復，且對于數據恢復的完整性不是非常敏感，那RDB方式要比AOF方式更加的高效。

RDB的缺點是最后一次持久化后的數據可能丟失。

Fork

Fork的作用是復制一個與當前進程一樣的進程。新進程的所有數據（變量，環境變量，程序計數器等）
數值都和原進程一致，但是是一個全新的進程，并作為原進程的子進程。

Rdb 保存的是 dump.rdb 文件

配置位置及SNAPSHOTTING解析

這里的觸發條件機制，我們可以修改測試一下：

save 180 10 # 180秒內修改10次則觸發RDB

RDB 是整合內存的壓縮過的Snapshot，RDB 的數據結構，可以配置復合的快照觸發條件。
默認：

• 1分鐘內改了1萬次
• 5分鐘內改了10次
• 15分鐘內改了1次

如果想禁用RDB持久化的策略，只要不設置任何save指令，或者給save傳入一個空字符串參數也可以。
若要修改完畢需要立馬生效，可以手動使用 save 命令！立馬生效 !

其余命令解析

Stop-writes-on-bgsave-error：如果配置為no，表示你不在乎數據不一致或者有其他的手段發現和控制，默認為yes。

rbdcompression：對于存儲到磁盤中的快照，可以設置是否進行壓縮存儲。如果是的話，redis會采用LZF算法進行壓縮，如果你不想消耗CPU來進行壓縮的話，可以設置為關閉此功能。

rdbchecksum：在存儲快照后，還可以讓redis使用CRC64算法來進行數據校驗，但是這樣做會增加大約10%的性能消耗，如果希望獲取到最大的性能提升，可以關閉此功能。默認為yes。

如何觸發RDB快照

1、配置文件中默認的快照配置，建議多用一臺機子作為備份，復制一份 dump.rdb
2、命令save或者是bgsave

• save 時只管保存，其他不管，全部阻塞
• bgsave，Redis 會在后臺異步進行快照操作，快照同時還可以響應客戶端請求。可以通過lastsave命令獲取最后一次成功執行快照的時間。

3、執行flushall命令，也會產生 dump.rdb 文件，但里面是空的，無意義 !
4、退出的時候也會產生 dump.rdb 文件！

如何恢復

1、將備份文件（dump.rdb）移動到redis安裝目錄并啟動服務即可。
2、CONFIG GET dir 獲取目錄。

127.0.0.1:6379> config get dir
dir
/usr/local/bin

優點和缺點

優點：
1、適合大規模的數據恢復。
2、對數據完整性和一致性要求不高。

缺點：
1、在一定間隔時間做一次備份，所以如果redis意外down掉的話，就會丟失最后一次快照后的所有修改。
2、Fork的時候，內存中的數據被克隆了一份，大致2倍的膨脹性需要考慮。

RDB小結

• RDB是一個非常緊湊的文件。

• RDB在保存RDB文件時父進程唯一需要做的就是fok出一個子進程，接下來的工作全部由子進程來做，父進程不需要再做其他10

  操作，所以RDB持久化方式可以最大化redis的性能。

• 與AOF相比，在恢復大的數據集的時候，RDB方式會更快一些。

• 數據丟失風險大。

• RDB需要經常fOrk子進程來保存數據集到硬盤上，當數據集比較大的時候，fok的過程是非常耗時的，可能會導致Redis在一些毫秒級不能響應客戶端請求。

AOF（Append Only File）

什么是AOF

以日志的形式來記錄每個寫操作，將Redis執行過的所有指令記錄下來（讀操作不記錄），只許追加文件但不可以改寫文件，redis啟動之初會讀取該文件重新構建數據，換言之，redis重啟的話就根據日志文件的內容將寫指令從前到后執行一次以完成數據的恢復工作。

Aof保存的是 appendonly.aof 文件。

配置

appendonly no # 是否以append only模式作為持久化方式，默認使用的是rdb方式持久化，這種方式在許多應用中已經足夠用了

appendfilename "appendonly.aof" # appendfilename AOF 文件名稱

appendfsync everysec # appendfsync aof持久化策略的配置
  				# no表示不執行fsync，由操作系統保證數據同步到磁盤，速度最快。
 				# always表示每次寫入都執行fsync，以保證數據同步到磁盤。
				# everysec表示每秒執行一次fsync，可能會導致丟失這1s數據。
  
No-appendfsync-on-rewrite #重寫時是否可以運用Appendfsync，用默認no即可，保證數據安全性

Auto-aof-rewrite-min-size # 設置重寫的基準值

Auto-aof-rewrite-percentage #設置重寫的基準值

AOF 啟動/修復/恢復

正常恢復：

• 啟動：設置Yes，修改默認的appendonly no，改為yes。
• 將有數據的aof文件復制一份保存到對應目錄。（config get dir）
• 恢復：重啟redis然后重新加載。

異常恢復：

• 啟動：設置Yes
• 故意破壞 appendonly.aof 文件！
• 修復： redis-check-aof --fix appendonly.aof 進行修復。
• 恢復：重啟 redis 然后重新加載。

Rewrite

是什么：
?AOF 采用文件追加方式，文件會越來越大，為避免出現此種情況，新增了重寫機制，當AOF文件的大小超過所設定的閾值時，Redis 就會啟動AOF 文件的內容壓縮，只保留可以恢復數據的最小指令集，可以使用命令 bgrewriteaof ！
重寫原理：
AOF 文件持續增長而過大時，會fork出一條新進程來將文件重寫（也是先寫臨時文件最后再rename），遍歷新進程的內存中數據，每條記錄有一條的Set語句。重寫aof文件的操作，并沒有讀取舊的aof文件，這點和快照有點類似！
觸發機制：
Redis會記錄上次重寫時的AOF大小，默認配置是當AOF文件大小是上次rewrite后大小的已被且文件大于64M的觸發。

優點和缺點

優點：
1、每修改同步：appendfsync always 同步持久化，每次發生數據變更會被立即記錄到磁盤，性能較差但數據完整性比較好。
2、每秒同步： appendfsync everysec 異步操作，每秒記錄 ，如果一秒內宕機，有數據丟失。
3、不同步： appendfsync no 從不同步。
缺點：
1、相同數據集的數據而言，aof 文件要遠大于 rdb文件，恢復速度慢于 rdb。
2、Aof 運行效率要慢于 rdb，每秒同步策略效率較好，不同步效率和rdb相同。

AOF小結

• AOF文件時一個只進行追加的日志文件。
• Redis可以在AOF文件體積變得過大時，自動地在后臺對AOF進行重寫。
• AOF文件有序地保存了對數據庫執行的所有寫入操作，這些寫入操作以Redis協議的格式保存，因此AOF文件的內容非常容易被人讀懂，對文件進行分析也很輕松。
• 對相同的數據集來說，AOF文件的體積通常要大于RDB文件的體積。
• 根據所使用的fsync策略，AOF的速度可能會慢于RDB。

總結

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

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

3、只做緩存，如果你只希望你的數據在服務器運行的時候存在，你也可以不使用任何持久化。

4、同時開啟兩種持久化方式

• 在這種情況下，當redis重啟的時候會優先載入AOF文件來恢復原始的數據，因為在通常情況下AOF文件保存的數據集要比RDB文件保存的數據集要完整。
• RDB 的數據不實時，同時使用兩者時服務器重啟也只會找AOF文件，那要不要只使用AOF呢？作者建議不要，因為RDB更適合用于備份數據庫（AOF在不斷變化不好備份），快速重啟，而且不會有AOF可能潛在的Bug，留著作為一個萬一的手段。

5、性能建議

• 因為RDB文件只用作后備用途，建議只在Slave上持久化RDB文件，而且只要15分鐘備份一次就夠了，只保留 save 900 1 這條規則。
• 如果Enable AOF ，好處是在最惡劣情況下也只會丟失不超過兩秒數據，啟動腳本較簡單只load自己的AOF文件就可以了，代價一是帶來了持續的IO，二是AOF rewrite 的最后將 rewrite 過程中產生的新數據寫到新文件造成的阻塞幾乎是不可避免的。只要硬盤許可，應該盡量減少AOF rewrite的頻率，AOF重寫的基礎大小默認值64M太小了，可以設到5G以上，默認超過原大小100%大小重寫可以改到適當的數值。
• 如果不Enable AOF ，僅靠 Master-Slave Repllcation 實現高可用性也可以，能省掉一大筆IO，也減少了rewrite時帶來的系統波動。代價是如果Master/Slave 同時倒掉，會丟失十幾分鐘的數據，啟動腳本也要比較兩個 Master/Slave 中的 RDB文件，載入較新的那個，微博就是這種架構。