前言
前面将了redis的主從複制以及怎麼搭建，還介紹了哨兵模式以及哨兵模式的搭建。雖然操作跟上了，但是還是補一下redis的持久化。redis之是以這麼流行，很大一部分原因便是持久化，斷電重新開機資料不消失，使得redis在資料庫領域中站穩了腳。前文将的主從複制其實就是依賴持久化的，如果沒有持久化，這些資料都不會從主伺服器備份到從伺服器。下文我們就講講redis的持久化。
說起redis持久化，大家或多或少都知道一些，簡單點一句話也能概括。redis通過RDB和AOF方式将資料存入磁盤，實作持久化。RDB是定期生成快照存入磁盤中，AOF是将寫操作存入磁盤中。二者各有優劣，RDB 是存放資料庫中資料，适合做資料備份，但是資料可能不全，最近幾分鐘的資料可能沒有。AOF是每秒鐘執行一次，如果有寫操作的指令就存儲起來，最多隻會丢失1秒鐘的資料，适合做資料恢複。但是這個就不适合做資料備份了，并且由于每秒都會執行多多少少會搶占redis的記憶體，會影響性能。但是在實際應用中是二者是配合使用的。
下面就來具體的講講RDB和AOF吧
RDB
RDB 的全稱是 redis database. 顧名思義，RDB就是将redis資料庫，用來存儲資料的，是以通過RDB方式持久化就是将存在redis記憶體中的資料寫入到RDB檔案中儲存到磁盤上進而實作持久化的。
RDB檔案是一個壓縮的二進制檔案，通過這個檔案可以還原redis資料庫的資料，進而達到資料恢複的目的，借用一下《redis設計與實作》講的這張圖，圖中資料庫狀态可以了解為redis記憶體中存儲的資料。
既然RDB持久化的方式是生成RDB檔案，那麼這個RDB檔案是怎麼生成的呢？
RDB檔案生成的方式有兩種，一種是通過指令手動生成快照，還有一個是通過配置自動生成快照。下面我們來分别看看。
通過save和bgsava指令生成RDB檔案
這兩個指令都是可以直接運作的。
save指令，會阻塞伺服器程序，隻有當RDB檔案生成成功才會接着響應服務端的其他指令。
而bgsave ，既然有這個指令，肯定是和save有所不同的，bgsave 不會阻塞伺服器程序，會建立一個子程序來建立RDB檔案
但是注意的是使用bgsave指令的時候，雖然是通過子程序生成RDB檔案，不會阻塞服務程序，其他的指令可以執行，但是有幾個指令是不能執行的。
save
bgsave
bgrewriteaof 複制
在bgsave 期間 伺服器拒絕這三個指令，主要是方式線程間競争産生問題。
通過配置檔案自動生成RDB
除了手動執行這兩個指令外，還可以在配置檔案中配合參數，達到條件的時候就會自動的生成RDB
打開我們的配置檔案redis.conf,找到如下圖，這個是預設的配置。
save 900 1
表示在900秒内，如果發生了一次寫操作，就觸發bgsave指令生成RDB
同理
save 300 10 在300秒内，發生了10次寫操作，就觸發bgsave
save 60 10000 在60秒内發生了10000次寫操作，就觸發bgsave 複制
上面的這些可以進行配置，可以看到預設的設定，如果短時間内發生大量的寫操作就會自動的觸發bgsave ,生成RDB檔案， 防止資料丢失。
好了，上面雖然說達到這三個條件中的一個，redis就會自動的生成RDB檔案，那系統是怎樣控制，又是怎樣識别是否滿足條件呢？
原來啊，伺服器維持了一個dirty 計數器，以及一個lastsave屬性。
dirty 計數器記錄着從上次save/bgave 到現在發生了多少次寫操作，沒進行一次寫操作，計數器就加1
比如
set a 123
計數器dirty 加1
set a 123 b 234 c 456
計數器dirty 加3 複制
而lastsave 是unix時間戳，記錄上次save或bgsave的時間。
有了這兩個屬性，就可以判斷什麼時候執行啦，redis伺服器會周期性的執行serverCron函數,預設的話是每100毫秒執行一次。
這個serverCron 函數先通過目前時間減去lastsave 擷取時間間隔。
如果dirty 大于 saveparm.chranges
并且時間間隔大于saveparm.seconds
那麼就會觸發bgsave 生成 RDB檔案
其中saveparm.seconds 和saveparm.chranges 分别對應的是配置檔案中設定的save 900 1等。
既然生成了RDB檔案，我們隻知道RDB是一個壓縮的二進制檔案，那RDB檔案到底結構是什麼樣的呢？
我看了一下《redis 設計與實作》沒有怎麼看明白哈哈，感興趣的可以去看看。
RDB方式就講到這裡了，記住RDB方式，是定時的執行bgsave 指令生成RDB檔案儲存在磁盤上實作持久化的。适合資料備份，用于資料恢複可能會丢失最近幾分鐘的資料。
AOF
全稱是append only file. AOF 持久化的方式是通過redis伺服器記錄儲存下所有的寫指令到AOF檔案存放在磁盤上，實作持久化的，看下圖：
怎樣采用AOF的方式持久化呢？
打開我們的配置檔案，在配置檔案中找到appendonly 改成yes 就可以采用AOF的方式備份了
我們啟動redis服務，為了測試友善，我們新啟的一個redis服務，資料庫中沒有任何key
我們看看appendonly.aof 也是沒有任何東西的。
現在我們存入一個key
然後我們來看下aof檔案的内容：
可以看到，除了一些$3等一些特殊符号外我們可以看到我們執行的指令。
select 0
set a bbb 複制
但是我們一些讀操作的就不會記錄。由此可見，AOF 持久化就是将所有的寫操作存入AOF檔案中，當資料恢複的時候，執行AOF檔案中的指令就可以擷取資料了。
我們接着來看那，我向資料庫中先加一個key b ,然後删除key a .
好了，現在我們再來看看aof 檔案中是什麼情況。
可以看到指令有：
select 0
set a bbb
set b ddd
del a 複制
是以aof 檔案中包含了這四條指令，到這大家有沒有發現一個問題，如果我重複的對某一個key值進行操作，那麼aof檔案中就會記錄所有的操作指令，但是實際上隻有最後一次操作才是有效的，那這個aof檔案中是不是就有很多備援的資料呢？
實際上是這樣的，那怎麼解決這個問題呢？這裡就要提到一個指令啦
BGREWRITEAOF 複制
和RDB中的save 以及bgsave 是類似的。不過bgrewriteaof 指令的作用是重寫aof檔案，為什麼要重寫呢，就是為了解決aof檔案中備援的問題。
我們先來手動執行一下這個指令
然後看看aof 檔案中的内容
可以看到指令變成了
select 0
set b ddd 複制
重寫之後，aof的檔案裡的指令就是有效的啦，但是我們總不能自己手動執行bgrewriteaof 指令吧，那我們在哪裡配置呢?
在redis.conf 配置檔案中有這兩個參數。
auto-aof-rewrite-percentage 100
當Aof log增長超過指定比例時，重寫log file， 設定為0表示不自動重寫Aof 日志，重寫是為了使aof體積保持最小，而確定儲存最完整的資料。
auto-aof-rewrite-min-size 64mb
觸發aof rewrite的最小檔案尺寸
也就是說在實際應用中，如果開啟了aof 備份，可以設定這兩個參數來重寫AOF檔案。
好了上面說了那麼多，那redis服務怎麼通過aof檔案來恢複資料的呢？
其實很簡單，就是将aof 檔案中的指令一條一條的讀取出來執行。看下圖
最後再說一點嘿嘿。
我們在配置檔案中同時啟用了RDB 和AOF ,那麼服務啟動的時候，會在用那個檔案來回複資料呢？
看下面這張圖。
可以看到如果啟動aof ,就會采用aof 檔案來回複資料，這是為什麼呢，因為AOF 檔案更新的頻率更高，模式一秒中一次，是以用AOF 恢複的資料更加準确。
好了，隻有這麼多了哈哈，推薦大家看看《redis 設計與實作》也不建議大家從頭往後看，挑感興趣的看吧，畢竟裡面還是有很多原理對我們而言也不是一定非得弄懂的，大概了解一下就行，我比較懶哈哈。
看到這的小夥伴，對文章有什麼建議趕緊提出來吧！這一期想寫 redis 的。從 redis 安裝到redis 簡單使用，redis主從複制，redis 持久化，哨兵模式，叢集模式。由淺及深圖文講解幫助大家全面深刻的了解reidis 知識。如果大家感興趣可以持續關注。