RDB的弊端
解决思路
一、AOF的概念
二、AOF写数据的过程
客户端发出指令给服务端，服务端并没有马上记录，而是放到AOF写命令刷新缓存区，到一定时间之后将命令同步到AOF文件中。
AOF写数据三种策略
always(每次)
每次写入操作均同步到AOF文件中，数据零误差，性能较低，如果不是对数据非常严格不建议使用
everysec(每秒)
每秒将缓冲区中的指令同步到AOF文件中，数据准确性较高，性能较高，建议使用，也是默认配置。在系统突然宕机的情况下丢失1秒内的数据
no(系统控制)
由操作系统控制每次同步到AOF文件的周期，整体过程不可控
AOF功能开启
两个配置： appendonly yes|no #配置是否开启AOF持久化功能，默认为不开启状态 appendfsync always|everysec|no #AOF写数据策略
注意：数据如果有修改了才会写入.aof文件，只是查询（get）的话不会写入文件
AOF相关配置
两个配置： appendfilename filename #AOF持久化文件名，默认文件名为appendonly.aof,建议配置为appendonly-端口号.aof dir #AOF持久化文件保存路径，与RDB持久化文件保持一致即可
三、AOF写数据遇到的问题
AOF重写问题
AOF重写规则
四、AOF重写方式
手动重写 bgrewriteaof #在客户端输入
自动重写触发的条件设置 auto-aof-rewrite-min-size size #设置触发aof的最小尺寸 auto-aof-rewrite-percentage percent #达到重写的百分比 自动重写触发对比参数（运行指令info 在Persistence获取具体信息） aof_current_size aof_base_size
五、AOF重写流程
非重写流程（always/everysec）
重写流程
六、RDB与AOF的区别
RDB与AOF的选择
七、Redis持久化的总结
1.什么是持久化 2.RDB save bgsave 配置 3.AOF 持久化写策略（三种） 重写