redis持久化（RDB、AOF）

redis是記憶體資料庫，但是不僅限于記憶體，redis有其持久化的方式；

共有三種持久化的方式；

方式1：生成dump.rdb檔案

方式2：生成appendonly.aof檔案

方式3：master/slave（主從複制讀寫分離）

RDB：（redis database）

簡介：   

   通俗來說，rdb是在指定的時間間隔内将記憶體中的資料集快照寫入磁盤，即snapshot快照，想要恢複時，将快照檔案（dump.rdb檔案）直接讀取，即可恢複到記憶體中；

    redis會單獨fork一個子程序來進行持久化，先将資料寫入一個臨時檔案，等持久化結束了（即該臨時檔案寫好了），将該臨時檔案替換上一次持久化生成的rdb檔案；整個過程中，主程序不進行任何的IO操作；

      rdb有一個缺點：最後一次持久化的資料可能丢失；因為按照時間段進行快照；

細節：

Rdb：預設狀态

Save 900 1      300秒内未達到10次，在900秒内達到1次，備份

Save 300 10    60秒内未達到10000次，在300秒内達到10次，備份

Save 60 10000   60秒内達到10000次，備份（這個備份不是立刻的，即使在50秒達到了10000次，也需要等到60秒才會生成dump.rdb檔案）

用save，bgsave指令可以直接備份，不需要等待上述條件；

save：隻管儲存，其他不管，全部阻塞；（即在寫入dump檔案的時候，redis占用的記憶體中不能執行寫入操作）

bgsave：redis會在背景異步進行快操作，快照的同時還可以響應用戶端請求，可以通過lastsave指令擷取最後一次成功執行快照的時間；

陷阱：

1. flushall指令：消除全部的記憶體中的redis資料，并即刻産生一個dump.rdb檔案，但由于清空了，是以該檔案記錄的是空；

2. shutdown指令： 通過redis-cli SHUTDOWN停掉redis，是一種安全退出的模式，redis在退出的時候會将記憶體中的資料立即生成一份完整的rdb快照。

3. 在redis中再儲存幾條新的資料，用kill -9 粗暴殺死redis程序，模拟redis故障異常退出，導緻記憶體資料丢失的場景；

這次就發現，redis程序異常被殺掉，資料沒有進dump檔案，幾條最新的資料丢失了；

4. 機器突然挂掉，可能會使得最近幾分鐘的資料無法恢複；

5. 一般生成dump.rdb檔案後會再次将該檔案備份到其他機器上面，恢複時，将dump.rdb檔案複制到redis目錄下，啟動即可

知識點：判斷redis啟動的方式

方法一：ps -ef|grep redis

方法二：lsof -i :6379

知識點：啟動redis的方式(先後啟動以下兩條指令)

redis-server /myredis/redis.conf

redis-cli -p 6379

知識點：在Linux中看磁盤空間和記憶體空間的指令

df –h 看磁盤空間

 free  看記憶體空間

---------------------------------------------------------------------------------------------------------------------------------------------

以下是從部落格中摘的一段更為細節一點的解釋：https://blog.csdn.net/why15732625998/article/details/80565044

2.1 配置RDB持久化機制

在redis.conf檔案，也就是我們這裡的

/etc/redis_6379/6379.conf

去配置RDB持久化

save 60 1000
           

每隔60s，如果有超過1000個key發生了變更，那麼就生成一個新的dump.rdb檔案，就是目前redis記憶體中完整的資料快照，這個操作也被稱之為snapshotting,快照也可以手動調用save或者bgsave指令，同步或異步執行rdb快照生成。

save可以設定多個，就是多個snapshotting檢查點，每到一個檢查點，就會去check一下，是否有指定的key數量發生了變更，如果有，就生成一個新的dump.rdb檔案。如下配置：

save 900 1
save 300 10
save 60 10000
           

2.2 基于RDB持久化機制的資料恢複實驗

1.在redis中儲存幾條資料，立即停掉redis程序，然後重新開機redis，看看剛才插入的資料還在不在,為什麼?

通過redis-cli SHUTDOWN這種方式去停掉redis，其實是一種安全退出的模式，redis在退出的時候會将記憶體中的資料立即生成一份完整的rdb快照。

2.在redis中再儲存幾條新的資料，用kill -9 粗暴殺死redis程序，模拟redis故障異常退出，導緻記憶體資料丢失的場景

這次就發現，redis程序異常被殺掉，資料沒有進dump檔案，幾條最新的資料丢失了

3.手動設定一個save檢查點， save 5 1

如果啟動報pid已經存在，則先删除

/var/run/redis_6379.pid

rm -rf redis_6379.pid
           

寫入幾條資料，等待5秒鐘

停掉redis程序，再重新啟動redis，看剛才插入的資料還在不在，這時我們發現資料可以順利恢複。

---------------------------------------------------------------------------------------------------------------------------------------------------------------------

AOF：

簡介：

aof用檔案追加方式，是通過對日志記錄的方式實作持久化，記錄所有的寫操作，生成appendonly.aof檔案，恢複時隻需在啟動時讀取該檔案即可；

redis.conf檔案中，預設為appendonly no，改成yes，啟動aof機制；

細節：

1. 如果兩種恢複（備份）政策，同時存在，那聽誰的？

先找appendonly.aof檔案（忽略dump.rdb）

2. 若aof檔案損壞，可以通過如下指令修複aof

redis-check-aof --fix appendonly.aof

rdb檔案恢複則是，redis-check-dump

3. appendsync：預設設定為everysec，持久化的參數設定，異步操作，每秒記錄，如果一秒内當機，有資料丢失；

該參數還有 always和No。分别表示同步持久化（性能差）和不持久化；

4. rewrite：aof檔案的瘦身機制，壓縮那個優化aof檔案

5. no-appendfsync-no-rewrite：重寫時運用appendsync，no-appendfsync-no-rewrite用預設的no即可，保證重寫時資料安全性；

如何選擇：

1.快速恢複和備份，對資料敏感性，完整性，要求不高--------單獨使用rdb即可；

2.建議同時使用aof和rdb

3.建議不要單獨使用aof

master/slave：

主從複制是為了

1.讀寫分離，減小io壓力

2.備份

該模式常用，持久化方案基礎還是rdb和aof，但是有其特殊的政策；

本章節暫不介紹...