本节内容：
1 RDB，
2 AOF
3 AOF重写
4 RDB和AOF总结
内存当中的数据，如果一断电，数据就会丢失，所以需要持久化。
redis提供了两种方式进行持久化。
一种是RDB持久化默认，
另一种是AOF(append only file) 持久化。
1RDB
原理：redis会单独创建（调用fork函数)一个与当前进程一模一样的子进程进行持久化，这个子进程的所有数据（变量，环境变量，程序计数器等）都和原进程一模一样，先将数据写入一个临时文件中，待持久化结束了，再用这个临时文件替换上次持久化好的文件，整个过程中，主进程不进行任何io操作，这就确保了极高的性能。
这个持久化文件在哪里？
redis.conf中有设置，默认是当前文件夹的dump.rdb中
它什么时候fork子进程，或者什么时候触发rdb持久化机制。
shutdown时如果没有开启aof，会触发。
配置文件中默认的快照配置
执行命令save或者bgsave save只管保存，其他不管，全部阻塞 bgsave：redis会在后台异步进行快照操作，同时可以响应客户端的请求，
执行flushall命令，但是里面是空的，无意义。
2 AOF持久化
原理是将redis操作日志以追加的方式写入文件，读操作不记录。
就是记录命令，然后重新执行一遍。
持久化文件在哪里？
在redis.conf中appendfilename “appendonly.aof”文件中。
appendonly no ,aof默认是关闭的，可以改为yes开启。
修改配置文件后需要重启redis,不然配置不会生效。
文件在redis-server所在的文件夹里。
shutdown
exit
redis-server
触发机制：
在redis.conf中
append
appendfsync everysec
append
**no千万不能配置。**表示等操作系统进行数据缓存同步到磁盘(快，持久化没保证）
always：同步持久化，每次发生数据变更时，立即记录到磁盘（慢，安全）
（redis特别快，这种消耗电脑性能。）
everysec: 表示每秒同步一次（默认值，很快，但可能会丢失一秒内的数据）
打开appendonly.aof,使用vim
*2 星号开头表示下面有两条命令，
select 0 是放在零号库里
set
kk
vv就是把命令存储在数据库中了。
补充：
哨兵模式
客机变主机的自动模式，选举制度。
后台监控主机是否故障，如果故障了，根据投票数自动将从库转换为主库。
3 aof重写机制
为什么需要重写？
aof过很久就会增长很大，就需要重写机制，
而且默认所有命令都存比如set k1 v1,设置重写机制后就会存储为二进制文件，比较省空间。
当AOF文件增长到一定大小的时候redis能够调用bgrewriteaof对日志文件进行重写，当AOF文件大小的增长率大于该配置项时自动开启重写（超过原大小的100%） 就是设置20M，然后到40M，就会触发。100是百分比，还有80的话，20M，到36M就会触发重写
auto-aof-rewrite-percentage 100
当AOF文件增长到一定大小的时候，redis能够调用bgrewriteaof对日志进行重写， 当AOF文件大小大于该配置项时自动开启重写。
auto-aof-rewrite-min-size 64mb
(实际生产中这里设置为3G-5G）
4RDB和AOF总结
1.redis提供了rdb持久化方案，为什么还要aof?
优化数据丢失问题，rdb会丢失最后一次快照后的数据，aof不会丢失超过2秒的数据。
2 如果RDB和aof同时存在，听谁的？
aof，比rdb数据准确性更高
3 rdb和aof优势劣势？
rdb适合大规模的数据恢复，对数据完整性和一致性不高，在一定间隔时间做一次备份，如果丢失的话，就会丢失最后一次快照后的所有操作。
aof根据配置项而定。
官方建议：两种持久化方式同时开启，如果两个同时开启，优先使用aof持久化机制。
性能建议：
因为RDB只用做后备用途，只要15分钟备份一次，只保留save 900 1 这条规则
如果Enalbe AOF,好处是最恶劣环境下，也只会丢失不超过2秒数据，启动脚本较简单，只load自己的AOF文件就可以了。
代价一是带来了持续的IO，二是SOFrewrite的最后将rewrite过程中产生的新数据写到新文件造成的阻塞几乎是不可避免的。
只要硬盘许可，应尽量减少AOF rewrite的频率，AOF重写的基础大小默认值64M太小了，可以设到5G以上。
如果有aof文件，就加载aof文件，启动成功，或者启动失败，
有rdb文件，加载rdb文件，启动成功，
如果不存在rdb文件，也能启动成功，就是没有数据。
