Redis持久化-RDB

持久化

言简意赅,持久化就是将内存中的数据存储在硬盘中.
持久化分为两种:

• RDB(快照)
  将当前数据状态进行保存,快照形式,存储数据结果,存储格式简单,关注点在数据

• AOF(日志)
  将数据的操作过程进行保存,日志形式,存储操作过程,存储格式复杂,关注点在数据的操作过程
  

  RDB

  save指令-启动方式
  命令:save
  作用:手动执行一次保存操作
  save指令相关配置
  

  Redis相关配置解释请点击
  save指令工作原理
  
  由于redis服务器是单线程任务执行序列,所以在使用save指令时,可能会阻塞当前的redis服务器,知道当前RDB过程完成为止,有可能会造成长时间阻塞.线上环境不建议使用.

  bgsave指令-启动方式(防止阻塞,后台执行)
  命令:bgsave
  作用:手动启动后操作,但不是立即执行
  bgsave指令工作原理
  bgsave命令是针对save阻塞问题做的优化,Redis内部所涉及到RDB操作都采用bgsave的方式

  save配置-启动方式
  配置:save second changes
  作用:满足限定时间范围内key的变化数量达到指定数量即进行持久化
  参数:scond 监控时间范围 changes 监控key的变化量
  位置:在conf文件中配置
  save配置工作原理
  save配置要根据实际业务情况进行设置,频度过高或过低都会出现性能问题,结果可能是灾难性的
  save配置中对于second与changes设置通常具有互补对应关系,尽量不要设置成包含性关系
  save配置启动后执行的是bgsave操作

  三种RDB启动方式对比
  因为save配置的底层还是bgsave,这里就将save指令和bgsave指令进行对比
  

  RDB优点

• RDB是一个紧凑压缩的二进制文件,存储效率较高

• RDB内存存储的是redis在某个时间点的数据快照,非常适合用于数据备份,全量复制等场景

• RDB恢复数据的速度要比AOF快

• 应用:服务器中每X小时执行bgsave备份,并将RDB文件拷贝到远程机器上,用于灾难恢复

  RDB缺点

• RDB方式无论是执行指令还是利用配置,无法做到实时持久化, 具有较大的可能性丢失数据

• bgsave指令每次运行要执行fork操作创建子进程,要牺牲掉一定的性能

• Redis的众多版本中未进行RDB文件格式的版本统一,有可能出现各版本服务之间数据格式无法兼容现象