一、Redis的持久化
redis與memcached相比，不同在於redis可支持持久化，且數據結構豐富：string, list, set, zset, hash等多種數據結構。
1.1、前言
Redis的所有數據都存儲到內存中，然後不定期的以異步的方式存儲到磁盤上（也稱爲半持久化模式），也可以把每一次數據變化都寫入到一個aof（append only file）文件中（稱爲全持久化模式）。
由於redis中的數據都存在內存中，如果沒有配置持久化，redis重啓後數據就全丟了。於是需要開啓redis的持久化功能，將數據保持到磁盤上。這樣當redis重啓後，就可以從磁盤上的文件恢復數據到內存。
1.2、Redis的持久化方式
1.2.1、redis支持兩種方式持久化內存數據到磁盤：
- RDB：將redis內存中的數據，全量定時dump到磁盤文件上。
- AOF：將redis的操作日誌以文件追加的方式寫入磁盤文件。AOF提供了三種數據同步策略：每秒同步、每修改同步、不同步。
1.2.2、二者區別：
RDB：定時將redis內存中的全量數據寫入磁盤，實際操作過程是fork一個子進程，先將redis的全部內存數據寫入一個臨時文件，寫入成功後，再替換之前的文件，然後用二進制壓縮存儲。
AOF：以記錄日誌的方式記錄redis每一個寫、刪操作，查詢操作不記錄。
1.2.3、二者優缺點
1、RDB
優勢：
- Redis的備份文件只有一個，災難恢復時方便
缺點：
- 備份RDB文件時，需要花費時間長，一旦此時宕機，未寫入磁盤的數據將丟失
- RDB是fork一個子進程來協助完成數據集備份的，因此當數據集很大時，服務器可能會停服幾百秒~1分鐘。
2、AOF
優勢：
- 相比RDB而言，具備更好的數據安全性：以每秒同步爲例，如果某時redis宕機，那麼丟失的只是沒來得及同步的1秒的數據。且這種append操作不會破壞原來已備份的數據文件。
缺點：
- AOF文件要大於RDB文件，RDB文件在恢復大數據集時的速度要快於AOF文件
1.2.4、二者如何選擇
選擇AOF：寧願犧牲一些性能，來換取更高的緩存一致性
選擇RDB：在寫操作頻繁的時候，不啓用備份來換取更高的性能，待手動運行save的時候，再執行RDB。
1.3、常用配置
1.3.1、RDB持久化配置
redis會將數據集dump到dump.rdb文件中，我們可以通過配置文件來修改RDB的dump頻率：在打開6379.conf文件後，搜索save，可以看見下面的配置信息：
save 900 1 #在900秒(15分鐘)之後，如果至少有1個key發生變化，則dump內存快照。
save 300 10 #在300秒(5分鐘)之後，如果至少有10個key發生變化，則dump內存快照。
save 60 10000 #在60秒(1分鐘)之後，如果至少有10000個key發生變化，則dump內存快照。
1.3.2、AOF持久化配置
在Redis的配置文件中存在三種同步方式，它們分別是：
appendfsync always #每次有數據修改發生時都會寫入AOF文件。
appendfsync everysec #每秒鐘同步一次，該策略爲AOF的缺省策略。
appendfsync no #從不同步。高效但是數據不會被持久化。
二、Redis的主從同步
2.1、爲什麼需要主從同步
在分佈式系統設計中，要避免單點問題，也就是說即便是Redis的某臺機器掛了，也不能影響到業務的正常使用。
2.2、主從同步的過程
1、增量同步：也叫指令同步，從庫按照順序，重放在主庫中進行的指令。就好比象棋的覆盤。
Redis會把指令存放在一個環形隊列當中，爲什麼要放一個環形隊列呢？因爲內存的容量畢竟有限，如果備機一直起不來，不可能把所有的內存都去存指令，也就是說，如果備機一直未同步，指令可能會被覆蓋掉。
如果指令被覆蓋掉了，那麼肯定增量同步就不行了，這個時候只好寄出我們的殺器，全量同步。
2、全量同步：又稱快照同步。
快照，就跟照片一樣，記錄着在某一個時間點所有鍵值狀態。在Redis中，獲取一個快照的命令並不難，我們可以手動創建一個快照，也可以通過配置，後臺根據相關規則創建快照。在Redis中，我們可以通過save命令，就可以創建快照，因爲Redis是單進程的，使用save命令會影響性能，所以通常我們會使用bgsave。
在redis.conf中，有着自動保存的配置，上述是Redis的默認配置，說的是在900秒內，如果有1個key變更，或者300秒內，有300個key變更，或者60秒內，有1個key變更，就會後臺出發生成快照功能。