前言
前面兩篇我們了解了Redis的安裝、Redis最常用的5種數據類型。本篇總結下Redis的持久化、主從復制特性，以及Redis服務掛了之后的一些處理思路。
前期回顧傳送門：
Linux下安裝Redis簡易教程
Redis實戰 | 5種Redis數據類型詳解
Redis的兩種持久化方式
經常有面試官會問：Redis數據存儲在內存中，萬一斷電了怎么辦呢？
不要慌，這個其實就是在問Redis的持久化策略啦。我們知道，保存在內存中的數據，在服務重啟或者是機器掛掉之后是會丟失的。而硬盤中的數據是不會丟失的，因此只有將數據保存在硬盤上才相對安全些。
Redis為了追求高性能而將數據存在內存中，同時也提供了持久化的選項保證數據的安全性。這兩種方式是：
- RDB快照持久化，就是將某一時刻的數據寫入硬盤中
- AOF只追加文件的方式，就是將被執行的寫命令追加到文件，並保存到硬盤里
1、RDB持久化方式
什么是RDB持久化呢？
也叫快照持久化，就是將當前Redis數據庫中的數據快照保存一份到磁盤文件中（一般叫dump.rdb）。好了，這個時候如果斷電了，沒事啊，重啟后，Redis通過加載rdb文件可以將數據庫狀態恢復。基本上算是，滿血復活了（因為存在數據丟失問題，血不是很滿！）
RDB 功能最核心的是 rdbSave 和 rdbLoad 兩個函數， 前者用於生成 RDB 文件到磁盤， 而后者則用於將 RDB 文件中的數據重新載入到內存中
看圖說話：
怎么實現RDB的持久化呢？
SAVE 和 BGSAVE兩個命令來實現RDB持久化，這兩個命令都會調用 rdbSave 函數，將數據保存在rdb文件中。但是有所區別：
- SAVE命令會直接調用rdbSave函數，阻塞Redis主進程，在保存完成之前，Redis不再響應其他任何客戶端命令。
- BGSAVE命令fork出一個子進程，子進程調用rdbSave函數，這樣Redis主進程可以繼續處理客戶端請求。
一般我們怎么配置RDB持久化呢？
這里我們可以通過修改redis.conf配置文件中關於RDB持久化的選項讓Redis自動去執行持久化。比如下面這些選項：
# 900s之內有1次寫入
save 900 1
# 300s內有10次寫入
save 300 10
# 60s內有10000次寫入
save 60 10000
#執行bgsave失敗時是否繼續執行寫命令，默認是yes
stop-writes-on-bgsave-error yes
#是否對快照文件進行壓縮，模式是yes
rdbcompression yes
#快照文件的名稱，默認是dump.rdb
dbfilename dump.rdb
當配置了多個save選項時，當任意一個save配置項條件被滿足時，Redis就會觸發一次BGSAVE命令。
除了在redis.conf配置文件中配置rdb持久化之外，還有一些方式，可以創建快照：
- 通過直接在redis客戶端敲save或bgsave命令的方式觸發一次快照持久化
- 通過shutdown命令關閉服務器時，會執行一個SAVE命令，阻塞所有客戶端，並在SAVE命令執行完畢之后關閉服務器
前面說到，RDB丟失數據的問題，其實就是在兩次同步數據之間，如果服務器發生崩潰，便會丟失掉這之間的數據。
2、AOF持久化方式
什么是AOF，就是appendonly file的縮寫啦！
簡單來說，AOF持久化就是將被執行的寫命令追加到AOF文件的末尾，以此來記錄數據發生的變化。在恢復數據時，只需要從頭到尾重新執行一遍AOF文件所包含的所有命令即可。
那么，AOF持久化有哪些配置項呢？
# 是否使用appendonly模式，默認是no
appendonly no
# appendfilename文件名
appendfilename "appendonly.aof"
# appendfsync always //每個命令都同步
appendfsync everysec //沒秒執行一次同步，默認是這個
# appendfsync no //操作系統決定何時進行同步
# 在對aof文件進行壓縮的時候能否執行同步
no-appendfsync-on-rewrite no
AOF方式的持久化有個缺點，就是文件的體積比較大。
Redis為了緩解這個問題，給我們提供了BGREWRITEAOF的命令，這個命令會通過移除AOF文件中的一些冗余命令來重寫AOF文件，使得AOF文件的體積盡可能地縮小。類比BGSAVE命令，這里的BGREWRITEAOF命令也是fork出一個子進程進行AOF文件的壓縮（也就是重寫）工作。
同樣地，我們可以在redis.conf配置文件中配置AOF文件的重寫選項，讓Redis自動執行BGREWRITEAOF
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
這兩個配置的意思就是，當AOF文件的體積大於64MB，
並且AOF文件的體積比上一次重寫之后的體積大了至少一倍（100%）時，
Redis將執行AOF文件的重寫命令。
Redis的主從復制
單機版Redis實例存在的問題
- 首先是數據安全性問題，畢竟所有數據在一台機器上，萬一這台機器被炸毀了，豈不是沒救了。因此，需要多機器備份數據出來，Redis主從復制特性幫助我們實現數據的熱備份。
- 第二個就是性能問題了，尤其是在處理一些較復雜命令和較大數據集合的操作時，每秒處理的請求數會下降不少。
什么是主從復制
就是將一台Redis服務器的數據，復制到另外一台或幾台Redis服務器上。前者就是主服務器，后者就是從服務器。主服務器負責處理客戶端的讀寫請求，而從服務器可以分擔一部分讀請求或者負責所有的讀請求。
客戶端每次向主服務器寫入的命令，從服務器都能得到實時的更新。默認情況下，每台Redis服務器都是主節點；且一個主節點可以有多個從節點(或沒有從節點)，但一個從節點只能有一個主節點。
如何配置主從復制
配置主從復制其實很簡單，就一條命令 slaveof。配置主從復制，其實就是配置Redis的從服務器從哪台主服務器復制數據。主服務器不需要動的。
因此，我們可以修改從服務器的 redis.conf 文件，增加如下一行配置就行：
slaveof masterip port
除了配置文件的方式外，還可以在啟動redis實例的時候 加入 --slaveof masterip port ，這樣就會告訴redis實例從哪台機器和端口處復制數據。
也可以直接在redis客戶端執行命令 slaveof masterip port，讓服務器開始復制一個主服務器。
另外，如果要斷開同主服務器的復制，可以使用下面命令：
slaveof no one
Redis主從復制的具體過程是怎樣的
當從服務器連接主服務器時，主從服務器執行的大概操作如下圖所示：
需要注意的是，從服務器在進行同步時，會清空自己的所有數據。
故障處理
服務器宕機之后，可能需要恢復數據，這時候會用到之前說的持久化到硬盤上的aof或是dump快照文件。Redis給我們提供了兩個命令行工具，在系統故障之后，用來檢查aof文件和快照文件的狀態，並且在還有修復功能。
下面是這兩個命令行程序：
redis-check-aof
redis-check-dump
下面舉例一種故障的場景：
A是redis主服務器，B是從服務器。A機器故障暫無法修復。現將C機器上的redis服務作為主服務器替換上去。
具體的替換計划是這樣的：
- 首先向B發送一個SAVE命令，讓它創建一個最新的快照文件
- 接着將這個快照文件發送給機器C，並在機器C上面啟動Redis
- 在機器B上執行slaveof 命令，讓它將C機器作為主服務器
作者Info：
公眾號：二營長的筆記