redis之持久化

redis持久化

配置及启动

• 在cof文件下面有一个redis.cnf文件可以设置配置文件
  • 大概有几个可以先试用,port,端口号
  • daemonize是否开启守护线程,日志不直接打出来,而是放在日志里面
  • logfile:日志文件放在那里
  • dir:数据放在哪个目录
• redis的启动
  • 在启动时也可以加上配置文件,表示试用该配置文件:redis-server 当前文件下配置文件的地址
  • redis-server 直接启动,不适用配置文件
  • redis-server – port 8808 设置端口号为8808的服务
• redis客户端的链接
  • redis-cli 默认链接
  • redis-cli -h 127.0.0.1 -p 8808使用哪个地址启动也可以单独某个端口,不需要地址也可以

持久化

• 持久化的分类
  • 将当前数据状态进行保存.快照形式,存储数据结果,存储格式简单,关注点在数据
  • 将数据的操作过程进行保存,日志格式,存储操作过程,存储格式复杂,关注点在数据的操作过程

RDB

• REB启动的方式
  • save命令,手动操作,直接阻塞当前所有线程进行数据的保存
  • bgsave命令,手动操作,启动子线程进行数据的保存,不影响当前redis的使用
  • 配置的形式:在cof里面的配置文件进行配置
    • dbfilename: 设置本地数据库文件名,默认为dump.rdb,可以设置为dump+端口号.rdb
    • dir:保存rdb文件的路径,可以专门建立一个文件夹来保存
    • rdbcompression:yes 设置存储到本地的数据是否压缩数据,默认为yes,采用lzf压缩,设置为no,节省cpu运行时间,但是文件变大
    • rdbxchecksum:yes 设置是否进行RDB文件格式校验,在写文件和读文件过程都进行,设置为no,节约时间消耗,但是有一定数据损坏风险
    • stop-writes-on-bgsave-error:yes 后台存储过程如果出现错误现象,是否停止保存操作,默认yes
    • save second changes,满足限定时间内key的变化数达到了就进行持久化,在second秒内,key被改变了changes次,就进行持久化
• 工作原理

  • bgsave
    

  • save配置
    

  • RDB三种启动方式对比(save和配置save其实是一种)

  • RDB启动的形式

    • 全量复制的时候
    • 服务器运行过程中重启:debug reload
    • 关闭服务器时指定保存数据 shutdown save
• RDB优点
  • RDB是一个紧凑压缩的二进制文件存储效率高
  • RDB内存存储的是redis在某个时间点的数据快照,适合数据备份,全量备份等场景
  • RDB恢复数据速度比AOF快
  • 服务器中每隔一段时间执行bgsave备份,然后将RDB拷贝到远程机器中,用于灾难恢复
• RDB缺点
  • RDB方式无论是执行指令还是配置,无法做到实时持久化,较大可能性丢失数据
  • bgsave每次运行都要执行fork操作创建子线程,牺牲一部分性能
  • redis版本多,RDB格式没统一,容易版本之间无法兼容问题

AOF

• 以独立日志的方式记录每次写命令,重启时重新执行AOF文件中命令
• 主要是为了解决数据持久化的实时性,redis持久化的主流方式,增量备份

  AOF写数据三种策略

  • always:每次写入都同步到AOF文件中,数据零误差,性能较低,不建议使用
  • everysec:每秒将缓冲区的指令同步到AOF文件中,.数据准确性较高,性能较高,建议使用,最多丢失1s数据
  • no:系统控制,整体过程不可控

  AOF相关配置

  • appendfilename filename:持久化的文件名称,建议appendonly-端口号.aof
  • dir AOF持久化文件保存路径,和RDB文件保持一致

AOF重写

• 随着命令不断写入AOF,文件会越来越大,为了解决这个问题,redis引入了AOF重写机制压缩文件体积,AOF文件重写是将redis进程内的数据转化为写命令同步到新AOF文件的过程,就是把几条命令压缩成一条
• 作用
  • 降低磁盘占用量,提高磁盘利用率
  • 提高持久化效率,降低持久化写时间,提高io性能
  • 减低数据恢复用时,提高数据恢复效率
• 重写规则
  • 进程内已经超时的数据不再写入文件
  • 忽略无效指令,重写使用进程内数据直接生成,就是一些del 在新增的操作,只保留最后一条
  • 把多条操作同个key的操作,只保留最后一条
• 重写方式
  • 手动重写:bgrewriteaof
  • 自动重写:auto-aof-rewrite-min-size size :最小数据块
  • 自动重写:auto-aof-rewrite -percentage percentage 自动重写百分比
  • 自动重写触发比对参数,运行指令info Persistence获取具体信息
    • aof_current_size:aof修改的数据
    • aof_base_size: aof原本的数据
  • 自动重写触发条件
    • aof_current_size < auto-aof-rewrite-min-size
    • auto-aof-rewrite -percentage percentage <= (aof_current_size-aof_base_size)/aof_base_size

  重写流程

  
  

  RDB和AOF对比

  

  RDB和AOF选择

  • 对数据非常敏感,建议使用默认的AOF持久化方案
    • AOF持久化策略使用everysecond,每一秒一次,这样redis还能保持比较好的性能,最多丢失1s数据
    • AOF文件较大,恢复速度比较慢
  • 数据呈阶段有效性,使用RDB持久化方案
    • 数据可以良好的做到阶段内无丢失
    • 但是RDB备份时间间隔太短会使得redis的性能降低
  • 综合对比
    • 各有利弊,相互权衡
    • 无法承受数分钟内的数据丢失,数据敏感,使用AOF
    • 能承受数分钟内的数据丢失,而且追求大数据的恢复速度,用RDB
    • 灾难恢复选用RDB
    • 双保险策略,都开启使用,重启后,redis优先使用AOF恢复数据