Redis持久化
面试和工作中，持久化都是重点
redis是内存数据库，如果不将内存中的数据存储到磁盘中，断电就会丢失
RDB（默认情况下使用rdb）
在指定的时间间隔内将内存中的数据集快照写入磁盘，也就是Snapshot快照，它恢复时是将快照文件直接读到内存里。
Redis会单独创建（fork）一个子进程进行持久化，会将数据先写入到一个临时文件中，持久化结束就用这个临时文件替换上次持久化好的文件。整个过程主进程不进行任何IO操作。确保了极高的性能，如果需要大规模数据恢复，且对数据恢复的完整性不是非常敏感，那RDB比AOF更加高效。
RDB的缺点是最后一次持久化后的数据可能丢失
RDB保存的文件是 dump.rdb(都是在配置文件中配置的)、生产环境需要备份
触发机制
- save规则满足的情况下，会自动触发rdb规则
- 执行flushall命令，也会触发rdb规则
- 退出redis，也会产生rdb文件
备份会自动生成一个dump.rdb
如何恢复rdb文件
- 只需要将rdb文件放在redis启动目录就可以，redis启动的时候会自动检查dump.rdb 恢复其中的数据
优点：
- 适合大规模的数据恢复！dump.rdb
- 对数据完整性要求不高！
缺点：
- 需要一定的时间间隔进程操作！如果redis意外宕机了，最后一次修改数据就没有了
- 需要额外占用
AOF
将我们的所有命令都记录下来，恢复的时候把这个文件全部执行一遍
以日志的形式记录每个写操作，将Redis执行过程的所有指令记录下来（读操作不记录），只许追加文件，但不可以改写文件。redis启动之初会读取该文件重新构建数据。换言之，redis重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作
AOF保存的是 appendonly.aof 文件
默认是不开启的，需要我们手动进行配置！我们需要将 appendonly 改为yes就开启了aof
重启redis就生效了
如果aof文件有错误，这个时候redis是启动不起来的，可以使用redis提供的redis-check-aof工具修复aof文件，文件修复了redis就可以重启了
重写规则（了解即可）
aof默认就是文件的无限追加，文件会越来越大
如果aof文件大于64m，就太大了！会fork一个新的进程来将我们文件进行重写
优点：
- 默认每秒同步一次，可能会丢弃一秒的数据
- 可以设置每一次修改都同步，文件的完整性会更好
- 可以设置从不同步，效率最高
缺点：
- 相对于数据文件来说，aof大小远远大于rdb，修复速度也比rdb慢
- aof运行效率也比rdb慢，所以redis默认使用rdb持久化
扩展：
1、RDB 持久化方式能够在指定的时间间隔内对你的数据进行快照存储 2、AOF 持久化方式记录每次对服务器写的操作，当服务器重启的时候会重新执行这些命令来恢复原始的数据，AOF命令以Redis 协议追加保存每次写的操作到文件未尾，Redis还能对AOF文件进行后台重写，使得AOF文件的体积不至于过大。 3、只做缓存，如果你只希望你的数据在服务器运行的时候存在，你也可以不使用任何持久化 4、同时开启两种持久化方式
- 在这种情况下，当redis重启的时候会优先载入AOF文件来恢复原始的数据，因为在通常情况下AOF文件保存的数据集要比RDB文件保存的数据集要完整。
- RDB 的数据不实时，同时使用两者时服务器重启也,只会找AOF文件，那要不要只使用AOF呢?作者建议不要，因为RDB更适合用于备份数据库(AOF在不断变化不好备份)，快速重启，而且不会有AOF可能潜在的Bug，留着作为一个万一的手段。
5.性能建议
- 因为RDB文件只用作后备用途，建议只在Slave上持久化RDB文件，而且只要15分钟备份一次就够了，只保留 save 9001这条规则。
- 如果Enable AOF,好处是在最恶劣情况下也只会丢失不超过两秒数据,启动脚本较简单只load自己的AOF文件就可以了,代价一是带来了持续的10，二是AOF rewrite 的最后将 rewrite 过程中产生的新数据写到新文件造成的阻塞几乎是不可避免的。只要硬盘许可，应该尽量减少AOFrewrite 的频率，AOF重写的基础大小默认值64M太小了，可以设到5G以上，默认超过原大小100%大小重写可以改到适当的数值。
- 如果不Enable AOF,仅靠 Master-Slave Repllcation 实现高可用性也可以,能省掉一大笔10,也减少了rewrite时带来的系统波动。代价是如果Master/slave 同时倒掉,会丢失十几分钟的数据,启动脚本也要比较两个 Master/slave 中的 RDB文件，载入较新的那个，微博就是这种架构。
