深刻了解Redis(6)-持久化原理

　　Redis是一個內存數據庫，數據保存在內存中。但咱們都知道存儲在內存中的數據會由於外部因素而丟失，因此Redis會把數據持久化到磁盤中，至因而如何持久化呢？

1、RDB

1.手動觸發

• save：該命令會阻塞當前Redis服務器，執行save命令期間，Redis不能處理其餘命令，直到RDB過程完成爲止。
• bgsave：執行該命令時，Redis會在後臺異步進行快照操做，快照同時還能夠響應客戶端請求。具體操做是Redis進程執行fork操做建立子進程，RDB持久化過程由子進程負責，完成後自動結束。阻塞只發生在fork階段，通常時間很短。基本上 Redis 內部全部的RDB操做都是採用 bgsave 命令。

2.自動觸發

• 根據redis.conf配置裏的save m n定時觸發（用的是BGSAVE）

• 主從複製時，主節點自動觸發

• 執行Debug Relaod

• 執行Shutdown且沒有開啓AOF持久化

# 在幾秒內改動了多少數據就觸發持久化
# 想禁用的話不設置save   或者save ""
save 900 1
save 300 10
save 60 10000
# 備份進程出錯主進程中止寫入操做
stop-writes-on-bgsave-error yes
# 是否壓縮rdb文件 推薦no 相對於硬盤成本cpu更值錢
rdbcompression yes

3.優缺點

優勢：

• 只會生成一個文件，方便操做，文件小
• 相對AOF來講，恢復大數據集的速度快
• 在RDB持久化開始時，只會fork一個子線程處理全部的持久化工做，不會影響到父系線程

缺點：

• 若是你想保證數據的高可用性，即最大限度的避免數據丟失，那麼RDB將不是一個很好的選擇。由於系統一旦在定時持久化以前出現宕機現象，此前沒有來得及寫入磁盤的數據都將丟失。
• 因爲RDB是經過fork子進程來協助完成數據持久化工做的，所以，若是當數據集較大時，可能會致使整個服務器中止服務幾百毫秒，甚至是1秒鐘。

2、AOF

　　全量備份老是耗時的，有時候咱們提供一種更加高效的方式AOF，工做機制很簡單，redis會將每個收到的寫命令都經過write函數追加到文件中。通俗的理解就是日誌記錄。

• 記錄除了查詢之外的全部變動數據庫狀態的指令

• 以append的形式追加保存到AOF文件中（增量）

• 日誌重寫解決AOF文件不斷增大的問題，原理以下

  • 調用fork，建立一個子進程

  • 子進程把新的AOF寫到一個臨時文件裏，不依賴原來的AOF文件

  • 主進程持續將新的變更同時寫到內存和原來的AOF裏

  • 主進程獲取子進程重寫AOF完成信號，往新AOF同步增量變更

  • 使用新的AOF文件替換掉舊的AOF文件

# 默認關閉若要開啓將no改成yes
appendonly no
# append文件的名字
appendfilename "appendonly.aof"
# AOF文件的寫入方式
# always一旦緩存區內容發生變化就寫入AOF文件中
appendfsync always
# everysec 每一個一秒將緩存區內容寫入文件 默認開啓的寫入方式
appendfsync everysec
# 將寫入文件的操做交由操做系統決定
appendfsync no
# 當AOF文件大小的增加率大於該配置項時自動開啓重寫（這裏指超過原大小的100%）。
auto-aof-rewrite-percentage 100
# 當AOF文件大小大於該配置項時自動開啓重寫
auto-aof-rewrite-min-size 64mb

優勢：

• AOF能夠更好的保護數據不丟失，通常AOF會每隔1秒，經過一個後臺線程執行一次fsync操做，最多丟失1秒鐘的數據。
• AOF日誌文件沒有任何磁盤尋址的開銷，寫入性能很是高，文件不容易破損。
• AOF日誌文件即便過大的時候，出現後臺重寫操做，也不會影響客戶端的讀寫。
• AOF日誌文件的命令經過很是可讀的方式進行記錄，這個特性很是適合作災難性的誤刪除的緊急恢復。

缺點：

• AOF日誌文件相對於RDB來講會更大
• AOF開啓後，支持的寫QPS會比RDB支持的寫QPS低

　　經過對比能夠看出單獨使用AOF和RDB都存在很多都問題，因此在redis4.0以後，帶來了新的持久化選項——混合持久化。

3、RDB-AOF混合持久化

　　若是開啓了混合持久化，aof在重寫時，再也不是單純將內存數據轉換爲RESP命令寫入aof文件，而是將重寫這一刻以前的內存作rdb快照處理，而且將rdb快照內容和增量的aof修改內存數據的命令存在一塊兒，都寫入新的aof文件，新的aof文件一開始不叫appendonly.aof，等到重寫完成後，新的aof文件纔會進行更名，原子的覆蓋原有的aof文件，完成新舊兩個aof文件的替換。
因而在redis重啓的時候，能夠先加載rdb文件，而後再重放增量的aof日誌就能夠徹底替代以前的aof全量文件重放，所以重啓效率大幅獲得提升。

　　簡單說就是BGSAVE作鏡像全量持久化，AOF作增量持久化。

注：圖來自網絡

若是redis沒有升級到4.0，優先選擇 RDB 仍是 AOF 呢?

分析對比兩種方式並作了測試後，發現這是兩種不一樣風格的持久化方式。那麼應該如何選擇呢?

• 對於企業級的中大型應用，若是不想犧牲數據完整性可是又但願保持高效率，那麼你應該同時使用 RDB 和 AOF 兩種方式。
• 若是你不打算耗費精力在這個地方，只須要保證數據完整性，那麼優先考慮使用 AOF 方式。
• RDB 方式很是適合大規模的數據恢復，若是業務對數據完整性和一致性要求不高，RDB 是很好的選擇。