redis 實戰操做RDB和AOF快照持久化

前言：redis是咱們經常使用的緩存方式，今天就來介紹下兩種持久化的方式吧，先科普概念，再實戰操做

 

1、RDB

Redis將某一時刻的快照（備份的數據庫數據）保存成一種稱爲RDB格式的文件中，這種格式是通過壓縮的二進制文件。redis保存和恢復文件，如圖1和圖2所示。

保存RDB數據的命令：有兩種，一個是save，一個是bgsave，通常用的都是bgsave命令。
    
        一、save命令：save命令會阻塞redis服務器的進程，直到RDB文件建立完，在該期間，redis不能處理任何的命令請求，這就是save命令最大的缺陷。

        二、bgsave命令：與save命令不一樣的是，bgsave在生成RDB文件時，會派生出一個子進程，子進程負責建立RDB文件，在此期間，主進程和子進程是同時存在的，所以不會阻塞redis服務器進程。

說明：（可用lastsave命令查看生成RDB文件是否成功）

RDB快照持久化數據的優缺點：
　　　　一、優勢：
　　　　　　（1）、採用子線程建立RDB文件，不會對redis服務器性能形成大的影響；
　　　　　　（2）、快照生成的RDB文件是一種壓縮的二進制文件，能夠方便的在網絡中傳輸和保存。經過RDB文件，能夠方便的將redis數據恢復到某一歷史時刻，能夠提升數據安全性，避免宕機等意外對數據的影響。
　　　　　　（3）、適合大規模的數據恢復。
　　　　　　（4）、若是業務對數據完整性和一致性要求不高，RDB是很好的選擇。
　　　　
　　　　二、缺點：
　　　　　　（1）、在redis文件在時間點A生成，以後產生了新數據，還未到達另外一次生成RDB文件的條件，redis服務器崩潰了，那麼在時間點A以後的數據會丟失掉，數據一致性不是完美的好，
　　　　　　　　　　若是能夠接受這部分丟失的數據，能夠用生成RDB的方式；
　　　　　　（2）、快照持久化方法經過調用fork()方法建立子線程。當redis內存的數據量比較大時，建立子線程和生成RDB文件會佔用大量的系統資源和處理時間，對 redis處理正常的客戶端請求形成較大影響。
　　　　　　（3）、數據的完整性和一致性不高，由於RDB可能在最後一次備份時宕機了。
　　　　　　（4）、備份時佔用內存，由於Redis 在備份時會獨立建立一個子進程，將數據寫入到一個臨時文件（此時內存中的數據是原來的兩倍哦），最後再將臨時文件替換以前的備份文件。
　　　　　　　　　　因此Redis 的持久化和數據的恢復要選擇在夜深人靜的時候執行是比較合理的。

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

經過RDB文件恢復數據：
　　　　將dump.rdb 文件拷貝到redis的安裝目錄的bin目錄下，重啓redis服務便可。在實際開發中，通常會考慮到物理機硬盤損壞狀況，選擇備份dump.rdb 。

 

2、AOF

AOF是redis對將全部的寫命令保存到一個aof文件中，根據這些寫命令，實現數據的持久化和數據恢復。

AOF ：Redis 默認不開啓。它的出現是爲了彌補RDB的不足（數據的不一致性），因此它採用日誌的形式來記錄每一個寫操做，並追加到文件中。
　　　 Redis 重啓的會根據日誌文件的內容將寫指令從前到後執行一次以完成數據的恢復工做。

AOF文件生成機制：
        一、生成過程包括三個步驟：命令追加、文件寫入、文件同步。
　　　　　　 redis打開AOF持久化功能以後，redis在執行完一個寫命令後，把執行的命令首先追加到redis內部的aof_buf緩衝區膜末尾，此時緩衝區的記錄尚未寫到appendonly.aof文件中。
　　　　　　而後，緩衝區的寫命令會被寫入到 AOF 文件，這一過程是文件寫入過程。對於操做系統來講，調用write函數並不會馬上將數據寫入到硬盤，爲了將數據真正寫入硬盤，還須要調用fsync函數，
　　　　　　調用fsync函數便是文件同步的過程，只有通過了文件的同步過程，寫命令才真正的被保存到了AOF文件中。appendfsync 就是配置同步的頻率的選項。

AOF重寫：
        一、redis不斷的將寫命令保存到AOF文件中，致使AOF文件愈來愈大，當AOF文件體積過大時，數據恢復的時間也是很是長的，所以，redis提供了重寫或者說壓縮AOF文件的功能。
　　　　　　 好比對key1初始值是0，調用incr命,100次，key1的值變爲100，那麼其實直接一句set key1 100 就能夠頂以前的100局調用，AOF重寫功能就是幹這個事情的。
　　　　　　 重寫時，能夠調用BGREWRITEAOF命令重寫AOF文件，與新建子線程bgsave命令的工做原理類似。也能夠經過配置文件配置什麼條件下對AOF文件重寫。
　　　　　
　　　　 二、重寫的原理：Redis 會fork出一條新進程，讀取內存中的數據，並從新寫到一個臨時文件中。並無讀取舊文件（太大了）。最後替換舊的aof文件
　　　　
　　　　 三、重寫觸發機制：當AOF文件大小是上次rewrite後大小的一倍且文件大於64M時觸發。這裏的「一倍」和「64M」 能夠經過配置文件修改。

