redis 两种持久化策略

1.rdb 

   redis默认是会已快照的形式将数据持久化到硬盘中（文件名 dump.rdb,文件名可以指定）

   可以在redis.conf 做如下配置

   save 200 1 （如果在200秒内有1次修改发起快照）

   svae 200 10 （如果在200秒内有10次修改发起快照）

   save 60 100 （如果在60秒内有100次修改发起快照）

   优点：

       1.rdb保存了某个时间点的数据，这种文件合适于备份，出现问题可以随时还原到不同的版本

       2.rdb可以最大化redis的性能，父进程在保存rdb文件时只要fork出一个子进程，子进程就可以处理接下来的保存工作，父进程无须任何的磁盘io操作

       3.rdb在恢复数据是比aof方式要快

  缺点：

      1.如果要避免数据丢失，rdb不合适你，因为至少你在几分钟之内才保存一次rdb文件，这种情况下。这几分钟的数据将就丢失了

      2.保存rdb时候fock的子进程，在数据庞大时会比较耗时。

2.aof

   配置:

   appendfsync always #每次有数据修改发生时都会写aof （效率低，安全性高）

   appendfsync everysec #每秒钟同步一次，默认的策略

   appendfsync no #redis并不直接调用文件同步，而是交给操作系统来处理，操作系统可以根据buffer填充情况/通道空闲时间等择机触发同步；这是一种普通的文件操作方式。性能较好，在物理服务器故障时，数据丢失量会因OS配置有关。

   优点：

1.aof默认策略为每秒同步一次，这种策略下面可以保持良好的性能，发生故障也只有丢失1秒的数据

2.aof文件是一个只进行追加操作的日志文件，对aof文件不需要seek

3.aof文件有序保存了对数据库执行的所有写操作，这些写操作以redis协议保存，所以内容容易被人读懂

对文件分析也很轻松，如果不小心执行了flushall命令，只要在aof文件的没有被重新，关闭redis服务器在aof文件的末端删除flunshall命令重启redis服务器，数据就可以恢复到flunshall之前的状态

 缺点：

1.相同数据来说，aof文件的体积要大于rdb文件的体积

2.根据所使用的 fsync 策略，AOF 的速度可能会慢于 RDB 。 在一般情况下， 每秒 fsync 的性能依然非常高， 而关闭 fsync 可以让 AOF 的速度和 RDB 一样快， 即使在高负荷之下也是如此。 不过在处理巨大的写入载入时，RDB 可以提供更有保证的最大延迟时间（latency）

最后：

当 Redis 启动时， 如果 RDB 持久化和 AOF 持久化都被打开了， 那么程序会优先使用 AOF 文件来恢复数据集， 因为 AOF 文件所保存的数据通常是最完整的。