Redis持久化配置

1.Redis持久化之RDB

  • Redis持久化介绍

    • Redis是一个内存数据库,如果没有配置持久化,Redis重启后数据就全丢失
    • 因此开启Redis的持久化功能,将数据保存到磁盘上,当Redis重启后,可以从磁盘中恢复数据
  • 两种持久化方式

    • RDB(Redis DataBase)
    • AOF(Append Only File)
  • RDB持久化介绍

    • 在指定的时间间隔内将内存中的数据集快照写入磁盘
    • 默认的文件名为dump.rdb
    • 产生快照的情况
      • save
        • 会阻塞当前Redis服务器,执行save命令期间,Redis不能处理其他命令,直到RDB过程完成为止
      • bgsave
        • fork创建子进程,RDB持久化过程由子进程负责,会在后台异步进行快照操作,快照同时还可以响应客户端请求
      • 自动化
        • 配置文件来完成,配置触发Redis的RDB持久化条件
        • 比如"save m n":表示m秒内数据集存在n次修改时,自动触发bgsave
      • 主从架构
        • 从服务器同步数据的时候,会发送sync执行同步操作,master主服务器就会执行bgsave
  • 优点

    • RDB文件紧凑,全量备份,适合用于进行备份和灾难恢复
    • 在恢复大数据集时的速度比AOF的恢复速度要快
    • 生成的是一个紧凑压缩的二进制文件
  • 缺点

    • 每次快照是一次全量备份,fork子进程进行后台操作,子进程存在开销
    • 在快照持久化期间修改的数据不会被保存,可能丢失数据
  • 持久化配置

    # 持久化文件名 
    dbfilename dump.rdb
    
    # 持久化文件存储地址
    dir /usr/local/redis6/data
    
    # 持久化机制 3600秒内有1个key改动执行快照
    save 3600 1
    
    # 导出RDB数据库文件压缩字符串和对象,默认yes,会浪费CPU但是节省空间
    rdbcompression yes
    
    # 导入时是否检查
    rdbchecksum yes
    

2.Redis持久化之AOF

  • AOF持久化介绍

    • append only file,追加文件的方式,文件容易被人读懂
    • 以独立日志的方式记录每次写命令,重启时再重新执行AOF文件中的命令达到恢复数据的目的
    • 写入过程宕机,也不影响之前的数据,可以通过redis-check-aof检查修复问题
  • 配置实战

    # 开启AOF,默认不开启
    appendonly yes
    
    # AOF文件名
    appendfilename "appendonly.aof"
    
    # AOF持久化策略,每秒钟同步一次
    appendfsync everysec
    
  • 核心原理

    • Redis每次写入命令会追加到aof_buf(缓冲区)
    • AOF缓冲区根据对应的策略向硬盘做同步操作
    • 高频AOF会带来影响,特别是每次刷盘
  • 提供了3种同步方式,在性能和安全性方面做出平衡

    • appendfsync always:每次有数据修改发生时都会写入AOF文件,消耗性能多
    • appendfsync everysec:每秒钟同步一次,该策略为AOF的缺省策略
    • appendfsync no:不主从同步,由操作系统自动调度刷磁盘,性能是最好的,但是最不安全

3.Redis持久化之AOF rewrite

  • rewrite重写介绍

    • AOF文件越来越大,需要定期对AOF文件进行重写达到压缩
    • 旧的AOF文件含有无效命令会被忽略,保留最新的数据命令
    • 多条写命令可以合并为一个
    • AOF重写降低了文件占用空间
    • 更小的AOF文件可以更快地被Redis加载
  • 重写触发配置

    • 手动触发
      • 直接调用bgrewriteaof命令
    • 自动触发
      • auto-aof-rewrite-percentage 100:表示当前AOF文件空间和上一次重写后AOF文件空间(aof_base_size)的比值
      • auto-aof-rewrite-min-size 64mb:表示运行AOF重写时文件最小体积,默认64MB
  • 配置实战

    # AOF重写期间是否同步
    no-appendfsync-on-rewrite no
    
    # 重写触发配置
    # 当前AOF文件空间和上一次重写后AOF文件空间(aof_base_size)的比值
    auto-aof-rewrite-percentage 100
    # 运行AOF重写时文件最小体积
    auto-aof-rewrite-min-size 64mb
    
    # 加载AOF时如果有错如何处理:yes表示如果AOF尾部文件出问题,写log记录并继续执行;no表示提示写入等待修复后写入
    aof-load-truncated yes
    

4.Redis持久化RDB+AOF混合模式

  • Redis提供了不同的持久化选项

    • RDB持久化以指定的时间间隔执行数据集的时间点快照
    • AOF持久化记录服务器接收的每个写入操作,将在服务器启动时再次读取,重建原始数据集。使用与Redis协议本身相同的格式以仅追加方式记录命令,当文件太大时,Redis能够重写
  • RDB的优缺点

    • 优点
      • RDB最大限度地提高了Redis的性能,父进程不需要参与磁盘I/O
      • RDB文件紧凑,全量备份,适合用于进行备份和灾难恢复
      • 在恢复大数据集时的速度比AOF的恢复速度要快
      • 生成的是一个紧凑压缩的二进制文件
    • 缺点
      • 如果您需要在Redis停止工作时(例如断电后)将数据丢失的可能性降至最低,则RDB并不友好
      • RDB经常需要fork才能使用子进程持久存储在磁盘上。如果数据集很大,fork可能会非常耗时
  • AOF的优缺点

    • 优点
      • 数据更加安全
      • 当Redis AOF文件太大时,Redis能够在后台自动重写AOF
      • AOF以易于理解和解析的格式,一个接一个地包含所有操作的日志
    • 缺点
      • AOF文件通常比同一数据集的等效RDB文件大
      • 根据确切的fsync策略,恢复的时候AOF可能比RDB慢
  • 线上如何选取

    • RDB持久化与AOF持久化一起使用
    • 如果Redis中的数据并不是特别敏感或者可以通过其它方式重写生成数据
    • 集群中可以关闭AOF持久化,靠集群的备份方式保证可用性
    • 自己指定策略定期检查Redis的情况,然后可以手动触发备份、重写数据
    • 采用集群和主从同步
  • Redis4.0后开始的rewrite支持混合模式

    • 就是RDB和AOF一起用
    • 直接将RDB持久化的方式来操作将二进制内容覆盖到AOF文件中,RDB是二进制,所以很小
    • 有写入的话还是继续append追加到文件原始命令,等下次文件过大的时候再次rewrite
    • 默认是开启状态
    • 好处
      • 混合持久化结合了RDB持久化和AOF持久化的优点,采取了RDB文件小易于灾难恢复
      • 同时结合AOF,增量的数据以AOF方式保存了,数据更少的丢失
    • 坏处
      • 前部分是RDB格式,是二进制所以阅读性较差
    • 数据恢复
      • 先看是否存在AOF文件,若存在则先按照AOF文件恢复,AOF比RDB全,且AOF文件也rewrite成RDB二进制格式
      • 若AOF不存在,则才会查找RDB是否存在

你可能感兴趣的:(Redis,redis)