Redis持久化
redis是内存型数据库，不做持久化，一旦退出或断电，数据将会丢失
RDB (REDIS DATABASE)
在制定的时间的时间间隔内将内存中的数据集快照写入磁盘，也就是快照，它恢复时将快照文件直接读取到内存里。
redis会单独创建(fork)一个子进程来进行持久化，首先会将数据写到一个临时文件中，待持久化过程都结束了，再用这个临时文件替换上次持久化好的文件。整个过程是不需要进行任何IO操作的，这就确保了极高的性能。如果需要进行大规模数据的回复，且对于数据回复的完整性不是很敏感，那么RED方式要比AOF方式更加的高校。RDB的缺点是最后一次持久化后的数据可能丢失。我们默认的就是RDB，一般情况下不需要修改这个配置。
RDB默认保存的文件就是dump.rdb文件
默认的文件名可以在配置文件中进行配置
- 优点：
- 适合大规模数据恢复！
- 缺点：
- 需要一定的时间间隔操作！在这个时间间隔内redis宕机了，那么这部分数据会丢失！
- fork进程的时候，会消耗内存..
AOF（APPEND ONLY FILE）
将我们的所有命令都记录下来，恢复的时候将这个文件全部都在执行一遍
以日志的形式去记录每一个操作，将redis执行过的所有指令记录下来(读操作不记录), 只许追加文件但不可以改写文件，redis启动之初会读取该文件重新构建数据库。
在主从复制中，rdb就是一个备用的作用
AOB保存的是appendonly.aof文件
默认的文件名可以在配置文件中进行配置
如果aof的文件发生了错误，redis默认的策略是拒绝客户端连接，可以使用redis-check-aof来修复它
redis-check-aof --fix filename
重写规则
如果aof的文件大小配置文件中的大小，那么redis会fork一个新的进程来对文件进行重写
- 优点：
- 每一次修改都同步，文件的完整性会更好
- 每秒同步一次，数据可能会丢失
- 从不同步，效率最高
- 缺点：
- 相对数据文件来说，aof占用的磁盘空间会大于rdb的文件，修复的速度也相对较慢
- aof的运行效率也相对较慢
扩展
1、RDB持久化的方式能够在制定的时间间隔内对你的数据库进行快照存储
2、AOF持久化方式记录每次对服务器写的操作，当服务器重启的时候回重新执行这些命令来恢复原始的数据。aof命令以redis、协议追加保存每次写的操作到文件的末尾，redis还能对aof文件进行后台重写，使得aof文件的体积不至于过大。
3、只是用redis做缓存，可以不适用持久化操作
4、同时开启两种持久化方式
- 在这种情况下，当redis重启的时候回有限加载AOF文件来恢复数据，因为在通常情况下AOF文集你保存的数据集要比RDB文件保存的数据集要完整。
- RDB的数据不实时，同时使用两者时服务器重启也会找AOF文件，那要不要只是用aof呢？作者建议不要，因为RDB更适合用于备份数据库(AOF在不断变化不好备份)，快速重启，而且aof不会有潜在的bug，留作作为万一的手段。
5、性能建议
-
因为rdb文件中用于后备用途，建议只在slave上持久化rdb文件，而且只需要15分钟备份一次就够了，只保留900 1这条规则
-
如果enable aof，好处是在最恶劣的情况下丢失的不会超过2秒钟的数据，启动脚本较简单只load自己的aof文件就可以了，代价是有一定的io操作，而是aof的重写过程新数据到新文件的阻塞是不可避免的，只要硬盘容量允许，应该尽量减少rewrite的操作，aof的默认重写大小为60m，可以执行调整大小来避免重写的发生。
-
如果disable aof，仅靠主从复制实现高可用性也行，能省调一大笔io，也减少了重写的发生。代价是如果主节点和从节点同时倒掉，会丢失设置的同步的时间内的数据，启动脚本也要比较两个主从的edb文件，载入较新的那个。