redis數據持久化

1、概念
一）redis提供了不一樣級別的持久化方式：

1. RDB持久化方式可以在指定的時間間隔能對你的數據進行快照存儲。
2. AOF持久化方式記錄每次對服務器寫的操做，當服務器重啓的時候會從新執行這些命令來恢復原始的數據，AOF命令以redis協議追加保存每次寫的操做到文件末尾，redis還能對AOF文件進行後臺重寫，使得AOF文件的體積不至於過大。
3. 若是你只但願你的數據在服務器運行的時候存在，你也能夠不適用任何持久化方式。
4. 也能夠同時開啓兩種持久化方式，在這種狀況下，當redis重啓的時候會有限載入AOF文件來恢復原始的數據，由於在一般狀況下AOF文件保存的數據集比RDB文件保存的數據集要完整

二）RDB的優缺點
優勢：

1. RDB是一個很是緊湊的文件，它保存了某個時間點的數據集，很是適用於數據集的備份，這樣即便出了問題你也能夠根據需求恢復到不一樣版本的數據集。
2. RDB是一個緊湊的單一文件，很方便傳送到另外一個遠端數據中心或者亞馬遜的S3（可能加密），很是適用於災難恢復。
3. RDB在保存RDB文件時父進程惟一須要作的就是fork出一個子進程，接下來的工做所有由子進程來作，父進程不須要再作其餘IO操做，因此RDB持久化方式能夠最大化redis的性能。
4. 與AOF相比，在恢復大的數據集的時候，RDB方式會更快一些。

缺點：

1. 若是但願在redis意外中止工做的狀況下丟失的數據最少的話，那麼RDB不適合
2. RDB須要常常fork子進程來保存數據集到硬盤上，當數據集比較大的時候，fork的過程是很是耗時的，可能會致使redis在一些毫秒級內不能相應客戶端的請求。

三）AOF的優缺點
優勢：

1. 使用AOF會讓你的redis更加耐久
2. AOF文件是一個只進行追加的日誌文件，因此不須要寫入seek，即便因爲某些緣由（磁盤空間已滿，寫的過程當中宕機等）未執行完整的寫入命令，你也可以使用redis-check-aof工具修復這些問題。
3. redis能夠在aof文件體積變得過大時，自動的在後臺對aof進行重寫。
4. aof文件有序地保存了對數據庫執行的全部寫入操做，這些寫入操做以redis協議的格式保存，所以aof文件的內容很是容易被人讀懂，對文件進行分析（parse）也很輕鬆。

缺點：

1. 對於相同的數據集來講，aof文件的體積一般要大於rdb文件的體積。
2. 根據所使用的fsync策略，aof的速度可能會慢於rdb

四）如何選擇使用哪一種持久化方式：

1. 通常來講，若是想達到足以媲美PostgreSQL的數據安全性，你應該同時使用兩種持久化功能。
2. 若是很是關心你的數據，但仍然能夠承受數分鐘之內的數據丟失，那麼你能夠只使用RDB持久化。
3. 不推薦只是用AOF持久化，由於定時生成RDB快照（snapshot）很是便於進行數據庫備份，而且RDB恢復數據集的速度也要比AOF恢復的速度要快。

五）更多RDB細節：

1. 在默認狀況下，redis將數據庫快照保存在名字爲dump.rdb的二進制文件中。
2. 這種持久化方式被稱爲快照snapshotting
3. 當redis須要保存dump.rdb文件時，服務器執行如下操做：

• • redis調用forks，同時擁有父進程和子進程。
  • 子進程將數據集寫入到一個臨時RDB文件中。
  • 當子進程完成對新RDB文件的寫入是，redis用新RDB文件替換原來的RDB文件，並刪除舊的RDB文件

2、redis數據持久化相關配置以及命令
一）RDB的配置：
一、在配置文件中已經預設三個條件

• save 900 1 #15分鐘內至少有一個鍵被更改
• save 300 10 #5分鐘內至少有10個鍵被更改
• save 60 10000 #1分鐘內至少有10000個鍵被更改

二、默認的rdb文件路徑是當前目錄，文件名是：dump.rdb，能夠在配置文件中修改路徑和文件名，分別是dir和dbfilename

• dir ./ #rdb文件存儲路徑
• dbfilename dump.rdb #rdb文件名

三、RDB文件的壓縮：

• RDB文件是經過壓縮的，能夠經過配置rdbcompression參數來禁用壓縮，redis默認是開啓壓縮的。

四、RDB相關命令：

