Redis持久化

持久化流程

  • 客户端发起写操作
  • 服务器接收客户端请求的数据
  • 服务器调用write,将主数据写入磁盘
  • 操作系统将缓冲器数据转移到磁盘
  • 磁盘控制器将数据写到磁盘介质

RDB机制

这种方式是就是将内存中数据以快照的方式写入到二进制文件中,默认的文件名为dump.rdb

触发方式

  • save命令触发,该命令会阻塞服务,执行期间Redis不能出来其他命令
    • 执行完保持后生成新的RDB,并把旧文件替换
    • 如果客户端较多,这种方式不可取,影响范围广
  • bgsave命令触发,异步执行,不影响客户端请求
    • 服务器通过fork子进程,RDB持久化由子进程完成,阻塞只发生在fork阶段
  • 自动触发
    • save m n配置方式
    • save 900 1 900秒内有1个key变动则保存
    • save 300 10 300秒呢有10个key变动则保存
    • save 60 10000 60秒内有10000个key变动则保存

额外配置

  • stop-writes-on-bgsave-error 默认yes,最后一次保存失败,停止接收数据,让客户端指定发送故障
  • rdbcompression ;默认值是yes。对于存储到磁盘中的快照,可以设置是否进行压缩存储。

优势

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

劣势

  • 父进程修改内存子进程不会反应出来,所以在快照持久化期间修改的数据不会被保存,可能丢失数据

AOF机制(append only file)

redis会将每一个收到的写命令都通过write函数追加到文件中。通俗的理解就是日志记录。类似mysql binlog

  • 通过appendonly开启,默认关闭
  • appendfsync用于指定触发方式
    • always 每次数据变更都会记录,频繁写入性能影响很大
    • everysec 每秒记录一次
    • no 不做同步

优点

  • AOF可以更好的保护数据不丢失,一般AOF会每隔1秒,通过一个后台线程执行一次fsync操作,最多丢失1秒钟的数据。(2)AOF日志文件没有任何磁盘寻址的开销,写入性能非常高,文件不容易破损。

  • AOF日志文件即使过大的时候,出现后台重写操作,也不会影响客户端的读写。

  • AOF日志文件的命令通过非常可读的方式进行记录,这个特性非常适合做灾难性的误删除的紧急恢复。比如某人不小心用flushall命令清空了所有数据,只要这个时候后台rewrite还没有发生,那么就可以立即拷贝AOF文件,将最后一条flushall命令给删了,然后再将该AOF文件放回去,就可以通过恢复机制,自动恢复所有数据

缺点

  • 对于同一份数据来说,AOF日志文件通常比RDB数据快照文件更大

  • AOF开启后,支持的写QPS会比RDB支持的写QPS低,因为AOF一般会配置成每秒fsync一次日志文件,当然,每秒一次fsync,性能也还是很高的

对比 RDB AOF
启动优先级
文件体积 大(可开启重写)
恢复速度
数据安全性 丢数据 根据策略
轻重
备份过程 全量备份 增量备份
是否阻塞 save阻塞 不阻塞

问答

1. 在dump rdb过程中,aof如果停止同步,会不会丢失?  
    不会,所有的操作缓存在内存队列里,dump完后后,统一操作
2. aof重写是什么?
    aof重写就是把内存中的数据逆化成命令,写入到aof文件,以解决aof日志过大问题
3. 如果rdb和aof文件都存在,优先使用谁恢复数据?
    在这种情况下,当redis重启的时候会优先载入AOF文件来恢复原始的数据,因为在通常情况下AOF文件保存的数据集要比RDB文件完整
4. rdb和aof是否可以同时用?
    可以,推荐同时使用
5. 恢复时,rdb和aof哪个更快?
    rdb快,因为rdb是数据的内存映射,直接载入到内存,而aof是命令,需要逐条执行
6. 如何在不用【config set】命令的情况下,将Redis持久化由RDB切换到AOF
    客户端执行[CONFIG set appendonly yes]开启AOF
    关闭RDB CONFIG set save ''
    修改配置,添加appendfsync everyses,否则重启失效

你可能感兴趣的:(Redis持久化)