Redis持久化---RDB&AOF

Redis是一個內存數據庫系統,爲了保證Redis數據不丟失,Redis有兩種方式實現持久化:RDB和AOF

官網截圖:
在這裏插入圖片描述
解釋:
RDB:在一個時間點對所有的內存數據做一個快照,然後保存下來,每次只保留最新的一份。
AOF:針對每一次“寫操作”,redis服務器都會將該操作以Redis的協議格式追加到日誌文件,每次重啓Redis都會通過讀取日誌文件重構原始的數據集

1、RDB(Redis DataBase)

1.1 RDB詳述
AOF介紹 Redis會單獨創建(fork)一個子進程來進行持久化,會先將數據寫入到一個臨時文件中,待持久化過程都結束了,再用這個臨時文件替換上次持久化好的文件。整個過程中,主進程是不進行任何IO操作的,這就確保了極高的性能如果需要進行大規模數據的恢復,且對於數據恢復的完整性不是非常敏感,那RDB方式要比AOF方式更加的高效。RDB的缺點是最後一次持久化後的數據可能丟失。

fork的作用是複製一個與當前進程一樣的進程。新進程的所有數據(變量、環境變量、程序計數器等) 數值都和原進程一致,但是是一個全新的進程,並作爲原進程的子進程。

rdb 保存的是dump.rdb文件。

1.2 如何觸發RDB快照
有三種情況會觸發RDB進行備份操作

  1. 配置文件中默認的快照配置
    在這裏插入圖片描述
    這是redis.conf的默認配置,解釋一下配置的意思:
    save 900 1 //900秒之內發生了一次寫操作(增刪改)就執行快照備份
    save 300 10 //300秒之內發生了10次寫操作(增刪改)就執行快照備份
    以此類推。。。
    也可以禁用持久化,設置爲:save "" 但一般不會這樣做

  2. 命令save或者是bgsave
    save命令就是立馬執行快照備份,不等到觸發默認的快照配置,因爲有些比較重要的數據需要立馬備份。bgsave也是立馬備份,與save不同的是bgsave是後臺備份,不會阻塞,redis還是可以響應客戶端請求,而save就是其他的不管,全部阻塞。

  3. 執行flushall命令,也會產生dump.rdb文件,但裏面是空的,無意義

1.3 如何恢復快照
將備份文件 (dump.rdb) 移動到 redis 安裝目錄並啓動服務即可,另外,爲了保險起見應該將dump.rdb同時備份到多臺機器防止機器損壞導致文件丟失無法恢復數據。

1.4 RDB的優勢和劣勢

官方解釋:
在這裏插入圖片描述

簡短翻譯一下
優勢:

  • 允許我們保存多個版本的數據備份來防止災難
  • RDB能夠最大化Redis的性能,因爲父進程唯一要做的就是fork一個子進程,剩下的就交給子進程來完成了,父進程不用執行任何I/O操作
  • 相比AOF,RDB更適合大規模數據的恢復

劣勢:

  • 對數據的完整性和一致性保證沒那麼高,故障發生在最後一次備份操作就會丟失最後一次備份後的一些數據
  • RDB需要fork一個子進程進行持久化操作,子進程要複製一份一模一樣的數據這會增加一倍內存的消耗,如果數據量大的話就會影響服務的性能。

總結(圖片來自尚學堂–周陽)
在這裏插入圖片描述

2、AOF(Append Only File)

2.2 AOF詳述
以日誌的形式來記錄每個寫操作,將Redis執行過的所有寫指令記錄下來(讀操作不記錄),只許追加文件但不可以改寫文件,redis啓動之初會讀取該文件重新構建數據,換言之,redis重啓的話就根據日誌文件的內容將寫指令從前到後執行一次以完成數據的恢復工作

Aof保存的是appendonly.aof文件

2.3 配置位置
在這裏插入圖片描述

  • appendonly默認是no,改成yes開啓aof
  • appendfilename默認是appendonly.aof,建議不要修改
  • 最後三個參數是rewrite相關的參數

2.4 rewrite
rewrite是什麼?
AOF採用文件追加方式,文件會越來越大爲避免出現此種情況,新增了重寫機制,當AOF文件的大小超過所設定的閾值時,Redis就會啓動AOF文件的內容壓縮,只保留可以恢復數據的最小指令集.可以使用命令bgrewriteaof

重寫原理是什麼?
AOF文件持續增長而過大時,會fork出一條新進程來將文件重寫(也是先寫臨時文件最後再rename),遍歷新進程的內存中數據,每條記錄有一條的Set語句。重寫aof文件的操作,並沒有讀取舊的aof文件,而是將整個內存中的數據庫內容用命令的方式重寫了一個新的aof文件,這點和快照有點類似

觸發機制?
Redis會記錄上次重寫時的AOF大小,默認配置是當AOF文件大小是上次rewrite後大小的一倍且文件大於64M時觸發

2.5 AOF的優劣勢

官方解釋:
在這裏插入圖片描述

尚學堂老師總結爲:
優勢:

  • 每修改同步:appendfsync always 同步持久化 每次發生數據變更會被立即記錄到磁盤 性能較差但數據完整性比較好
  • 每秒同步:appendfsync everysec 異步操作,每秒記錄 如果一秒內宕機,有數據丟失
  • 不同步:appendfsync no 從不同步

劣勢:

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

2.6 小總結
在這裏插入圖片描述

本筆記內容摘自尚學堂—周陽老師

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章