Redis：持久化篇

1、什麼是 Redis 的持久化

• rdb和aof

2、RDB（Redis DataBase）：

一、RDB是什麼?

• 在指定的時間間隔內將內存中的數據集快照寫入磁盤， 也就是行話講的：Snapshot快照，它恢復時是將快照文件直接讀到內存裏
• Redis會單首創建（fork拷貝）一個子進程來進行持久化，會先將數據寫入到一個臨時文件中，待持久化過程都結束了，再用這個臨時文件替換上次持久化好的文件。好比：第一次存儲5條數據到dump.rdb文件中，5分鐘後，第二次存儲20到條dump.rdb文件中，就把第一次的覆蓋了。
• 整個過程當中，主進程是不進行任何IO操做的，這就確保了極高的性能。若是須要進行大規模數據的恢復，且對於數據恢復的完整性不是很是敏感， 那RDB方式要比AOF方式更加的高效。
• RDB的缺點：最後一次持久化後的數據可能丟失。好比：服務器恰好炸了。

二、Fork

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

三、RDB 保存的是 dump.rdb文件。

四、配置位置：redis.conf 的 SNAPSHOTTING

五、配置詳解：

在磁盤上保存數據的命令：save <seconds> <changes>

如下狀況3選1，將會觸發數據庫保存：

• 900秒（15分鐘）內，若是至少增刪改了1個key，觸發數據庫保存，會產生dump.rdb文件，默默地保存到磁盤中。
• 300秒（5分鐘）內，若是至少改變了10個key，觸發數據庫保存，會產生dump.rdb文件，默默地保存到磁盤中。
• 60秒內，若是至少改變了10000個key，觸發數據庫保存，會產生dump.rdb文件，默默地保存到磁盤中。

手動當即保存：

• set key value -> save

不保存：

• 註釋掉上面的配置便可。

注意：

• 執行ShutDown，至關於MySQL的commit，會當即生成dump.rdb文件。此時，若是以前執行FLUSHALL，把數據庫清空，此時既清空又提交，生成的dump.rdb是空的文件。因此，恢復的文件也是空的。

恢復：

• 遠程服務器已備份的數據拷貝到生產機器，命名爲：dump.rdb便可。

stop-writes-on-bgsave-error：後臺save出錯，那麼就中止寫入，出錯就剎車。

rdbcompression：是否啓用壓縮算法，默認開啓。

rdbchecksum：用於數據校驗。

六、如何觸發RDB快照（3種方式）

• 配置文件中默認的快照配置（3種策略）
• 命令save或者bgsave。Save：save時只管保存，其它無論，所有阻塞。BGSAVE：Redis會在後臺異步進行快照操做，快照同時還能夠響應客戶端請求。能夠經過：lastsave，獲取最後一次成功執行快照的時間
• 執行flushall命令，也會產生dump.rdb文件，但裏面是空的，無心義

七、RDB優點和劣勢：

• 優點：適合大規模的數據恢復；對數據完整性和一致性要求不高
• 劣勢：在必定間隔時間作一次備份，因此若是redis意外down掉的話，就會丟失最後一次快照後的全部修改的時候；內存中的數據被克隆了一份，大體2倍的膨脹性須要考慮。

八、如何中止：

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

3、AOF（Append Only File）

一、AOF是什麼?

• 是記錄操做者的全部寫操做，數據恢復的時候，把全部寫操做執行一遍。
• 以日誌的形式來記錄每一個寫操做，將Redis執行過的全部寫指令記錄下來(讀操做不記錄)，只許追加文件但不能夠改寫文件，redis重啓的話就根據日誌文件的內容，將寫指令從頭至尾執行一次以完成數據的恢復工做。

二、AOF 保存的是 appendonly.aof文件

三、配置的位置：redis.conf 的 APPEND ONLY MODE

四、配置詳解：

appendfsync ：同步寫的策略，有三種

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

默認AOF文件名：appendonly.aof

AOF啓動，修復，恢復：

一、啓動 AOF

AOF持久化存儲方式默認關閉，設置yes就是啓動持久化

二、修復 AOF

若是我在上面文件的後面，模擬文件損壞的場景，可否成功啓動redis？同時存在rdb 和aof ，二者可否共存，能的話優先加載誰？

模擬：

啓動：

第一問：啓動失敗；

第二問：能夠共存；

第三問：優先加載 aof 文件，由於 rdb 文件是正常的，aof 文件是損壞的，加載失敗的緣由是 aof 文件損壞，因此得出：優先加載 aof 文件

三、如何修復 aof 文件？

輸入命令：redis-check-aof --fix appendonly.aof

Rewrite(AOF文件自我瘦身)：

一、是什麼？

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

二、重寫原理：

• AOF文件持續增加而過大時，會fork出一條新進程來將文件重寫。重寫aof文件的操做，並無讀取舊的aof文件，而是將整個內存中的數據庫內容用命令方式重寫了一個新的aof文件，這點和快照有點相似。

三、觸發條件:

• redis會記錄上次重寫時的AOF大小，默認配置：是當AOF文件大小是上次rewrite後大小的一倍，且文件大於64M時觸發，高併發系統絕對不止64mb。

auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
複製代碼

AOF優點和劣勢：

• 優點：能夠靈活設置同步寫的策略；數據比較完整
• 劣勢：相同數據集的數據而言aof文件要遠大於rdb文件，恢復速度慢於rdb；aof運行效率要慢於rdb，每秒同步策略效率較好，不一樣步效率和rdb相同

4、RDB or AOF

• 同時開啓兩種持久化方式：在這種狀況下，當redis重啓的時候會優先載入AOF文件來恢復原始的數據。
• 由於在一般狀況下AOF文件保存的數據集要比RDB文件保存的數據集要完整。
• RDB的數據不實時，同時使用二者時服務器重啓也只會找AOF文件。那要不要只使用AOF呢？建議不要，由於RDB更適合用於備份數據庫(AOF在不斷變化很差備份)。

5、面試：

一、什麼是持久化？

• rdb和aof

二、若是dump.rdb和appendonly.aof能夠共存，同時存在的狀況下，會先加載誰？

• 優先加載appendonly.aof