Redis從入門到放棄 之 數據持久化RDB和AOF

Redis強大的功能很大部分是因爲他把數據緩存在內存中，爲了使Redis在重啓的時候，數據不丟失，就須要已某種方式把數據持久化到磁盤中。Redis持久化的方式有倆種，RDB和AOF。

 

RDB==>Redis DatabaseAOF====>Append Only File

 

一、RDB

①、RDB是以快照的方式對內存中的數據進行存儲。即在 「」制定的時間間隔內「」將內存中的數據快照寫入磁盤（即默認的dump.rdb文件）。重啓或執行其餘恢復命令 時 Redis直接去讀取快照文件（dump.rdb）。

 ②、Redis調用fork()函數 單首創建一個子進程進行持久化操做。Redis持久化時會將數據寫到一個臨時文件中，待持久化過程結束後，再用這個臨時文件替換上次持久化好的文件（在這個持久化過程當中，主進程是不會進行IO操做的）

【fork（）函數經過系統調用建立一個與原來進程幾乎徹底相同的進程，也就是兩個進程能夠作徹底相同的事，但若是初始參數或者傳入的變量不一樣，兩個進程也能夠作不一樣的事。】

③、與RDB持久化相關的  配置信息（在redis.conf文件中）

Redis經過在redis.conf配置文件中配置 在規定時間內的改動次數 來觸發  Redis內存數據持久化的發生：

（格式：save <seconds>  <changes>）

save 900 1 即900秒內至少更改過一個鍵 就會觸發
save 300 10 即300秒內至少更改過10個鍵 就會觸發
save 60 10000 即60秒內至少更改過10000個鍵 就會觸發

此外執行save命令，無需知足 上訴條件 也會迅速生成dump.rdb文件

save "" 表示禁用RDB功能

配置文件中的其餘相關 配置：

a、stop-write-on-bgsave-error  yes

yes 表示若是後臺保存RDB出錯時，就會禁止前臺寫KEY/VALUE

no 表示 不在意數據是否知足一致性，能夠進行更改和寫操做

b、rdbcompress  yes

yes表示對存儲到磁盤中的快照(dump.rdb)進行壓縮操做  （會有必定的性能消耗）

c、rdbchecksum  yes

yes表示存儲快照完成後，讓redis進行數據的校驗。（會有必定的性能消耗）

d、dbfilename  dump.rdb

是對生成的快照文件的命名  即將持久化後的信息保存在這個dump.rdb文件中

e、dir   ./

表示dump.rdb存儲文件的位置

④、rdb快照觸發條件：

a、知足redis.conf文件中的save配置條件

b、執行save命令或 bgsave命令

（save時只管持久化，其餘無論，所有阻塞；bgsave時後臺會異步進行快照持久化操做）

c、執行flushdb或者flushall操做

(flushdb清除當前庫中的數據，flushall清除全部庫中的數據)

d、重啓服務等。

⑤、優缺點

優勢：適合大規模的數據恢復，應爲不是實時的進行持久化操做，因此性能會比aof要好點

缺點：默認在觸發save條件時，也就是會在必定的間隔時間內才作一次數據持久化。因此若是Redis服務器意外宕機，就會丟失最後一次的快照後的所  有修改數據。

  fork()時會開啓一個與主進程如出一轍的子進程進行持久化操做，也就是說內存中的數據被克隆了一份，這就大體形成了2倍的膨脹性，須要考  慮。

 

二、AOF

（他的存在時爲了不RDB丟失最後一次數據的問題而誕生的，迷之誘惑）

與RDB記錄內存數據到dump.rdb文件中不同，AOF會將用戶操做的"命令" "實時" 記錄進appendonly.aof文件中。固然，若是aof文件信息膨脹到必定程度時，Redis會將AOF文件中的用戶命令進行 "總結優化"（從新讀取內存中的數據，每條數據會以set命令的形式從新寫進aof文件中）。

（appendonly.aof是優先於dump.rdb的）

下面進入正題

①、AOF以日誌的形式來記錄每一次的寫操做，將Redis執行過的全部寫指令記錄下來，秩序追加文件但不能夠改寫文件，Redis啓動之初會讀取appendonly.aof文件從新構建數據，換言之，redis重啓的話就會根據日誌文件的內容將寫指令從前到後的執行一次已完成數據的恢復工做。

②、appendonly.aof是優先於dump.rdb的，也就是說當Redis服務啓動的時候，若是dump.rdb和appendonly.aof同時存在的話，只要appendonly開啓，服務會優先讀取appendonly.aof文件的。只有在appendonly.aof文件不存在時，服務纔會讀取dump.rdb文件進行數據恢復。

 

③、bgrewriteaof

appendonly.aof確定會越寫越多，因此要精簡、要優化、要重寫文件。因而bgrewriteaof橫空出世。

當appendonly.aof文件持續增加而過大時，服務會fork出一條新的進程來將文件進行重寫（同rdb同樣也是先寫臨時文件，而後再替換原來的appendonly.aof）。這條新進程會遍歷當前內存中的數據，每條數據都會對應一條set語句寫進aof文件。

重寫aof的操做，並無讀取就得aof，而是將整內存中的數據庫內容用命令的方式重寫進一個新的aof文件中，相似快照。

那麼重寫的觸發機制有哪些？：

Redis會記錄上一次重寫時AOF文件的大小，默認配置是當AOF文件大小是上一次reWrite後大小的一杯，且文件小於64M時觸發。

對應的配置文件信息：

a、auto-aof-rewrite-percentage  100auto-aof-rewrite-min-size  64M

是上次文件的一倍，和大於64M時，觸發。

 

④、與AOF持久化相關的配置信息（redis.conf文件中）

a、appendonly  yes

是否開啓AOF，默認是NO不開啓

b、appendfilename"appendonly.aof"

對持久化文件的命名，即持久化的寫命令會追加到appendonly.aof文件中

c、appendfsync  everysec

AOF持久化的觸發條件配置，有三個

1>、Always：同步持久化，每次數據變動，命令都會被馬上記錄到磁盤文件中，性能較差，但數據的完整性一致性最好

2>、EverySec：這是默認的也是推薦的配置，異步操做，每秒記錄並寫進磁盤文件，可是若是服務宕機，就會丟失者一秒內的數據。

3>、No

d、no-appendfsync-on-write no

重寫是是否能夠運用appendfsync（即寫數據到持久化文件中）。用默認的No便可，保證數據的安全性。

⑤、優缺點：

優勢：默認每秒都會進行同步。數據的完整性和一致性比較高

缺點：應爲是記錄命令，因此相同數據集的數據而言AOF文件要遠大於rdb文件。Redis服務在恢復數據的速度上是要慢於RDB的。

 

 

 

三、總結

①、若是對數據存儲文件的大小，速度效率的快慢 要求比較高，但對數據的完整性和一致性要求不高時用RDB（雙十一時）

②、對數據的完整性要求比較高時用AOF

③、若是隻但願數據在服務器運行的時候存在，能夠不用任何持久化方式。

在配置文件裏  save "" 能夠禁用RDB功能，appendonly no 表示禁用AOF功能

④、同時開啓兩種持久化方式，在這種狀況下，當Redis重啓時候優先載入AOF文件來恢復原始數據。

由於在一般的狀況下AOF文件保存的數據集要比RDB文件保存的數據集要完整。

RDB的數據不實時，同時使用二者時服務器重啓也只會找AOF文件。那要不要只是用AOF呢？建議不要，由於RDB更適合用於備份數據庫（AOF在不斷變化很差備份，快速重啓，並且不會有AOF可能在的bug,留着做爲一個萬一的手段）