Redis学习03：Redis数据持久化
Redis数据持久化
官网介绍：https://redis.io/topics/persistence
归纳说，就是分RDB和AOF
RDB介绍
1-官网介绍：https://redis.io/topics/persistence
2-RDB：在指定的时间间隔内将内存中的数据快照写入磁盘；也就是行话讲的Snapshot快照，它恢复时是将快照文件直接读取到内存。Redis会单独创建(fork)一个子进程来进行持久化，会先将数据写入到一个临时文件中，待持久化过程都结束了，在用这个临时文件替换上次持久化好的文件。整个过程中，主进程是不进行任何IO操作的，这就确保了极高的性能，如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那么RDB方式要比AOF方式更加的高效。RDB的缺点是最后一次持久化后的数据可能丢失。
3-Fork：Fork的作用是复制一个与当前进程一样的进程。新进程的所有进程(变量、环境变量、程序计数器等)数值都喝原进程一致，但是hi一个全新的进程，并作为原进程的子进程尽兴。
4-dump.rdb文件：dump.rdb是默认的RDB持久化文件，命名可以在redis.conf中进行配置
5-RDB配置位置：在redis.conf中进行配置
6-如何触发RDB快照
方法1：配置文件中默认的快照配置：比如，配置文件中设置了 save 300 10，就表示如果在300秒内至少有10个key发生变化，则数据持久化到dump.rdb文件
方法2：使用save或bgsave命令：其中save时只管保存，其他不管，全部阻塞；bgsave时，redis后台在异步进行快照操作，同时还可以响应客户端请求。
方法3：使用flushall命令：也会产生dump.rdb，但里面是空的，没有意义；同时，shutdown也可以触发快照
7-如何恢复：将备份文件(dump.rdb)移动到redis安装目录下，并启动服务即可(指令config get dir获取目录)
8-RDB优势：适合大规模的且对数据完整性和一致性要求不高的数据进行恢复；
9-RDB劣势：在一定间隔时间做一次备份，所以如果redis意外down掉时，就会丢失最后一次快照后的所有修改。Fork时，内存数据被克隆一份，大致2倍的膨胀性需要考虑
10-如何停止RDB：动态停止RDB保存规则：redis-cli config set save ''
AOF介绍
1-官网介绍：https://redis.io/topics/persistence
2-AOF: 以日志的形式来记录每个写操作；将Redis执行过的所有写指令记录下来(读操作不记录)，只许追加文件但不可以改写文件，Redis启动之初会读取改文件重新构建数据，换言之，Redis重启的话就根据日志文件的内容将写指令指令从前到后执行一次以玩成数据的回复工作；
3-AOF保存的是appendonly.aof文件
4-配置文件位置
5-AOF启动/修复/恢复
1-启动：在redis.conf配置文件中设置appendonly 为yes，再重新启动redis即可；
2-正常恢复：重新启动redis就是自动重新加载
3-异常修复：先备份被写坏的AOF文件，然后再Linux命令行执行redis-check-aof -fix appendonly.aof;最后重启redeis即可
6-AOF Rewrite
7-AOF 优势
1-每修改同步：appendfsync always ； 同步持久化，性能较差但数据完整性比较好
2-每秒同步：appendfsync everysec ； 异步操作，每秒记录，如果一秒内宕机，有数据丢失
3-不同步：appendfsync no 从不同步
8-AOF 劣势
1-相同数据集的数据而言AOF文件要远大于RDB文件，恢复速度慢于RDB
2-AOF运行效率要慢于RDB，每秒同步策略效率较好，不同步效率和RDB相同
总结
- Redis 默认开启RDB持久化方式，在指定的时间间隔内，执行指定次数的写操作，则将内存中的数据写入到磁盘中。
- RDB 持久化适合大规模的数据恢复但它的数据一致性和完整性较差。
- Redis 需要手动开启AOF持久化方式，默认是每秒将写操作日志追加到AOF文件中。
- AOF 的数据完整性比RDB高，但记录内容多了，会影响数据恢复的效率。
- Redis 针对 AOF文件大的问题，提供重写的瘦身机制。
- 若只打算用Redis 做缓存，可以关闭持久化。
- 若打算使用Redis 的持久化。建议RDB和AOF都开启。其实RDB更适合做数据的备份，留一后手。AOF出问题了，还有RDB。