Redis實戰 | 持久化、主從複製特性和故障處理思路

前言

前面兩篇咱們瞭解了Redis的安裝、Redis最經常使用的5種數據類型。本篇總結下Redis的持久化、主從複製特性，以及Redis服務掛了以後的一些處理思路。

前期回顧傳送門：

Linux下安裝Redis簡易教程
Redis實戰 | 5種Redis數據類型詳解

Redis的兩種持久化方式

常常有面試官會問：Redis數據存儲在內存中，萬一斷電了怎麼辦呢？

不要慌，這個其實就是在問Redis的持久化策略啦。咱們知道，保存在內存中的數據，在服務重啓或者是機器掛掉以後是會丟失的。而硬盤中的數據是不會丟失的，所以只有將數據保存在硬盤上才相對安全些。

Redis爲了追求高性能而將數據存在內存中，同時也提供了持久化的選項保證數據的安全性。這兩種方式是：

• RDB快照持久化，就是將某一時刻的數據寫入硬盤中
• AOF只追加文件的方式，就是將被執行的寫命令追加到文件，並保存到硬盤裏

一、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丟失數據的問題，其實就是在兩次同步數據之間，若是服務器發生崩潰，便會丟失掉這之間的數據。

二、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服務做爲主服務器替換上去。

具體的替換計劃是這樣的：

1. 首先向B發送一個SAVE命令，讓它建立一個最新的快照文件
2. 接着將這個快照文件發送給機器C，並在機器C上面啓動Redis
3. 在機器B上執行slaveof 命令，讓它將C機器做爲主服務器

做者Info：公衆號：二營長的筆記