• 若是沒有觸發自動快照，須要對redis執行手動快照操做，save和bgsave都是執行手動快照，可是二者有區別：能夠經過save和bgsave命令來手動快照，兩個命令的區別是前者是由主進程進行快照，會阻塞其餘請求，後者是經過fork子進程進行快照。

二）AOF（Append-Only File）
一、快照功能並非很是耐久（dura ble）：若是redis由於某些緣由而形成故障停機，那麼服務器將丟失最近寫入、且仍未保存到快照中的那些數據。從1.1版本開始，redis增長了一種徹底耐久的持久化方式：AOF持久化。
二、能夠在配置文件中打開AOF方式：

• appendonly yes

三、從如今開始，每當redis執行一個改變數據集的命令時（好比set），這個命令就會被追加到AOF文件的末尾。

四、AOF工做原理：
1）redis執行fork(),如今同時擁有父進程和子進程
2）子進程開始將新AOF文件的內容寫入到臨時文件
3）對於全部新執行的寫入命令，父進程一邊將他們累積到一個內存緩存中，一邊將這些改動追加到現有AOF文件的末尾，這樣即便在重寫的中途發生停機，現有的AOF文件也仍是安全的
4）當子進程完成重寫工做時，它給父進程發送一個信號，父進程在接收到信號以後，將內存緩存中的全部數據追加到新AOF文件的末尾

五、日誌重寫
1）AOF文件的體積會變得愈來愈大
2）重建（rebuild）
3）bgrewriteaof命令
4）自動觸發AOF重寫

六、AOF相關配置
1）AOF文件的位置和RDB的位置相同，都是經過dir參數設置，默認的文件名是appendonly.aof,能夠經過appendfilename參數修改
2）重寫策略的參數設置

• auto-aof-rewrite-percentage 100
• 當前的AOF文件大小超過上一次重寫的AOF文件大小的百分之多少時會再次進行重寫，若是以前沒有重寫過，則以啓動時的AOF大小爲依據
• auto-aof-rewrite-min-size 64mb
• 限制了容許重寫的最小AOF文件

3）文件同步策略

• 文件寫入默認狀況下會先寫入到系統的緩存中，系統每一個30秒同步一次，纔是真正的寫入到磁盤，若是在這30秒服務器宕機那數據也會丟失
• appendfsync always每次都同步（最安全可是最慢）
• appendfsync everysec每秒同步（默認的同步策略）
• appendfsync no 不主動同步，由操做系統來決定（最快可是不安全）

七、優化AOF文件：

• 可使用BGREWRITEAOF命令來重寫AOF文件。目的是去除數據的中間執行過程，保存最終數據命令便可。

八、AOF文件損壞
1）爲現有的AOF文件建立一個備份
2）使用redis-check-aof修復

• redis-check-aof --fix
• （可選）使用diff -u對比修復後的AOF文件和原始AOF文件的額備份，查看兩個文件之間的不一樣之處。
• 重啓redis服務器，等待服務器載入修復後的AOF文件，並進行數據恢復。

九、怎樣從RDB方式切換爲AOF方式：
1）爲最新的dump.rdb文件建立一個備份
2）將備份放到一個安全的地方
3）執行如下兩條命令

• redis-cli config set appendonly yes
• redis-cli config set save ""

4）確保寫命令會被正確的追加到AOF文件的末尾

3、redis數據備份
一）數據備份
一、確保你的數據由完整的備份（磁盤故障，節點失效，諸如此類的問題均可能使數據丟失，不進行備份是很是危險的）
二、不管什麼時候，賦值RDB文件都是絕對安全的。

二）備份步驟
1）建立一個按期任務，每小時將一個RDB文件備份到一個文件夾，而且天天將一個RDB文件備份到另外一個文件夾。
2）確保快照的備份都帶有相應的日期和時間信息，每次執行按期任務腳本是，使用find命令來刪除過時的快照：好比說，能夠保留最近48小時內的每小時快照，還能夠保留最近一兩個月的每日快照。
3）至少天天一次，將RDB備份到你的數據中心以外，或者至少是備份到你運行redis服務器的屋裏機器以外

三）容災備份：
1）對數據進行備份，並將這些備份傳送到多個不一樣的外部數據中心。
2）容災備份能夠在redis運行併產生快照的主數據中心發生嚴重的問題是，仍然讓數據處於安全狀態。

四）容災備份方法：1）Amazon S32）傳送快照可使用SCP來完成（ssh的組件）3）在文件傳送完畢以後，檢查所傳送備份文件的體積和原始文件的體積是否相同。