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：公众号：二营长的笔记