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，性能也还是很高的

问答

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，否则重启失效