標籤:格式 資料 寫入 一致性 速度 資料存放區 檔案中 過程 sadd
redis是記憶體資料庫,它把資料存放區在記憶體中,這樣在加快讀取速度的同時也對資料安全性產生了新的問題,即當redis所在伺服器發生宕機後,redis資料庫裡的所有資料將會全部丟失。為瞭解決這個問題,redis提供了持久化功能——RDB和AOF。通俗的講就是將記憶體中的資料寫入硬碟中。
一、RDB持久化
RDB持久化是指在指定的時間間隔內將記憶體中的資料集快照寫入磁碟,實際操作過程是fork一個子進程,先將資料集寫入臨時檔案,寫入成功後,再替換之前的檔案。當redis所在的伺服器發生宕機,重啟會自動載入rdb檔案,恢複資料。實際生產中,rdb備份檔案通常儲存在兩個伺服器上。防止伺服器發生故障,備份檔案也丟失。
1、自動觸發
在conf設定檔中:
save 900 1save 300 10save 60 10000
注意:你可以注釋掉所有的 save 行來停用儲存功能。也可以直接一個Null 字元串來實現停用:save ""
當上面三個條件中有一個符合就會觸發RDB
2、手動觸發
當然如果不滿足上麵條件,也可以手動觸發RDB
1)、SAVE是阻塞式的RDB持久化,當執行這個命令時redis的主進程把記憶體裡的資料庫狀態寫入到RDB檔案中,直到該檔案建立完畢的這段時間內redis將不能處理任何命令請求。
2)、BGSAVE屬於非阻塞式的持久化,它會建立一個子進程專門去把記憶體中的資料庫狀態寫入RDB檔案裡,同時主進程還可以處理來自用戶端的命令請求。但子進程基本是複製的父進程,這等於兩個相同大小的redis進程在系統上運行,會造成記憶體使用量率的大幅增加。
redis 127.0.0.1:6379> set k1 v1OKredis 127.0.0.1:6379> saveOKredis 127.0.0.1:6379>
3、優缺點
優點:
1、採用這種方式,一旦系統出現故障,就可以用rdb檔案進行恢複
2、在開始持久化時,它唯一需要做的只是fork出子進程,之後再由子進程完成這些持久化的工作,這樣就可以極大的避免服務進程執行IO操作了。
3、RDB採用全量寫入,當資料發生變化,就會產生新的rdb檔案來替代舊的rdb檔案,相對於AOF,RDB恢複啟動效率更高
缺點:
1、系統一旦在定時持久化之前出現宕機現象,最後一次沒有來得及寫入磁碟的資料都將丟失。
2、由於RDB是通過fork子進程來協助完成資料持久化工作的,因此,如果當資料集較大時,可能會導致整個伺服器停止服務幾百毫秒,甚至是1秒鐘。
一、AOF持久化
與RDB的儲存整個redis資料庫狀態不同,AOF是通過儲存對redis服務端的寫命令(如set、sadd、rpush)來記錄資料庫狀態的,即儲存你對redis資料庫的寫操作,只許追加檔案,不可改寫檔案,redis啟動之初會讀取該檔案將寫指令從前到後執行一次以完成資料的恢複工作。
1、配置
appendonly yesappendfilename "appendonly.aof"
appendonly no修改為appendonly yes
appendfsync alwaysappendfsync everysecappendfsync no
no表示不執行fsync,由作業系統保證資料同步到磁碟,速度最快。
always表示每次寫入都執行fsync,以保證資料同步到磁碟。
everysec表示每秒執行一次fsync,可能會導致丟失這1s資料
如果redis開啟了AOF持久化功能,那麼當redis服務重啟時會優先使用AOF檔案來還原資料庫。
2、aof檔案修複
萬一aof檔案遭到破壞,就可以使用命令redis-check-aof.exe appendonly.aof來修複。
3、優缺點
優點:
1)、Redis中提供了3中同步策略,即每秒同步、每修改同步和不同步。預設策略是每秒同步,效率高,所一旦系統出現宕機現象,那麼只會丟失一秒鐘之內修改的資料。
2)、採用增量寫入的方式,在寫入過程中即使出現宕機現象,也不會破壞記錄檔中已經存在的內容。即使出現亂碼,也可以通過redis-check-aof工具來協助我們解決資料一致性的問題。
3)、如果日誌過大,Redis可以自動啟用rewrite機制。
4). AOF包含一個格式清晰、易於理解的記錄檔用於記錄所有的修改操作。使用者可以通過該檔案完成資料的重建。
缺點:
1). 對於相同數量的資料集而言,AOF檔案通常要大於RDB檔案。RDB 在恢複大資料集時的速度比 AOF 的恢複速度要快。
2). 根據同步策略的不同,AOF在運行效率上往往會慢於RDB。總之,每秒同步策略的效率是比較高的,同步禁用策略的效率和RDB一樣高效。
redis學習(四)redis持久化之RDB、AOF