Redis的持久化——RDB与AOF
RDB（Redis DataBase）快照形式
1、RDB是什么？
- 在指定的时间间隔内将内存中的数据集快照写入磁盘，也就是Snapshot快照，它恢复时是将快照文件直接读到内存里
- redis会单独创建一个子进程（fork）来进行持久化，会先将数据写入到一个临时文件中，待持久化过程都结束了，再用这个临时文件替换上次持久化好的文件
- 整个过程中，主进程是不进行任何IO操作的，这就确保了极高的性能，如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那RDB方式要比AOF方式更加的高效
- RDB的缺点是最后一次持久化后的数据可能丢失
2、Fork
- fork的作用是复制一个与当前进程一样的进程
- 新进程的所有数据数值都和原进程一致，但是是一个全新的进程，并作为原进程的子进程
3、RDB保存的是dump.rdb文件
4、配置策略
5、触发RDB
6、RDB的优点
- 适合大规模的数据恢复
- 对数据完整性和一致性要求不高
7、RDB的缺点
- 在一定间隔时间做一次备份，所以如果redis意外down掉的话，就会丢失最后一次快照后的所有修改
- fork的时候，内存中的数据被克隆一份，大致2倍的膨胀性需要考虑
8、动态停止RDB
-
在redis-cli命令行中，输入congfig set save""
[root@node01 redis-3.0.4]# redis-cli config set save "" OK
AOF（AppendOnly File）日志形式
1、AOF是什么？
- 以日志的形式来记录每个写操作，将redis执行过的所有写指令记录下来（读操作不记录），只许追加文件不可以改写文件
- redis启动之初会读取该文件重新构建数据，换言之，redis重启的话，就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作
2、AOF保存的是appendonly.aof文件
3、配置策略
4、触发AOF
- 修改配置文件的appendonly为yes
5、AOF的数据修复
-
redis-check-aof --fix appendonly.aof
[root@node01 redis-3.0.4]# redis-check-aof --fix appendonly.aof
6、AOF的优点
- 同步持久化每次发生数据变更会被立即记录到磁盘
- 性能较差但数据完整性比较好
7、AOF的缺点
- 相同数据集的数据而言aof文件要远大于rdb文件，恢复速度慢于rdb
总结
- Redis 默认开启RDB持久化方式，在指定的时间间隔内，执行指定次数的写操作，则将内存中的数据写入到磁盘中。
- RDB 持久化适合大规模的数据恢复但它的数据一致性和完整性较差。
- Redis 需要手动开启AOF持久化方式，默认是每秒将写操作日志追加到AOF文件中。
- AOF 的数据完整性比RDB高，但记录内容多了，会影响数据恢复的效率。
- Redis 针对 AOF文件大的问题，提供重写的瘦身机制。
- 若只打算用Redis 做缓存，可以关闭持久化。
- 若打算使用Redis 的持久化。建议RDB和AOF都开启。其实RDB更适合做数据的备份，留一后手。AOF出问题了，还有RDB。