Redis的两种持久化策略

Redis一共有2种持久化策略，分别是

    RDB：Redis DataBase

    AOF：Append Only File

RDB

  默认情况下，是快照rdb的持久化方式，将内存中的数据以快照的方式写入二进制文
  件中，默认的文件名dump.rdb

  RDB持久化是指在指定的时间间隔内将内存中的数据集快照写入磁盘，
  写入成功后，再替换之前的文件，用二进制压缩存储。

RDB持久化配置

  save 900 1              15分钟内至少有1个key被修改

  save 300 10            5分钟内至少有0个key被修改

  save 60 10000        1分钟内至少有100000个key被修改

以上三种默认配置，触发条件之后，redis就会生成快照，将内存中的数据写入到dump.rdb文件中

注意：执行save，FlushDB，FlushAll，Shutdown 命令之后，会立即生成快照，自动备份

RBD文件修复命令：redis-check-dump –fix dump.rdb

RDB的优缺点

优点：

由于存储的有数据快照文件，恢复数据很方便。

相比于AOF机制，如果数据集很大，RDB的启动效率会更高

性能最大化。对于Redis的服务进程而言，在开始持久化时，
之后再由子进程完成这些持久化的工作，
这样就可以极大的避免服务进程执行IO操作了

缺点：

会丢失最后一次快照以后更改的所有数据。
因此，如果当数据集较大时，
可能会导致整个服务器停止服务几百毫秒，甚至是1秒钟。

AOF

    AOF持久化以日志的形式记录服务器所处理的每一个写、删除操作，
    查询操作不会记录，以文本的方式记录，可以打开文件看到详细的操作记录。

开启方法：

    只需要在redis.conf中，将appendonly 设置为 yes，即可开启AOF持久化

AOF持久化配置
在Redis的配置文件中存在三种同步方式，它们分别是：

  appendfsync always     #每次有数据修改发生时都会写入AOF文件。

  appendfsync everysec  #每秒钟同步一次，该策略为AOF的缺省策略。（推荐策略）

  appendfsync no          #从不同步。高效但是数据不会被持久化。

AOF文件重写

   auto-aof-rewrite-percentage 100：默认超过当前配置重写容量100%（当前为64M），则进行重写

   auto-aof-rewrite-min-size 64mb：默认存储64M

AOF文件修复命令：redis-check-aof –fix appendonly.aof
AOF的优缺点

优点：

Redis中AOF默认同步策略是每秒同步一次，所以丢失数据小，数据一致性高

缺点：

数据量相同的情况下，AOF恢复数据的速度要低于RDB
总之，每秒同步策略的效率是比较高的，同步禁用策略的效率和RDB一样高效。

二者选择的标准，就是看系统是愿意牺牲一些性能，换取更高的缓存一致性（aof），还是愿意写操作频繁的时候，不启用备份来换取更高的性能，待手动运行save的时候，再做备份（rdb）。rdb这个就更有些 eventually consistent的意思了。

数据恢复

    将备份的dump.rdb或者appendonly.aof文件拷贝到redis.conf文件同级目录下，
    重新启动redis服务，即可恢复数据

注意：当redis启动时，如果rdb持久化和aof持久化都打开了，那么程序会优先使用aof方式来恢复数据集，因为aof方式所保存的数据通常是最完整的。如果aof文件丢失了，则启动之后数据库内容为空。

注意：如果想把正在运行的redis数据库，从RDB切换到AOF，建议先使用动态切换方式，再修改配置文件，重启数据库。(不能直接修改配置文件，重启数据库，否则数据库中数据就为空了