Redis 持久化

Redis 持久化

• RDB 持久化

  RDB持久化方式能够在指定的时间间隔能对你的数据进行快照存储.

• Aof 持久化

  Aof 会在每次Redis 执行写操作时进行记录，当服务器宕机重启后 服务器会重新执行这些命令进行恢复，,AOF命令以redis协议追加保存每次写的操作到文件末尾.Redis还能对AOF文件进行后台重写,使得AOF文件的体积不至于过大.

• Aof与RDB 优缺点

  优点:

  RDB在保存RDB文件时父进程唯一需要做的就是fork出一个子进程,接下来的工作全部由子进程来做，父进程不需要再做其他IO操作，所以RDB持久化方式可以最大化redis的性能.
  与AOF相比,在恢复大的数据集的时候，RDB方式会更快一些.

  缺点:
  RDB 可能会在Redis服务器宕机丢失一些数据

  AOF

  优点:
  使用AOF 会让你的Redis更加耐久: 你可以使用不同的fsync策略：无fsync,每秒fsync,每次写的时候fsync.使用默认的每秒fsync策略,Redis的性能依然很好(fsync是由后台线程进行处理的,主线程会尽力处理客户端请求),一旦出现故障，你最多丢失1秒的数据.

  缺点:对于相同的数据集来说，AOF 文件的体积通常要大于 RDB 文件的体积。
  在redis中 默认开启RDB持久化

  配置 Redis 默认使用RDB 持久化

  • 配置RDB
    打开Redis.cnf 文件可以看到

    
    save 900 1
    save 300 10
    save 60 1000
    比如  save 60 1000 设置会让 Redis 在满足“ 60 秒内有至少有 1000 个键被改动”这一条件时， 自动保存一次数据集:
    dbfilename dump.rdb  // dump.rdb 表示 生成的rdb二进制文件 redis会在启动时恢复数据
    rdbchecksum yes        //（对rdb数据进行校验，耗费CPU资源，默认为yes）    
    stop-writes-on-bgsave-error yes    //（后台存储存储发生错误时禁止写入，默认为yes）
    
    rdbcompression yes  // （启动rdb文件压缩，耗费CPU资源，默认为yes）
    

  • 配置AOF

    // 在配置文件中加入如下 开启AOF持久化
    appendonly yes //从现在开始， 每当 Redis 执行一个改变数据集的命令时（比如 SET）， 这个命令就会被追加到 AOF 文件的末尾
    磁盘同步策略 默认每秒一次  
    appendfsync always  //每次
    
    appendfsync everysec // 每秒一次（足够快（和使用 RDB 持久化差不多），并且在故障时只会丢失 1 秒钟的数据。）
    
    appendfsync no //由操作系统执行，默认Linux配置最多丢失30秒
    

  现在我们重启redis 服务之后 就可以看到appendonly.aof 二进制文件

  如何出现断电导致AOF文件损坏

  • 可以使用redis-check-aof –fix 文件名.aof 修复aof文件

  工作原来

  AOF 重写和 RDB 创建快照一样，都巧妙地利用了写时复制机制:

  Redis 执行 fork() ，现在同时拥有父进程和子进程。
  子进程开始将新 AOF 文件的内容写入到临时文件。
  对于所有新执行的写入命令，父进程一边将它们累积到一个内存缓存中，一边将这些改动追加到现有 AOF 文件的末尾,这样样即使在重写的中途发生停机，现有的 AOF 文件也还是安全的。
  当子进程完成重写工作时，它给父进程发送一个信号，父进程在接收到信号之后，将内存缓存中的所有数据追加到新 AOF 文件的末尾。
  搞定！现在 Redis 原子地用新文件替换旧文件，之后所有命令都会直接追加到新 AOF 文件的末尾。