redis持久化緩衝相關理解，redis緩衝

redis持久化緩衝相關理解，redis緩衝
redis 持久化緩衝：

一：SNAPSHOTTING（快照方式 -》二進位檔案）

①定時產生快照

②定量產生快照

觀察redis的設定檔中的SNAPSHOTTING設定模組的設定資訊，我們可以發現

已經對save命令的意思做出瞭解釋，現在我再來說一下，意思就是：

save? 900? 1????? 每900秒(15分鐘)至少一次索引值變更時被觸發；

?

 

##當snapshot時出現錯誤無法繼續時，是否阻塞用戶端“變更操作”，“錯誤”可能因為磁碟已滿/磁碟故障/OS層級異常等  stop-writes-on-bgsave-error yes  

rdbcompression?

RDB檔案過大時，是可以壓縮的，Redis預設開啟壓縮，當然也可以通過配置rdbcompression參數來禁用壓縮。

 

壓縮和不壓縮的優缺點：

壓縮：

優點：減少磁碟儲存空間缺點：消耗CPU資源

不壓縮：

優點：不消耗CPU資源缺點：佔用磁碟空間多

 

如何選擇？ 那就需要看需求、看伺服器資源情況了。

 

RDB的快照過程：

 

1.redis 調用 fork,現在有了子進程和父進程。

2. 父進程繼續處理 client 請求，子進程負責將記憶體內容寫入到臨時檔案。由於 os 的即時複製機制（ copy on write)父子進程會共用相同的物理頁面，當父進程處理寫請求時 os 會為父進程要修改的頁面棄置站台，而不是寫共用的頁面。所以子進程地址空間內的資料是 fork時刻整個資料庫的一個快照。

3.當子進程將快照寫入臨時檔案完畢後，用臨時檔案替換原來的快照檔案，然後子進程退出。client 也可以使用 save 或者 bgsave 命令通知 redis 做一次快照持久化。 save 操作是在主線程中儲存快照的，由於 redis 是用一個主線程來處理所有 client 的請求，這種方式會阻塞所有client 請求。所以不推薦使用。另一點需要注意的是，每次快照持久化都是將記憶體資料完整寫入到磁碟一次，並不是增量的只同步變更資料。如果資料量大的話，而且寫操作比較多，必然會引起大量的磁碟 io 操作，可能會嚴重影響效能。

 

 

手動快照：

 

如果沒有觸發自動快照，可以對redis進行手動快照操作，SAVE和BGSAVE都可以執行手動快照，兩個命令的區別是前者是由主進程進行快照操作，會阻塞其他請求；而後者是通過fork子進程進行快照操作。

 

注意：

由於redis使用fork來複製一份當前進程，那麼子進程就會佔有和主進程一樣的記憶體資源，比如說主進程8G記憶體，那麼在備份的時候必須保證有16G記憶體，要不然會啟用虛擬記憶體，效能非常差。

二：APPEND ONLY MODE（aof類似於預寫記錄檔）

①後台執行

②邊服務邊備份

 

Redis AOF是類似於log的機制，每次寫操作都會寫到硬碟上，當系統崩潰時，可以通過AOF來恢複資料。每個帶有寫操作的命令被Redis伺服器端收到運行時，該命令都會被記錄到AOF檔案上。由於只是一個append到檔案操作，所以寫到硬碟上的操作往往非常快。

其實Redis oaf機制包括了兩件事，rewrite和AOF。rewrite類似於普通資料庫管理系統日誌復原點，當AOF檔案隨著寫命令的運行膨脹時，當檔案大小觸碰到臨界時，rewrite會被運行。
rewrite會像replication一樣，fork出一個子進程，建立一個臨時檔案，遍曆資料庫，將每個key、value對輸出到臨時檔案。輸出格式就是Redis的命令，但是為了減小檔案大小，會將多個key、value對集合起來用一條命令表達。在rewrite期間的寫操作會儲存在記憶體的rewrite buffer中，rewrite成功後這些操作也會複製到臨時檔案中，在最後臨時檔案會代替AOF檔案。

以上在AOF開啟的情況下，如果AOF是關閉的，那麼rewrite操作可以通過bgrewriteaof命令來進行。

 

Redis Bgrewriteaof 命令用於非同步執行一個 AOF（AppendOnly File） 檔案重寫操作。重寫會建立一個當前 AOF 檔案的體積最佳化版本。

即使 Bgrewriteaof 執行失敗，也不會有任何資料丟失，因為舊的 AOF 檔案在 Bgrewriteaof 成功之前不會被修改。

注意：從 Redis 2.4 開始， AOF 重寫由 Redis 自行觸發， BGREWRITEAOF 僅僅用於手動觸發重寫操作。

 

 

