您的位置:首页 > 数据库 > Redis

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

2020-01-07 23:19 1136 查看

前言

前面两篇我们了解了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服务作为主服务器替换上去。

具体的替换计划是这样的:

  1. 首先向B发送一个SAVE命令,让它创建一个最新的快照文件
  2. 接着将这个快照文件发送给机器C,并在机器C上面启动Redis
  3. 在机器B上执行slaveof 命令,让它将C机器作为主服务器

作者Info:
公众号:二营长的笔记

内容来自用户分享和网络整理,不保证内容的准确性,如有侵权内容,可联系管理员处理 点击这里给我发消息
标签: