Redis实战 | 持久化、主从复制特性和故障处理思路

时间:2020-01-08 二营长的笔记人气:0

前言

前面两篇我们了解了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：
公众号：二营长的笔记

加载全部内容