Redis持久化方式

rdb全稱redis database，在指定的時間間隔內將記憶體中的資料集快照寫入磁碟，也就是行話講的snapshot快照，它恢復時直接將快照檔案直接讀到記憶體裡；在預設情況下，redis 將記憶體資料庫快照儲存在名字為 dump.rdb 的二進位制檔案中，有手動觸發和自動觸發兩種方式。

手動觸發：s**e 和 bgs**e 兩命令

s**e命令：阻塞當前 redis，直到 rdb 持久化過程完成為止，若記憶體例項比較大會造成長時間阻塞，線上環境不建議用它

bgs**e命令：

redis會在後台非同步進行快照操作，快照同時還可以響應客戶端請求。可以通過lasts**e命令獲取最後一次成功執行快照的時間。redis 程序執行 fork 操作建立子執行緒，由子執行緒完成持久化，阻塞時間很短(微秒級)，是 s**e 的優化，在執行 redis-cli shutdown 關閉 redis 服務時，如果沒有開啟 aof 持久化，自動執行 bgs**e;

bgs**e的寫時複製(cow)機制

redis 借助作業系統提供的寫時複製技術（copy-on-write, cow），在生成快照的同時，依然可以正常處理寫命令。簡單來說，bgs**e 子程序是由主線程 fork 生成的，可以共享主線程的所有記憶體資料。bgs**e 子程序執行後，開始讀取主線程的記憶體資料，並把它們寫入 rdb 檔案。此時，如果主線程對這些資料也都是讀操作，那麼，主線程和 bgs**e 子程序相互不影響。但是，如果主線程要修改一塊資料，那麼，這塊資料就會被複製乙份，生成該資料的副本。然後，bgs**e 子程序會把這個副本資料寫入 rdb 檔案，而在這個過程中，主線程仍然可以直接修改原來的資料。

自動觸發：

通過配置檔案對 redis 進行設定，讓它在「n 秒內資料集至少有 m 個改動」這一條件被滿足時，自動進行資料集儲存操作。

rdb相關配置：

rdb自動持久化規則

#當 900 秒內有至少有 1 個鍵被改動時，自動進行資料集儲存操作

s**e 900 1

#當 300 秒內有至少有 10 個鍵被改動時，自動進行資料集儲存操作

s**e 300 10

#當 60 秒內有至少有 10000 個鍵被改動時，自動進行資料集儲存操作

s**e 60 10000

#rdb持久化檔名

dbfilename dump.rdb

#資料持久化檔案儲存目錄

dir /var/lib/redis

#bgs**e發生錯誤時是否停止寫入，通常為yes

stop-writes-on-bgs**e-error yes

#對於儲存到磁碟的快照，是否啟用lzf演算法進行壓縮儲存，預設是yes，但會消耗一定cpu。

rdbcompression yes

# 在儲存快照後，是否讓redis使用crc64演算法來進行資料校驗，通常為yes

rdbchecksum yes

優點：整個redis資料庫將只包含乙個檔案 dump.rdb，方便持久化

壓縮後的二進位製文，方便備份、全量複製，災性好

效能最大化，fork子程序來完成寫操作，讓主程序繼續處理命令，所以是io最大化，使用單獨的子程序來進行持久化，主程序不會進行任何io操作，保證了redis的高效能

相對於資料集大時，比aof的啟動效率更高

缺點：

資料安全性低。rdb 是間隔一段時間進行持久化，如果持久化時redis 發生故障，會發生資料丟失，所以這種更適用於資料要求不嚴謹的場景

由於rdb是通過fork子程序來協助完成資料持久化工作的，因此，如果當資料集較大時，可能會導致整個伺服器停止服務幾百毫秒，甚至是1秒鐘

儲存後的二進位制檔案，存在老版本不相容新版本rdb檔案的問題

比如執行命令set name james，aof檔案裡會記錄如下資料

這是一種resp協議格式資料，星號後面的數字代表命令有多少個引數，$號後面的數字代表這個引數有幾個字元注意，如果執行帶過期時間的set命令，aof檔案裡記錄的是並不是執行的原始命令，而是記錄key過期的時間戳

