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
持久化写策略（三种）
重写