Redis持久化之AOF

简析RBD的缺陷：

①RDB是存储某个时间点的数据状态，用的是快照的方式，不管是使用命令还是设置配置都无法满足实时持久化的需求，很有可能造成数据的丢失

②RDB持久化需要调用fork函数生成子进程去进行持久化会造成性能上的损失

解决思路：

①不记录全部数据，仅记录部分数据

②改记录数据变成记录操作

③对所有操作记录，排除数据的丢失

所以Redis推出了AOF机制：改记录数据为记录操作

AOF作用：实时持久化数据

目前已经成为Redis持久化的主流方式

AOF写数据的过程：

 AOF写数据的三种策略

①always(每次)

       每次写入操作均同步到aof文件中，数据零误差，性能较低

②everysec(每秒)

        每秒将缓存中的指令同步到AOF文件中，数据准确性较高，性能较高

        在系统宕机的情况下只丢失1s的数据

③no(系统控制)

        由操作系统控制每次同步到AOF文件的周期，整体过程不可控

AOF功能的开启：

·配置

appendonly yes

作用：是否开启AOF持久化，默认不开启

·配置

appendfsync always|everysec|no

作用：AOF写数据的策略

AOF相关配置：

·配置

appendfilename filename

作用：AOF持久化文件名，默认appendonly.aof，建议appendonly-端口号.aof

·配置

dir

作用：AOF持久化文件路径与RDB持久化文件路径一致

 

 我将AOF持久化策略设置为always，可以看到每次操作都会记录到aof文件中

 

 如果执行set sno 183206207 再执行 set sno 183206227，这样看显然第一次的操作记录是累赘的，有没有办法就是只记录最后一次的操作，肯定有，如果没有的话，aof记录的操作将会很庞大。接下来就是我要介绍的AOF重写，

AOF重写

什么是AOF重写：简单点说就是对同一个数据的进行的若干操作将最后的结果转换为操作指令

AOF重写的好处：

①提高磁盘的利用率

②提高持久化的效率

③提高数据恢复的效率

AOF的重写策略：

①进程中已经过期的数据不再写入文件中

②忽略无效指令，生成最终数据的操作指令

③对同一条数据的若干操作指令进行一个合并

说明：为了防止客户端缓冲区溢出，对list、set、hash、zset等类型，每条指令最多写入64个元素

AOF重写方式：

①手动重写

bgrewriteaof

②自动重写

·自动重写触发条件设置

auto-aof-rewrite-min-size size
auto-aof-rewrite-percentage percentage

 ·自动重写触发比对参数(运行指令info Persistence获取具体信息)

aof_current_size
aof_base_size

·自动重写触发条件 

aof_current_size>auto-aof-rewrite-min-size

(aof_current_size-aof_base_size)/aof_base_size >= auto-aof-rewrite-percentage

 aof手动重写的执行流程：

 aof工作流程：

 

 

 RBD与AOF的对比：

持久化方式	RDB	AOF
占用存储空间	小	大
存储速度	慢	快
恢复速度	快	慢
数据安全	会丢失数据	依据策略决定
资源消耗	高	低
启动优先级	低	高