持久化功能

redis為了內部資料的安全考慮，會把本身的資料以檔案形式儲存到硬碟中一份，在伺服器

重啟之後會把硬碟中的資料恢復到記憶體(redis)的裡邊。資料儲存到硬碟的過程就稱為“持久化”效果

redis有兩種持久化功能，一種是“快照持久化”,一種是“AOF持久化”

1.snap shotting快照持久化

該持久化預設開啟，一次性把redis中全部的資料儲存一份儲存在硬碟中，如果資料非常多

(10-20G)就不合適頻繁操作該持久化操作

我們的快照持久化在硬碟中保留的備份在:

預設的檔名為：dump.rdb

在我們的redis安裝目錄下有一個redis.conf配置檔案，其中就有快照持久化的配置:

上圖配置的就是快照持久化的“備份頻率”。

以上的配置三個都不能缺少，這樣能保證不管修改資料頻率高還是低的情況，資料都會儲存。

其中快照持久化的檔案的名稱和儲存位置在配置檔案中也有配置:

手動發起快照持久化:
我們首先在Redis中加入一些資料:

我們添加了好多testN的資料，為了持久化這些變化，我們手動發起快照持久化:

./redis-cli bgsave    

redis的持久化相關指令:
bgsave 非同步儲存資料到磁碟(快照儲存)
lastsave 返回上次成功儲存到磁碟的unix時間戳
shutdown 同步儲存到伺服器並關閉redis伺服器

bgrewriteaof 當日志文件過長時優化AOF日誌檔案儲存

快照持久化缺點:
一下是一次快照的模擬：

每隔一個小時做一次快照持久化

可以看到，我們在10:00-11:00的時候斷電了，按照我們每一個小時做的快照持久化來看，
11:00才執行的快照，就無法挽回10:00-10:55分的資料。
解決方案:
每隔一個小時做一次快照持久化

在每一個小時內，我們做“精細持久化”，也就是每修改一個key就儲存起來，
並且頻率可以達到秒級。不管你1秒內修改了多少key，只做一次持久化，這樣
也比較節省記憶體。

上面所說的“精細持久化”也就是Redis的第二種持久化方法---append only file(AOF持久化)。

2.append only file(AOF持久化)
回想一下，mysql資料庫的備份也就是備份了一些sql語句，還原的時候執行sql語句就就行了。

我們在redis.conf配置檔案中可以找到它:

將“no”改為“yes”，就開啟了快照持久化。
我們也可以更改AOP持久化檔名稱(檔案位置與dump.rdb同一目錄)。

配置檔案被修改後，要刪除舊的程序，再根據新的配置檔案啟動新程序:

然後就可以在同級目錄下，發現一個AOF持久化備份檔案appendpnly.aof

然後就發現所有的資料全部清空了(預設)

資料庫0-15資料庫都是空的。

我們在資料庫0中建立了三個key

然後回到根目錄看一下備份檔案，發現時間和大小都有所改變:

然後檢視一下內容：

發現我們寫的指令全部都備份進去了，說明備份頻率還是十分高的。

在redis.conf中，可以調整AOF備份的頻率:

有三種備份方式：
(1)always
一寫指令就備份一次。這樣做雖然安全，但是系統性能會降低。不推薦使用

(2)everysec
每一秒中備份一次。不管一秒鐘變化了多少key，只備份一次，效能得到一定的保護。推薦使用。

(3)no
會檢視當前伺服器狀態，如果狀態良好，就進行備份(隨機)。這種備份方式資料是沒有保證的。

對比下來，效能:always<everysec<no，而資料安全:always>everysec>no。

我們做一個例子，建立一個num資料，使用incr指令對其每過一秒自增一次:

我們檢視我們的appendonly.aof檔案，看看備份情況:

其實自增10次(10個incr num)就相當於一個set num 10，如果只儲存“set num 10”，那麼
備份檔案的儲存空間就會節省了一些。這就牽扯到了我們如何“為aof備份檔案做優化處理”。

3.為AOF備份檔案做優化處理
所謂優化，其實就是把AOF備份檔案中所有的備份資料的內容進行一個處理。

在啟動redis客戶端的時候，使用bgrewriteaof指令，就可以對aof備份檔案的內容進行

優化壓縮處理。

我們可以發現aof的大小由位元組變為位元組，證明其內容被壓縮了

看一下其中的內容，發現備份資料儲存指令變了:

總結:
快照持久化和AOF持久化是一種互補的關係，快照持久化用來做大的備份，
而AOF持久化用來做做精細備份。
資料還原的時候，快照持久化和AOF持久化可以一起來還原。
還原的時候也十分簡單，在任何一臺伺服器上，只要拿到備份檔案，都可以進行資料備份