Redis教程（二）——Redis的持久化

2019-06-14  本文已影响0人  AmosZhu

ok,今天我们来整理下Redis持久化这个知识点，Redis的持久化对于分布式缓存来说是必不可少的一个部分，试想，一个高流量的系统，如果突然某些原因导致系统宕机，那么怎么样才能将缓存中的数据重新找回呢？这时Redis的持久化就派上用场了。

在了解Redis持久化之前，我们还是带着问题去学习：

  1. Redis持久化有什么意义，为什么需要持久化
  2. Redis持久化的方式，以及各个方式的特点和使用方法
  3. 持久化方式的区别
  4. 企业级的持久化方案

Redis持久化

对于生产数据而言，在系统服务的过程中，由于某些原因系统宕机，从而导致系统数据丢失，这绝对是一次生成事故，是大灾难，那么有没有一种方法能在不影响系统性能的前提下，能将生产数据实时备份下来呢？答案肯定是有的，而且Redis进行很好的支持这个方法。

Redis通过持久化这个功能将生产数据有计划、实时的保存到磁盘中，等Redis服务端重启的时候，将数据再重新写入到Redis中，这样能最大限度的保证生产数据的完整性；So，总结来说，Redis的持久化就是为了数据备份，数据备份也是为了数据恢复。

Redis持久化的方式

Redis提供两种持久化的方式：RDB和AOF，这两种方式是可以同时使用的

RDB

RDB是Redis默认支持的持久化方式，就是当前进程的数据生产快照存入到磁盘中。RDB保存到文件中的数据是二进制数据流，RDB提供配置固定的时间间隔对数据进行快照存储。

    ## RDB主要涉及redis.conf下的几个配置项
    ## 1.持久化时间间隔设置，多条配置只要有一条满足就会执行持久化操作
    ## 每900秒钟里redis数据库有1条数据被修改则触发RDB
    save 900 1  
    ## 每300秒钟里redis数据库有10条数据被修改则触发RDB
    save 300 10
    ## 每60秒钟里redis数据库有10000条数据被修改则触发RDB
    save 60 10000
    ## 持久化文件名称
    dbfilename "dump.rdb"
    ## 持久化数据文件保存路径，默认是/usr/local/redis-5.0.5/src下，实际生产过程中需要配置其他的目录下
    dir ./

这里有必要说明下RDB的原理：

Redis在触发持久化后，会fork一个子进程，此时父进程和子进程同在
子进程将目前Redis进程的全部数据写入到一个临时文件RDB中
当子进程完成对新RDB文件的写入时，Redis用新的RDB的文件覆盖旧的RDB文件

  1. 触发RDB机制有两种：手动触发和自动触发 
    ## 查看redis持久化配置
    CONFIG GET save
    ## 修改redis持久化配置
    CONFIG SET save "60 10000"

注意：一般不使用save方法来持久化，我们知道Redis是单线程的，所以一旦执行save命令，则Redis就会调用主进程来执行内存数据持久化到文件中，这里为什么使用主进程，主要是后面介绍的bgsave正好相反，主进程被调用，则会阻塞进程，特别是数据量特别大的时候更是如此。

  1. RDB持久化的优点：
  1. RDB持久化的缺点：

AOF

AOF持久化就是以独立的日志来记录每次的写命令，然后Redis重启的时候 ，重新执行AOF的命令来完成Redis数据的恢复，这里的日志记录是每次的写命令而不是二进制数据流

这里有必要说明下AOF的实现原理：

所有的命令都会被追加到aof_buf这个缓冲区中
接着AOF缓冲区根据对应的同步策略想磁盘中做同步操作，此处的同步策略可以通过redis.conf中的appendfsync进行配置
随着AOF文件变大，可以通过rewrite机制来压缩Redis中的数据
Redis服务器重启会加载AOF文件用来恢复数据

  1. AOF必须手动开启，在redis.conf中设置如下参数
    ## 开启AOF持久化，默认关闭
    appendonly yes
    ## AOF文件名称（默认）
    appendfilename "appendonly.aof"
    ## AOF持久化策略 有三个值 always、everysec和no 默认是everysec 建议设置成everysec
    appendfsync everysec
    ## AOF自动重写的文件大小跟上一次重写的文件的百分比
    auto-aof-rewrite-percentage 100
    ## AOF自动重写的文件的最小值
    auto-aof-rewrite-min-size 64mb

其中appendfsync的配置如下：

可配置的值 配置说明
always 服务器会在每执行一个事件就把AOF缓冲区的内容强制性的写入硬盘上的AOF文件里，
可以看成你每执行一个redis写入命令就往AOF文件里记录这条命令，
这保证了数据持久化的完整性，但效率是最慢的，却也是最安全的
everysec 服务端每执行一次写操作（如set、sadd、rpush）也会把该条命令追加到一个单独的AOF缓冲区的末尾，
并将AOF缓冲区写入AOF文件，然后每隔一秒才会进行一次文件同步把内存缓冲区里的AOF缓存数据真正
写入AOF文件里，这个模式兼顾了效率的同时也保证了数据的完整性，
即使在服务器宕机也只会丢失一秒内对redis数据库做的修改
no redis数据库里的数据就算丢失你也可以接受，
它也会把每条写命令追加到AOF缓冲区的末尾，然后写入文件，
但什么时候进行文件同步真正把数据写入AOF文件里则由系统自身决定，
即当内存缓冲区的空间被填满或者是超过了设定的时限后系统自动同步。
这种模式下效率是最快的，但对数据来说也是最不安全的
  1. AOF的优点
  1. AOF的缺点

Redis持久化操作

我们通过上面的redis.conf配置文件的修改，开启RDB和AOF持久化的机制，然后再Redis中设置好对应的键值

为了测试RDB的持久化效果，我们可以设置1秒内有1条数据变化就执行RDB持久化

首先添加数据

image

查看是否生成备份文件

image

查看AOF的备份数据文件

image

查看RDB的备份数据文件

image

RDB和AOF的区别

比较项 RDB AOF
文件大小 小 大
备份频率 低 高
数据恢复速度 快 慢
写QPS 高 低
支持重写 否 是

Redis企业级数据持久化

AOF的重写机制

AOF重写的原理：

  1. 先是将当前Redis数据库中的数据读取出来，然后fork一个子进程，子进程会携带主进程的数据（数据为主进程上的所有的数据）副本将数据写入到新的AOF备份数据文件。
  2. 对于新执行的写入命令，主进程会将其写入到一个缓存中，一边将改动追加到现有的AOF文件中，这个缓存在fork出子进程之后开始启用
  3. 当子进程完成重写工作时，他会给主进程发送一个信号，主进程收到这个信号后，会将缓存中的所有的数据写入到新的AOF文件中，同时将该AOF文件重新替换原有的AOF文件

流程图表示

image
上一篇下一篇

猜你喜欢

热点阅读