redis学习笔记---redis的持久化（RDB和AOF方式）

  redis支持两种持久化的方式，能够单独使用或者结合起来使用

     第一种：RDB方式（redis默认的持久化方式）

 第二种：AOF方式

     1、RDB

     rdb方式的持久化是经过快照完成的，当符合必定条件时redis会自动将内存中的全部数据执行快照操做并存储到硬盘上。默认存储在redis根目录的dump.rdb文件中。(文件名在配置文件中dbfilename)

redis进行快照的时机（在配置文件redis.conf中）

save 900 1：表示900秒内至少一个键被更改则进行快照。

save 300 10

save 60 10000

redis自动实现快照的过程

    1：redis使用fork函数复制一份当前进程的副本(子进程)

 2：父进程继续接收并处理客户端发来的命令，而子进程开始将内存中的数据写入硬盘中的临时文件

 3：当子进程写入完全部数据后会用该临时文件替换旧的RDB文件，至此，一次快照操做完成。  

 注意：redis在进行快照的过程当中不会修改RDB文件，只有快照结束后才会将旧的文件替换成新的，也就是说任什么时候候RDB文件都是完整的。 这就使得咱们能够经过定时备份RDB文件来实现redis数据库的备份， RDB文件是通过压缩的二进制文件，占用的空间会小于内存中的数据，更加利于传输。

手动执行save或者bgsave命令让redis执行快照。

两个命令的区别在于，save是由主进程进行快照操做，会阻塞其它请求。bgsave是由redis执行fork函数复制出一个子进程来进行快照操做。

文件修复：redis-check-dump

rdb的优缺点

优势：因为存储的有数据快照文件，恢复数据很方便。

缺点：会丢失最后一次快照之后更改的全部数据。

2、AOF

     aof方式的持久化是经过日志文件的方式。默认状况下redis没有开启aof，能够经过参数appendonly参数开启。

  appendonly yes

 aof文件的保存位置和rdb文件的位置相同，都是dir参数设置的，默认的文件名是appendonly.aof，能够经过      appendfilename参数修改

   appendfilename appendonly.aof

 redis写命令同步的时机

 a ppendfsync always 每次都会执行

 appendfsync everysec 默认 每秒执行一次同步操做（推荐，默认）

 appendfsync no不主动进行同步，由操做系统来作，30秒一次

  aof日志文件重写

 auto-aof-rewrite-percentage 100(当目前aof文件大小超过上一次重写时的aof文件大小的百分之多少时会再次进行重写，若是以前没有重写，则以启动时的aof文件大小为依据)

 auto-aof-rewrite-min-size 64mb

  手动执行bgrewriteaof进行重写

 重写的过程只和内存中的数据有关，和以前的aof文件无关。 所谓的“重写”实际上是一个有歧义的词语， 实际上， AOF 重写并不须要对原有的 AOF 文件进行任何写入和读取， 它针对的是数据库中键的当前值。

  文件修复：redis-check-aof

     动态切换redis持久方式，从 RDB 切换到 AOF（支持Redis 2.2及以上）

    CONFIG SET appendonly yes
    CONFIG SET save ""（可选）
     注意：当redis启动时，若是rdb持久化和aof持久化都打开了，那么程序会优先使用aof方式来恢复数据集，由于aof方式所保存的数据一般是最完整的。若是aof文件丢失了，则启动以后数据库内容为空。

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