RDB与AOF

rdb

save 900 1
save 300 10
save 60 10000

rdb默认配置

当 900 秒执行 1 个写命令时，启用快照备份。
当 300 秒执行 10 个写命令时，启用快照备份。
当 60 秒内执行 10000 个写命令时，启用快照备份。

触发RDB快照

1 在指定的时间间隔内，执行指定次数的写操作
2 执行save（阻塞， 只管保存快照，其他的等待）
3 bgsave （异步）命令
4 执行flushall 命令，清空数据库所有数据，意义不大。
5 执行shutdown 命令，保证服务器正常关闭且不丢失任何数据，意义不大。



第一种就是根据上面说的在配置文件中的配置触发快照的时间与次数的写操作
第二种是使用save命令，但是我们要设置在使用该命令时，将禁止写入命令。
   需要配置stop-writes-on-bgsave-error yes
第三种 bgsave 命令
   它是一个异步保存命令，也就是系统将启动另外一条进程，
   把 Redis 的数据保存到对应的数据文件中。它和 save 命令最大的不同是它不会阻塞客户
   端的写入，也就是在执行 bgsave 的时候，允许客户端继续读/写 Redis

通过RDB文件恢复数据

将dump.rdb 文件拷贝到redis的安装目录的bin目录下，重启redis服务即可。
在实际开发中，一般会考虑到物理机硬盘损坏情况，选择备份dump.rdb     

RDB 的优缺点

优点：
1 适合大规模的数据恢复。
2 如果业务对数据完整性和一致性要求不高，RDB是很好的选择。

缺点：
1 数据的完整性和一致性不高，因为RDB可能在最后一次备份时宕机了。
2 备份时占用内存，因为Redis 在备份时会独立创建一个子进程，将数据写入到一个临时文件
（此时内存中的数据是原来的两倍哦），最后再将临时文件替换之前的备份文件


所以Redis 的持久化和数据的恢复要选择在夜深人静的时候执行是比较合理的

AOF

Redis 默认不开启。它的出现是为了弥补RDB的不足（数据的不一致性），
所以它采用日志的形式来记录每个写操作，并追加到文件中。Redis 重启的会根据日志文件的
内容将写指令从前到后执行一次以完成数据的恢复工作

redis 默认关闭，开启需要手动把no改为yes   
  appendonly yes
指定本地数据库文件名，默认值为 appendonly.aof
  appendfilename "appendonly.aof"

指定更新日志条件
   # appendfsync always
     appendfsync everysec
   # appendfsync no

always：同步持久化，每次发生数据变化会立刻写入到磁盘中。
        性能较差当数据完整性比较好（慢，安全）
everysec：出厂默认推荐，每秒异步记录一次（默认值）
no：不同步

配置重写触发机制

auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发。
一般都设置为3G，64M太小了。

根据AOF文件恢复数据

正常情况下，将appendonly.aof 文件拷贝到redis的安装目录的bin目录下，
重启redis服务即可。但在实际开发中，可能因为某些原因导致appendonly.aof 文件格式异
常，从而导致数据还原失败，可以通过命令redis-check-aof --fix appendonly.aof 进行
修复

AOF的重写机制

前面也说到了，AOF的工作原理是将写操作追加到文件中，文件的冗余内容会越来越多。
所以聪明的 Redis 新增了重写机制。当AOF文件的大小超过所设定的阈值时，
Redis就会对AOF文件的内容压缩。

重写的原理：Redis 会fork出一条新进程，读取内存中的数据，并重新写到一个临时文件中。
并没有读取旧文件

触发机制：当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发。
 这里的“一倍”和“64M” 可以通过配置文件修改。

AOF 的优缺点

优点：数据的完整性和一致性更高
缺点：因为AOF记录的内容多，文件会越来越大，数据恢复也会越来越慢。