AOF優缺點：
　　優勢：
　　　　一、提供了多種同步命令的方式，默認1秒同步一次寫命令，作多會丟失1秒內的數據；
　　　　二、若是AOF文件有錯誤，好比在寫AOF文件時redis崩潰了，redis提供了多種恢復AOF文件的方式，
　　　　　　例如使用redis-check-aof工具修正AOF文件（通常都是最後一條寫命令有問題，能夠手動取出最後一條寫命令）；
　　　　三、AOF文件可讀性交強，也可手動操做寫命令。
　　　　四、數據的完整性和一致性更高
　　
　　缺點：
　　　　一、AOF文件比RDB文件較大；
　　　　二、redis負載較高時，RDB文件比AOF文件具備更好的性能；
　　　　三、RDB使用快照的方式持久化整個redis數據，而aof只是追加寫命令，所以從理論上來講，RDB比AOF方式更加健壯，另外，官方文檔也指出，在某些狀況下，AOF的確也存在一些bug，
　　　　　　好比使用阻塞命令時，這些bug的場景RDB是不存在的。
　　　　四、由於AOF記錄的內容多，文件會愈來愈大，數據恢復也會愈來愈慢。

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

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

以上簡單羅列了下兩種快照的基本信息，更多詳細信息能夠參考：https://www.jianshu.com/p/cbe1238f592a，下面開始實戰

 

3、實戰RDB操做

打開 redis.conf 文件，找到 SNAPSHOTTING 對應內容
　　（1）、RDB核心規則配置（重點）
　　　　　　save <seconds> <changes>

　　　　　　save 900 1 
　　　　　　save 300 10 
　　　　　　save 60 10000

　　　　　　說明：save <指定時間間隔> <執行指定次數更新操做>，知足條件就將內存中的數據同步到硬盤中。官方出廠配置默認是 900秒內有1個更改，300秒內有10個更改以及60秒內有10000個更改，
　　　　　　　　　則將內存中的數據快照寫入磁盤。若不想用RDB方案，能夠把 save "" 的註釋打開，下面三個註釋。

　　（2）、指定本地數據庫文件名，通常採用默認的 dump.rdb
　　　　　　　配置：dbfilename dump.rdb

　　（3）、指定本地數據庫存放目錄，通常也用默認配置
　　　　　　　配置：dir ./

　　（4）、默認開啓數據壓縮
　　　　　　　配置：rdbcompression yes
　　　　　　　說明：配置存儲至本地數據庫時是否壓縮數據，默認爲yes。Redis採用LZF壓縮方式，但佔用了一點CPU的時間。若關閉該選項，但會致使數據庫文件變的巨大。建議開啓。

　　一、配置save：設置了120S，修改3次，則持久化一次（shutdown和FLUSHALL也有生成快照的功能）

 

　　二、開始測試

　　　　

　　三、經過RDB文件恢復數據　

流程：
        一、先備份一份dump.rdb爲dump_bak.rdb（模擬線上）
        二、flushall清空數據（模擬數據丟失........注意flushall也會觸發rbd持久化）
        三、將dump_bak.rdb替換爲dump.rdb
        四、重啓redis服務，恢復數據

　　

 

4、實戰AOF操做 

打開 redis.conf 文件，找到 APPEND ONLY MODE 對應內容
　　　　一、redis 默認關閉，開啓須要手動把no改成yes
　　　　　　配置：appendonly yes

　　　　二、指定本地數據庫文件名，默認值爲 appendonly.aof
　　　　　　配置：appendfilename "appendonly.aof"

　　　　三、指定更新日誌條件
　　　　　　配置：# appendfsync always 
　　　　　　　　　　appendfsync everysec 
　　　　　　　　　# appendfsync no

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

　　　　四、配置重寫觸發機制
　　　　　　配置：auto-aof-rewrite-percentage 100
　　　　　　　　　auto-aof-rewrite-min-size 64mb

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

　　

　　一、修改配置appendonly爲yes（須要重啓redis）

　　

　　二、開始測試

　　

　　三、經過AOF文件恢復數據

流程：   
        一、執行flushall，模擬數據丟失
        二、重啓redis服務，恢復數據
        三、修改appendonly.aof，模擬文件異常
        四、重啓 Redis 服務失敗。這同時也說明了，RDB和AOF能夠同時存在，且優先加載AOF文件。
        五、使用redis-check-aof 校驗appendonly.aof 文件。重啓Redis 服務後正常。

　　　注意：當你使用flushall清空數據的時候，重啓redis服務發現數據沒恢復，是由於FLUSHALL 命令也被寫入AOF文件中，致使數據恢復失敗。
　　　　　　只須要刪除aof文件中的flushall就好了

　　

　　

　　

 　　

5、總結

一、Redis 默認開啓RDB持久化方式，在指定的時間間隔內，執行指定次數的寫操做，則將內存中的數據寫入到磁盤中。

二、RDB 持久化適合大規模的數據恢復但它的數據一致性和完整性較差。

三、Redis 須要手動開啓AOF持久化方式，默認是每秒將寫操做日誌追加到AOF文件中。

四、AOF 的數據完整性比RDB高，但記錄內容多了，會影響數據恢復的效率。

五、Redis 針對 AOF文件大的問題，提供重寫的瘦身機制。

六、若只打算用Redis 作緩存，能夠關閉持久化。（RDB關閉：註釋掉全部save，AOF關閉：appendonly爲no）

七、若打算使用Redis 的持久化。建議RDB和AOF都開啓。其實RDB更適合作數據的備份，留一後手。AOF出問題了，還有RDB。

 

以上就是文章的所有內容了，實戰部分爲本人親測。

概念參考連接：http://www.javashuo.com/article/p-kbfkhfzd-mh.html