redis-redis的持久化

 1.什么是持久化：

       持久化就是将内存中的数据写入到磁盘中

 2.redis持久化的方式

redis持久化有两种。rdb和aof

3.rdb

• RDB介绍：

1. 在指定的时间内将内存中的数据持久化到磁盘中，（行内的话就是说将数据snapshot快照数据）。如果该redis重新启动了就可以从这个这快照中依次读取数据。
2. 默认生成的路径是在启动redis服务的目录下，生成的文件是 dump.rdb的文件
3. 当redis中的数据到达了触发持久化的条件时，redis就会就会 fork出一个子进程来进行持久化，会将内存中的数据复制序列化到一个临时文件中等到所有的数据都序列化完成后就会使用这个临时文件代替上一次生成的文件数据。
4.  

• 如何触发RDB快照

1. 配置文件中默认的快照配置（冷拷贝后重新使用：可以cp dump.rdb dump_new.rdb）save 900 1 or save 300 10 or save 60 10000
2. 使用命令save ：save时只管保存，其它不管，全部阻塞；
3. bgsave：Redis会在后台异步进行快照操作，快照同时还可以响应客户端请求。可以通过lastsave命令获取最后一次成功执行快照的时间；
4. 执行flushall命令，也会产生dump.rdb文件，但里面是空的，无意义；

• 如何恢复

1. 将备份文件 (dump.rdb) 移动到 redis 安装目录并启动服务即可，通过config get dir可获取目录；注意：这里SHUTDOWN都会生成dump.rdb，如果内存中没有数据，这时会覆盖之前生成的文件。所有要非常的注意
2. 如何停止
   动态所有停止RDB保存规则的方法：redis-cli config set save ""；
3. 优势
4. 适合大规模的数据恢复；
5. 对数据完整性和一致性要求不高；
6. 劣势
7. 在一定间隔时间做一次备份，所以如果redis意外宕掉的话，就会丢失最后一次快照后的所有修改；
8. fork的时候，内存中的数据被克隆了一份，大致2倍的膨胀性需要考虑；

 

4.aof (Append Only File)

1.aof介绍：

          redis只会一追加的方式来记入日志，将redis执行的过程都记录下来（读操作不记录），只允许追加文件，不能修改文件。redis启动的时候会将日志文件中的数据依次读取来恢复数据。换言之，redis重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作（AOF保存的是appendonly.aof文件）；

2.aof的启动/修复/恢复

1. 正常恢复
   启动：修改默认的appendonly no，改为yes；
   将有数据的aof文件复制一份保存到对应目录(目录通过config get dir命令获取)；
   恢复：重启redis然后重新加载；
2. 异常恢复
   启动：修改默认的appendonly no，改为yes；
   备份被破坏的aof文件；
   修复：使用redis-check-aof --fix命令进行修复；
   恢复：重启redis然后重新加载；
3. 如果aof文件损坏时，重启redis时会失败。因为要从aof文件中恢复数据

         aof文件修复命令

redis-check-aof --fix appendonly.aof

• 优势
  每修改同步：appendfsync always 同步持久化，每次发生数据变更会被立即记录到磁盘 性能较差但数据完整性比较好；
  每秒同步：appendfsync everysec 异步操作，每秒记录，如果一秒内宕机，有数据丢失；
  不同步：appendfsync no 从不同步；
• 劣势

1. 相同数据集的数据而言aof文件要远大于rdb文件，恢复速度慢于rdb；
2. aof运行效率要慢于rdb,每秒同步策略效率较好，不同步效率和rdb相同；

 

• rewrite

1. rewrite介绍
   AOF采用文件追加方式，文件会越来越大为避免出现此种情况，新增了重写机制，当AOF文件的大小超过所设定的阈值时，Redis就会启动AOF文件的内容压缩，只保留可以恢复数据的最小指令集.可以使用命令bgrewriteaof；
2. 重写原理
   AOF文件持续增长而过大时，会fork出一条新进程来将文件重写(也是先写临时文件最后再rename)，遍历新进程的内存中数据，每条记录有一条的Set语句。重写aof文件的操作，并没有读取旧的aof文件，而是将整个内存中的数据库内容用命令的方式重写了一个新的aof文件，这点和快照有点类似；
3. 触发机制
   Redis会记录上次重写时的AOF大小，默认配置是当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发；（这是redis的一种优化手段，如果用的好的公司一般都在5G左右）

 

总结：

1.  rdb和aof都是redis数据持久化的两种方式
2. rdb  默认生成的文件名称为：dump.rdb
   有效触发条件。当有数据操作满15分钟或者300秒操作超过15或者1分钟操作超过了10000次就会触发保存机制。命令 sava  bgsave 可以手动的触发数据保存。
   无效的保存。当手动的FLUSHALL 和exit的时候就会 生成空的dump.rdb文件。所以在此操作的时候一定要保存备份数据。
   原理：会fork一个子进程将数据写到一个临时的文件，当数据完全的写入到文件中时，临时文件将会代替之前生成的文件。
   优势：     
        1.适合大规模的数据恢复
        2.对数据实时性没那么高的时候
   劣势：
        1.如果发生了宕机的时候会发生数据丢失。如果对数据的实时性有要求的时候，不适合。
        2.发生了fork的时候，会拷贝一份数据，将会影响到服务器的性能。  
3. aof:默认生成的文件名为：appendonly.aof
   原理：日志追加的方式来记录redis写的操作不记录读的操作
   修改配置文件的参数 appendonly yes 开启日志追加模式。
   追加的方式：appendfsync on 不开启\appendfsync always 总是追加，不会发生数据丢失\appendfsync everysec 每秒追加。会发生一秒的数据丢失。
   优势：
         1.备份数据时如果发生数据丢失，只是秒级数据丢失。
         2.如果同时存在rdb和aof文件时，系统默认加载aof日志文件
   劣势：
       相同数据集的数据而言aof文件要远大于rdb文件，恢复速度慢于rdb；
       aof运行效率要慢于rdb,每秒同步策略效率较好，不同步效率和rdb相同；