Redis 持久化

咱們知道，redis是基於內存的，也就是說數據在內存中，這也是爲何redis這麼快的緣由之一。可是當redis重啓了，內存中的數據就會丟失。因此，redis就有持久化的機制。它提供兩種方式的持久化：

1. RDB
2. AOF

前者根據指定的規則‘定時’將內存中的數據存儲在硬盤中。後者在每次執行寫命令後將命令自己記錄下來。

RDB方式

當符合必定的條件的時候，redis會自動將內存中的全部數據生成一個副本並存儲在硬盤上。這個過程被稱爲‘快照’。

根據配置規則進行自動快照

在配置文件redis.conf中, 配置save以下例：

save 900 1
save 300 10
save 60 10000

意思是：900s內，至少有一個key被更改則進行異步快照；300s內至少有10個key被更改；60s內至少有10000個key。

執行SAVE或者BGSAVE命令

SAVE命令，使redis同步進行快照，會阻塞來自客戶端的請求。不推薦

BGSAVE命令，在後臺異步進行快照，能夠相應客戶端請求。執行BGSAVE會馬上返回ok,表示開始執行快照操做，若是想要知道快照是否完成，經過LASTSAVE命令,獲取最近一次成功執行快照的時間，返回unix時間戳。

快照過程

redis默認會將快照文件存儲在redis工做目錄的dump.rdb文件中。過程以下：

1. redis使用fork函數複製一份當前進程的子進程；
2. 父進程繼續處理客戶端發來的請求，子進程開始將內存中的數據寫入硬盤中的臨時文件
3. 當子進程寫入完全部的數據後會用該臨時文件替換舊的rdb文件，本次快照完成。

注意： 當fork函數發生的一刻，父子進程共享同一內存數據，當父進程要更改其中某片數據時，操做系統會將該片數據複製一份，以保持子進程的數據不受影響，因此新的rdb文件存儲的是fork一刻的內存數據。

rdb文件是通過壓縮的二進制格式。

以上，能夠看到這種方式的持久化明顯存在缺陷。當redis異常退出，就會丟失最後一次快照之後的更改。若是數據相對重要，就要使用AOF方式了。

AOF方式

這種方式將全部的寫命令追加到硬盤文件中，這個過程會下降redis的性能，可是大部分狀況下這個影響是能夠接受的，另外使用較快的硬盤能夠提升AOF的性能。

默認狀況redis是沒有開啓AOF的，能夠經過appendonly參數啓用：

appendonly yes

aof文件和rdb文件的位置相同，默認文件名是appendonly.aof,能夠經過appendfilename參數修改：

appendfilename XXX.aof

AOF文件的重寫

好比咱們有兩條寫命令：

set foo 1
set foo 2
set foo 3

明顯，前面兩條都是沒用的。這時候咱們但願優化aof文件。

能夠在配置文件redis.conf裏面配置：

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

auto-aof-rewrite-percentage意思是當目前的aof文件大小超過上次重寫時的aof文件大小的百分之多少時，會再次自動重寫，若是以前沒有重寫過，則以啓動時的aof文件大小爲依據。

aotu-aof-rewrite-min-size限制了容許自動重寫的最小aof文件大小，一般在aof文件過小的時候咱們並不關心。

此外還能夠手動重寫：

BGREWRITEAOF

重寫的過程只和內存中的數據有關，和舊的aof文件無關。