自動的bgrewriteaof

為了避免aof檔案過大，我們會周期性的做bgrewriteaof來重整aof檔案。以前我們會額外的配置crontab在業務低峰期執行這個命令，這額外的增加一個workaroud的指令碼任務在大叢集裡是很糟糕的，不易檢查，出錯無法即時發現。

於是這個自動bgrewriteaof功能被直接加到redis的內部。首先對於aof檔案，server對象添加一個欄位來記錄aof檔案的大小server.appendonly_current_size，每次aof發生變化都會維護這個欄位。

bgrewriteaof完畢或者執行個體啟動載入aof資料後也會調用aofUpdateCurrentSize這個函數維護這個欄位，同時會記錄下此時的aof檔案的大小server.auto_aofrewrite_base_size作為基準值，用於接下來判斷aof增長率。

有了當前值和基準值我們就可以判斷aof檔案的增長情況。另外還需要配置兩個參數來判斷是否需要自動觸發bgrewriteaof。

?auto-aof-rewrite-percentage：aof檔案的大小超過基準百分之多少後觸發bgrewriteaof。預設這個值設定為100，意味著當前aof是基準大小的兩倍的時候觸發bgrewriteaof。把它設定為0可以禁用自動觸發的功能。
auto-aof-rewrite-min-size: 當前aof檔案大於多少位元組後才觸發。避免在aof較小的時候無謂行為。預設大小為64mb。
兩個參數都是可以在conf裡靜態配置，或者通過config set來動態修改的。

appendonly? 是否開啟aof緩衝機制

appendfilename??? aof檔案的名稱

appendfsync?? 的三種執行方式：

 

調用fsync()方式讓作業系統寫資料到磁碟上，資料同步方式，有下列三種模式

always????????? 每次都調用，比如安全，但速度最慢；

everysec?????? 每秒同步，這也是預設；

no ? ? ???????? 不調用fsync，由作業系統決定何時同步，比如快的模式；

no-appendfsync-on-rewrite?? no

 

如上面所說到的bgrewriteaof機制，在一個子進程中進行aof的重寫，從而不阻塞主進程對其餘命令的處理，同時解決了aof檔案過大問題。現在問題出現了，同時在執行bgrewriteaof操作和主進程寫aof檔案的操作，兩者都會操作磁碟，而bgrewriteaof往往會涉及大量磁碟操作，這樣就會造成主進程在寫aof檔案的時候出現阻塞的情形，現在no-appendfsync-on-rewrite參數出場了。如果該參數設定為no，是最安全的方式，不會遺失資料，但是要忍受阻塞的問題。如果設定為yes呢？這就相當於將appendfsync設定為no，這說明並沒有執行磁碟操作，只是寫入了緩衝區，因此這樣並不會造成阻塞（因為沒有競爭磁碟），但是如果這個時候redis掛掉，就會遺失資料。丟失多少資料呢？在linux的作業系統的預設設定下，最多會丟失30s的資料。

因此，如果應用系統無法忍受延遲，而可以容忍少量的資料丟失，則設定為yes。如果應用系統無法忍受資料丟失，則設定為no。

三.總結：

AOF和RDB各有優缺點，這是有它們各自的特點所決定：

1) AOF更加安全，可以將資料更加及時的同步到檔案中，但是AOF需要較多的磁碟IO開支，AOF檔案尺寸較大，檔案內容恢複數度相對較慢。
*2) snapshot，安全性較差，它是“正常時期”資料備份以及master-slave資料同步的最佳手段，檔案尺寸較小，恢複數度較快。

可以通過設定檔來指定它們中的一種，或者同時使用它們(不建議同時使用)，或者全部禁用，在架構良好的環境中，master通常使用AOF，slave使用snapshot，主要原因是master需要首先確保資料完整性，它作為資料備份的第一選擇；slave提供唯讀服務(目前slave只能提供讀取服務)，它的主要目的就是快速響應用戶端read請求；但是如果你的redis運行在網路穩定性差/實體環境糟糕情況下，建議你master和slave均採取AOF，這個在master和slave角色切換時，可以減少“人工資料備份”/“人工引導資料恢複”的時間成本；如果你的環境一切非常良好，且服務需要接收密集性的write操作，那麼建議master採取snapshot，而slave採用AOF。

Redis資料恢複

當redis伺服器掛掉時,重啟時將按以下優先順序恢複資料到記憶體種:

1.?如果只配置了AOF,重啟時載入AOF檔案恢複資料.

2.?如果同時配置了RBD和AOF,啟動時只載入AOF檔案恢複資料.

3.?如果只配置了RDB,啟動時將載入dump檔案恢複資料。