【Redis快取機制】9.快照持久化和AOF持久化
阿新 • • 發佈：2019-02-20
持久化功能
redis為了內部資料的安全考慮，會把本身的資料以檔案形式儲存到硬碟中一份，在伺服器
重啟之後會把硬碟中的資料恢復到記憶體(redis)的裡邊。
資料儲存到硬碟的過程就稱為“持久化”效果。
redis有兩種持久化功能，一種是“快照持久化”,一種是“AOF持久化”。
1.snap shotting快照持久化
該持久化預設開啟，一次性把redis中全部的資料儲存一份儲存在硬碟中，如果資料非常多
(10-20G)就不合適頻繁操作該持久化操作。
我們的快照持久化在硬碟中保留的備份在:
預設的檔名為dump.rdb
在我們的redis安裝目錄下有一個redis.conf配置檔案，其中就有快照持久化的配置:
上圖配置的就是快照持久化的“備份頻率”。
以上三個save的意思：
資料修改的頻率非常高，備份的頻率也高
資料修改的頻率低，備份的頻率也低
以上的配置三個都不能缺少，這樣能保證不管修改資料頻率高還是低的情況，資料都會儲存。
其中快照持久化的檔案的名稱和儲存位置在配置檔案中也有配置:
手動發起快照持久化:
我們首先在Redis中加入一些資料:
我們添加了好多testN的資料，為了持久化這些變化，我們手動發起快照持久化:
可以看到，原來備份檔案時間未11月12日，現在變為了程式修改的20日了:
我們看一看我們的快取檔案中都儲存了什麼:
我們之前的改動都有記錄在備份檔案中。
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語句就就行了。
其實AOF持久化就是類似的操作。
AOF持久化本質:把使用者執行的每個“寫”指令(新增/修改/刪除)都備份到檔案中，還原資料的時候
就是執行具體寫指令而已。
開啟AOF持久化(會清空redis內部的資料，最好在redis使用之前就開啟它)
我們在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的大小由位元組變為位元組，證明其內容被壓縮了
看一下其中的內容，發現備份資料儲存指令變了:
果然，10次的incr num變成了一次的set num 10
總結:
快照持久化和AOF持久化是一種互補的關係，快照持久化用來做大的備份，
而AOF持久化用來做做精細備份。
資料還原的時候，快照持久化和AOF持久化可以一起來還原。
還原的時候也十分簡單，在任何一臺伺服器上，只要拿到備份檔案，都可以進行資料備份。
至此，兩種持久化方式介紹完畢。
redis為了內部資料的安全考慮，會把本身的資料以檔案形式儲存到硬碟中一份，在伺服器
重啟之後會把硬碟中的資料恢復到記憶體(redis)的裡邊。
資料儲存到硬碟的過程就稱為“持久化”效果。
redis有兩種持久化功能，一種是“快照持久化”,一種是“AOF持久化”。
1.snap shotting快照持久化
該持久化預設開啟，一次性把redis中全部的資料儲存一份儲存在硬碟中，如果資料非常多
(10-20G)就不合適頻繁操作該持久化操作。
我們的快照持久化在硬碟中保留的備份在:
預設的檔名為dump.rdb
在我們的redis安裝目錄下有一個redis.conf配置檔案，其中就有快照持久化的配置:
上圖配置的就是快照持久化的“備份頻率”。
以上三個save的意思：
資料修改的頻率非常高，備份的頻率也高
資料修改的頻率低，備份的頻率也低
以上的配置三個都不能缺少，這樣能保證不管修改資料頻率高還是低的情況，資料都會儲存。
其中快照持久化的檔案的名稱和儲存位置在配置檔案中也有配置:
手動發起快照持久化:
我們首先在Redis中加入一些資料:
我們添加了好多testN的資料，為了持久化這些變化，我們手動發起快照持久化:
可以看到，原來備份檔案時間未11月12日，現在變為了程式修改的20日了:
我們看一看我們的快取檔案中都儲存了什麼:
我們之前的改動都有記錄在備份檔案中。
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語句就就行了。
其實AOF持久化就是類似的操作。
AOF持久化本質:把使用者執行的每個“寫”指令(新增/修改/刪除)都備份到檔案中，還原資料的時候
就是執行具體寫指令而已。
開啟AOF持久化(會清空redis內部的資料，最好在redis使用之前就開啟它)
我們在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的大小由位元組變為位元組，證明其內容被壓縮了
看一下其中的內容，發現備份資料儲存指令變了:
果然，10次的incr num變成了一次的set num 10
總結:
快照持久化和AOF持久化是一種互補的關係，快照持久化用來做大的備份，
而AOF持久化用來做做精細備份。
資料還原的時候，快照持久化和AOF持久化可以一起來還原。
還原的時候也十分簡單，在任何一臺伺服器上，只要拿到備份檔案，都可以進行資料備份。
至此，兩種持久化方式介紹完畢。