Redis持久化详解

  • RDB:快照形式是直接把内存中的数据保存到一个 dump 文件中,恢复时是将快照文件直接读到内存里。适合做冷备,定时同步数据到其它服务器上
  • AOF:把所有的对Redis的服务器进行修改的命令都存到一个文件里,命令的集合。适合做热备,slave开启AOF,master宕机就行主从切换

Redis默认是快照RDB的持久化方式

一、RDB

RDB 有两种触发方式,分别是自动触发和手动触发

  • 自动触发

    在 redis.conf 配置文件中的 SNAPSHOTTING 下,加上如下配置:

    save 900 1:表示900 秒内如果至少有 1 个 key 的值变化,则保存
    save 300 10:表示300 秒内如果至少有 10 个 key 的值变化,则保存
    save 60 10000:表示60 秒内如果至少有 10000 个 key 的值变化,则保存
    

    当然如果你只是用Redis的缓存功能,不需要持久化,那么你可以注释掉所有的 save 行来停用保存功能,也可以使用`redis-cli config set save ""命令

  • 手动触发

    手动触发Redis进行RDB持久化的命令有两种:

    1. save

      该命令会阻塞当前Redis服务器,执行save命令期间,Redis不能处理其他命令,直到RDB过程完成为止

    2. bgsave

      执行该命令时,Redis会在后台异步进行快照操作,快照同时还可以响应客户端请求。具体操作是Redis进程执行fork操作创建子进程,RDB持久化过程由子进程负责,完成后自动结束。阻塞只发生在fork阶段,一般时间很短

基本上 Redis 内部所有的RDB操作都是采用 bgsave 命令

恢复数据

将备份文件 (dump.rdb) 移动到 redis 安装目录并启动服务即可,redis就会自动加载文件数据至内存了。Redis 服务器在载入 RDB 文件期间,会一直处于阻塞状态,直到载入工作完成为止。

获取 redis 的安装目录可以使用 config get dir 命令

RDB优势与劣势

优势:

  • RDB是一个非常紧凑(compact)的文件,它保存了redis 在某个时间点上的数据集。这种文件非常适合用于进行备份和灾难恢复
  • 生成RDB文件的时候,redis主进程会fork()一个子进程来处理所有保存工作,主进程不需要进行任何磁盘IO操作
  • RDB 在恢复大数据集时的速度比 AOF 的恢复速度要快

劣势:

  • RDB方式数据没办法做到实时持久化/秒级持久化。因为bgsave每次运行都要执行fork操作创建子进程,属于重量级操作(内存中的数据被克隆了一份,大致2倍的膨胀性需要考虑),频繁执行成本过高(影响性能)
  • RDB文件使用特定二进制格式保存,Redis版本演进过程中有多个格式的RDB版本,存在老版本Redis服务无法兼容新版RDB格式的问题(版本不兼容)
  • 在一定间隔时间做一次备份,所以如果redis意外down掉的话,就会丢失最后一次快照后的所有修改(数据有丢失)
  • RDB文件恢复数据速度比较快

二、AOF

AOF配置

在 redis.conf 配置文件的 APPEND ONLY MODE 下:

  • appendonly no 默认配置,表示不开启AOF持久化
  • appendfilename “appendonly.aof” AOF日志文件名
  • appendfsync: aof持久化策略的配置;
    • no表示不执行fsync,由操作系统保证数据同步到磁盘,速度最快,但是不太安全;
    • always表示每次写入都执行fsync,以保证数据同步到磁盘,效率很低;
    • everysec表示每秒执行一次fsync,可能会导致丢失这1s数据。通常选择 everysec ,兼顾安全性和效率
AOF文件恢复

重启 Redis 之后就会进行 AOF 文件的载入

AOF重写

AOF文件不断变大,Redis为了解决这种情况,在文件大小达到一定阈值后,进行AOF重写,对AOF文件进行压缩,只保留可以恢复数据的最小指令集

举个例子:

sadd key "A" "B" "C"

如果不重写会保留三条sadd指令,但是重写只会保留一条

  • 执行AOF重写的时候,会直接读取服务器内存的所有键值对,不是对之前的AOF文件进行整理
  • 子进程进行 AOF 重写期间,服务器进程(父进程)可以继续处理其他命令
  • 子进程带有父进程的数据副本,使用子进程而不是线程,可以在避免使用锁的情况下,保证数据的安全性

主进程和子进程之前可能会产生数据不一致,解决方案:

Redis 服务器设置了一个 AOF 重写缓冲区,这个缓冲区是在创建子进程后开始使用,当Redis服务器执行一个写命令之后,就会将这个写命令也发送到 AOF 重写缓冲区。当子进程完成 AOF 重写之后,就会给父进程发送一个信号,父进程接收此信号后,就会调用函数将 AOF 重写缓冲区的内容都写到新的 AOF 文件中

AOF优缺点

优点:

  • AOF 持久化的方法提供了多种的同步频率,即使使用默认的同步频率每秒同步一次,Redis 最多也就丢失 1 秒的数据而已
  • AOF 文件使用 Redis 命令追加的形式来构造,因此,即使 Redis 只能向 AOF 文件写入命令的片断,使用 redis-check-aof 工具也很容易修正 AOF 文件
  • AOF 文件的格式可读性较强,这也为使用者提供了更灵活的处理方式。例如,如果我们不小心错用了 FLUSHALL 命令,在重写还没进行时,我们可以手工将最后的 FLUSHALL 命令去掉,然后再使用 AOF 来恢复数据。

缺点:

  • 对于具有相同数据的的 Redis,AOF 文件通常会比 RDF 文件体积更大
  • 在 Redis 的负载较高时,RDB 比 AOF 具好更好的性能保证
  • AOF可能存在bug
  • 利于AOF恢复数据太慢

三、生产持久化策略

生产上采用的持久化策略为

  • master关闭持久化
  • slave开RDB即可,对数据安全性要求比较高的AOF和RDB都开启

对于绝大部分业务场景来说,都是可以容忍缓存的部分数据丢失的,这是因为缓存的数据一般在数据库也会存在一份,数据库的安全性高于缓存,所以一般我们会以数据库的数据为准

无论使用哪种持久化方式都会影响redis的性能,哪一种持久化都会造成CPU卡顿,影响对客户端请求的处理,所以为了保证读写最佳性能,需要将master的持久化关闭

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值