比如執行set age 20 ex 1000，對應aof檔案裡記錄如下

aof相關配置　

啟用aof持久化方式

//每收到寫命令就立即強制寫入磁碟，最慢的，但是保證完全的持久化，不推薦使用

//每秒強制寫入磁碟一次，效能和持久化方面做了折中，只會丟失一秒鐘的資料，推薦

//從不進行寫入，更不安全的選擇

aof重寫

aof檔案裡可能有太多沒用指令，所以aof會定期根據記憶體的最新資料生成aof檔案，例如執行如下幾條命令：

此時，aof檔案裡的內容為：

重寫aof後：

如下兩個配置可以控制aof自動重寫頻率

auto-aof-rewrite-percentage 100 //

aof檔案大小比起上次重寫時的大小,增長率100%時,重寫

auto-aof-rewrite-min-size 64mb //

aof檔案,至少超過64m時,重寫

當然aof還可以手動重寫，進入redis客戶端執行命令bgrewriteaof重寫aof

注意，aof重寫redis會fork出乙個子程序去做(與bgs**e命令類似)，不會對redis正常命令處理有太多影響

aof重寫原理:

aof重寫並不是對原有aof檔案進行任何寫入和讀取，它針對的是資料庫中鍵的當前值。將當前資料庫中的資料轉換成一系列的redis的操作指令，儲存到乙個新的aof日誌檔案中，完畢後再將操作期間發生的增量aof日誌追加到這個新的aof日誌檔案中，追加完畢後就立即替換舊的aof。在重寫的過程中，由於redis還會有新的寫入，為了避免資料丟失，會開闢一塊記憶體用於存放重寫期間產生的寫入操作，等到重寫完畢後會將這塊記憶體中的操作再追加到aof檔案中。如果在重寫過程中redis的寫入很頻繁或寫入量很大，就會導致占用大量額外的記憶體來快取寫操作，導致記憶體爆漲

優點：

資料安全，redis中提供了3種同步策略，即每秒同步、每修改同步和不同步。事實上，每秒同步也是非同步完成的，其效率也是非常高的，所差的是一旦系統出現宕機現象，那麼這一秒鐘之內修改的資料將會丟失，而每修改同步，我們可以將其視為同步持久化，即每次發生的資料變化都會被立即記錄到磁碟中

aof機制的rewrite模式。定期對aof檔案進行重寫，以達到壓縮的目的

缺點：

aof 檔案比 rdb 檔案大，且恢復速度慢

資料集大的時候，比rdb 啟動效率低

執行效率沒有rdb高

aof檔案比rdb更新頻率高，優先使用aof還原資料。

重啟 redis 時，我們很少使用 rdb來恢復記憶體狀態，因為會丟失大量資料。我們通常使用 aof 日誌重放，但是重放 aof 日誌效能相對 rdb來說要慢很多，這樣在 redis 例項很大的情況下，啟動需要花費很長的時間。 redis 4.0 為了解決這個問題，帶來了乙個新的持久化選項——混合持久化。整合了 rdb 和 aof 的優點

通過如下配置可以開啟混合持久化(必須先開啟aof)：

aof‐use‐rdb‐preamble yes //

開啟混合持久化，必須先開啟aof

混合持久化aof檔案結構如下：

redis資料備份策略：

1. 寫crontab定時排程指令碼，每小時都copy乙份rdb或aof的備份到乙個目錄中去，僅僅保留最近48小時的備份

2. 每天都保留乙份當日的資料備份到乙個目錄中去，可以保留最近1個月的備份

3. 每次copy備份的時候，都把太舊的備份給刪了

4. 每天晚上將當前機器上的備份複製乙份到其他機器上，以防機器損壞

Redis持久化方式

Redis持久化方式

Redis持久化方式介紹

redis的持久化方式

Redis持久化方式

Redis持久化方式

Redis持久化方式介紹

redis的持久化方式

相關推薦