技術人都要了解的redis持久化～

redis做爲典型的nosql數據庫，其擁有兩種持久化的方案，分別是RDB （Redis DataBase）和 AOF （Append Only File）接下來就簡單的介紹一下兩種方式的優缺點，以及相關的配置操做等。

1、RDB詳解

rdb是redis默認的持久化的方案，是以快照的方式，將內存中的數據不斷寫入磁盤。詳細描述過程是：在指定的時間間隔內，執行指定次數的寫操做，則會將內存中的數據寫入到磁盤當中，同時在指定的相關目錄下生成dump.rbd文件，而後redis重啓的時候，會加載該文件，恢復數據

1.一、從配置文件看rbd相關的配置

咱們打開redis.conf文件，能夠找到SNAPSHOTTING 快照這部分對應的內容

1.1.一、RDB核心的配置規則

#save <seconds> <changes>
#   save ""
save 900 1
save 300 10
save 60 10000

解讀：其中save <seconds> <changes>這一行第一個參數是seconds 表示的時間間隔，第二個參數表示是執行指定次數更新操做，
redis的默認配置時間有三個：分別是900秒內1個更改，300秒內10個更改，60秒內10000個更改，則將內存中的數據快照寫入磁盤。

若是不想用RDB的方案，能夠將save ""去掉註釋，官方默認的的加上註釋。

1.1.二、指定本地數據庫文件名，官方默認的是：

dbfilename dump.rdb

1.1.三、指定本地數據庫存放的目錄，官方默認的是：

dir ./

1.1.四、默認開啓數據壓縮

# Compress string objects using LZF when dump .rdb databases?
# For default that's set to 'yes' as it's almost always a win.
# If you want to save some CPU in the saving child set it to 'no' but
# the dataset will likely be bigger if you have compressible values or keys.

rdbcompression yes

解答：配置存儲.rdb數據庫的時候，是否壓縮數據。默認爲yes。redis的rbd會採用lzf的壓縮方式，可是會佔用cpu的，若是關閉的話，當前數據庫文件會邊的巨大。

1.2 觸發RBD快照

• 1 在指定的時間間隔內，執行指定次數的寫操做
• 2 執行save（阻塞， 只管保存快照，其餘的等待） 或者是bgsave （異步）命令
• 3 執行flushall 命令，清空數據庫全部數據，意義不大。
• 4 執行shutdown 命令，保證服務器正常關閉且不丟失任何數據，意義...也不大。

1.3 經過RDB文件恢復數據

將dump.rdb 文件拷貝到redis的安裝目錄的bin目錄下，重啓redis服務便可。在實際開發中，通常會考慮到物理機硬盤損壞狀況，選擇備份dump.rdb 。能夠從下面的操做演示中能夠體會到。

1.4 RDB的優缺點

1.4.1 優勢

• 1 適合大規模的數據恢復。
• 2 若是業務對數據完整性和一致性要求不高，RDB是很好的選擇。

1.4.2 缺點：

• 1 數據的完整性和一致性不高，由於RDB可能在最後一次備份時宕機了。
• 2 備份時佔用內存，由於Redis 在備份時會獨立建立一個子進程，將數據寫入到一個臨時文件（此時內存中的數據是原來的兩倍哦），最後再將臨時文件替換以前的備份文件。

因此Redis 的持久化和數據的恢復要選擇在夜深人靜的時候執行是比較合理的。

2、AOF詳解

AOF:redis默認不開啓，它是爲了彌補RDB的數據不一致性，採用了日誌的形式記錄每個寫操做，而且追加到文件中。當redis重啓會根據日誌的內容將寫的指令從前到後按照順序執行一次，從而完成數據的恢復工做。

2.1 從配置文件瞭解AOF

打開 redis.conf 文件，找到 APPEND ONLY MODE 對應內容

2.1.1 redis 默認關閉，開啓須要手動把no改成yes

appendonly yes

2.1.2 指定本地數據庫文件名，默認值爲 appendonly.aof

appendfilename "appendonly.aof"

2.1.3 指定更新日誌條件

# appendfsync always
appendfsync everysec
# appendfsync no

解說：

• always：同步持久化，每次發生數據變化會馬上寫入到磁盤中。性能較差當數據完整性比較好（慢，安全）
• everysec：出廠默認推薦，每秒異步記錄一次（默認值）
• no：不一樣步

2.1.4 配置重寫觸發機制

auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

解說：當AOF文件大小是上次rewrite後大小的一倍且文件大於64M時觸發。通常都設置爲3G，64M過小了。

2.2 觸發AOF快照

根據配置文件觸發，能夠是每次執行觸發，能夠是每秒觸發，能夠不一樣步。

2.3 根據AOF文件恢復數據

正常狀況下，將appendonly.aof 文件拷貝到redis的安裝目錄的bin目錄下，重啓redis服務便可。但在實際開發中，可能由於某些緣由致使appendonly.aof 文件格式異常，從而致使數據還原失敗，能夠經過命令redis-check-aof --fix appendonly.aof 進行修復 。從下面的操做演示中體會。

2.4 AOF的重寫機制

前面也說到了，AOF的工做原理是將寫操做追加到文件中，文件的冗餘內容會愈來愈多。因此聰明的 Redis 新增了重寫機制。當AOF文件的大小超過所設定的閾值時，Redis就會對AOF文件的內容壓縮。

重寫的原理：Redis 會fork出一條新進程，讀取內存中的數據，並從新寫到一個臨時文件中。並無讀取舊文件。最後替換舊的aof文件。

觸發機制：當AOF文件大小是上次rewrite後大小的一倍且文件大於64M時觸發。這裏的「一倍」和「64M」 能夠經過配置文件修改。

2.5 AOF 的優缺點

優勢：數據的完整性和一致性更高
缺點：由於AOF記錄的內容多，文件會愈來愈大，數據恢復也會愈來愈慢。

==多說一句==

• 問: 若是rdb文件,和aof文件都存在,優先用誰來恢復數據?
  答: aof
• 恢復時rdb和aof哪一個恢復的快
  答: rdb快,由於其是數據的內存映射,直接載入到內存,而aof是命令,須要逐條執行

更多精彩內容，歡迎你們關注個人微信公衆號：喝醉的清茶