由于redis的数据都直接存储在内存里，在服务器发生宕机时内存的数据会瞬间清空，那么必须要有重启时恢复数据的方法。
redis通过持久化机制将数据存储到磁盘中从而在服务器重启时恢复数据，这篇文章主要简介redis的持久化机制。

• rdb：rdb是通过快照的方式实现持久化，redis定期将数据集快照写入磁盘。

  • 触发RDB持久化过程分为手动触发和自动触发。手动触发的命令为save和bgsave。
    save：会阻塞主进程，一般不使用；bgsave：fork操作创建子进程，子进程执行，完成后自动结束，阻塞只发生在fork阶段，阻塞时间很短。
    自动触发都是通过bgsave的方式执行（save配置、从节点发送同步请求后主节点通过bgsave然后发送给从节点、默认情况下执行shutdown命令时，如果没有开启AOF持久化功能则自动执行bgsave）
  • save配置：
    save 900 1 #在900秒(15分钟)之后，如果至少有1个key发生变化，则dump内存快照。
    save 300 10 #在300秒(5分钟)之后，如果至少有10个key发生变化，则dump内存快照。
    save 60 10000 #在60秒(1分钟)之后，如果至少有10000个key发生变化，则dump内存快照。
  • rdb的优点：
    • RDB是一个紧凑压缩的二进制文件，代表Redis在某一个时间点上的数据快照。非常适合用于备份，全量复制等场景。比如每6小时执行bgsave备份，并把RDB文件拷贝到远程机器或者文件系统中（如hdfs），用于灾难恢复。
    • Redis加载RDB恢复数据远远快于AOF方式。
  • rdb的缺点：
    • RDB方式数据没办法做到实时持久化/秒级持久化。因为bgsave每次运行都要执行fork操作创建子进程，属于重量级操作，频繁执行成本过高。
    • RDB文件使用特定二进制格式保存，Redis版本演进过程中有多个格式的RDB版本，存在老版本Redis服务无法兼容新版RDB格式的问题。

• aof：以独立日志的方式记录每次写命令，重启时再重新执行AOF文件中命令达到恢复数据的目的。AOF的主要作用是解决了数据持久化的实时性，目前已经是Redis持久化的主流方式。

  • 由于aof文件可能会变得很大，提供了文件重写机制，分为自动重写和手动重写
  • aof配置：
    appendfsync always # 每次有数据修改发生时都会写入AOF文件。
    appendfsync everysec # 每秒钟同步一次，该策略为AOF的缺省策略。
    appendfsync no # 从不同步。高效但是数据不会被持久化。

• 此外，redis4.0还推出了混合持久化策略，解决了重启时使用aof恢复慢和rdb保存时效不高的问题，有兴趣的读者可以自行了解。