redis的持久化操作2 AOF

一、AOF是什么

AOF（Append Only File）是继RDB之后产生，为了解决RDB容易丢失最后一次快照的问题，就产生了AOF技术。AOF就是以日志的形式记录下redis所有的写操作（不记录读操作），只允许在日志文件后面追加内容，不允许进行修改，redis的启动之初就会读取该文件，并从头到尾执行一次，以完成数据的恢复。

 

二、AOF的配置信息

appendonly：AOF默认是no，设置为yes启动AOF技术

appendfilename：AOF的日志文件名（不建议更改）

appendfsysnc：AOF的保存策略，

1.always：同步持久化，每进行写操作时，立即记录到磁盘中

2.everysec：异步操作，每秒进行一次日志保存，如果在一秒钟之内

redis进程挂掉，那么会丢失数据

3.NO：不进行持久化操作

auto-aof-rewrite-percentage：AOF文件的大小超过上一次文件的多少百分比进行rewrite

auto-aof-rewrite-min-size：AOF文件大小超过多少时，进行rewrite。

（上面两项配置需要同时满足时才会进行rewrite）

no-appendfsync-on-rewrite：redis在进行rewrite时是否可以用appendfsysnc的策略，默认使用no，保证日志文件的安全性。

 

三、AOF与RDB能否共存？（以及AOF日志文件修复）

可以共存，但是redis会优先去读取AOF的日志文件，如果AOF的日志文件出错，那么redis就会启动失败，可以先将出错的AOF日志文件进行备份然后使用redis-check-aof-fix进行修复。（什么时候AOF日志文件会出错？如果AOF在写日志文件写了一半时，redis突然宕了，那么AOF日志文件就会出现错误的语句）

 

四、AOF的Rewrite机制

因为AOF的日志文件采用的是追加的方式，所以不可避免的日志文件会越来越大，为了避免这样的情况，AOF就采用了rewirite（重写）机制，当AOF文件的大小超过了设定的阈值，那么redis就会启动AOF的内容压缩，只保留可以恢复数据的最小指令集。

重写的原理：当AOF的文件超过阈值时，就会fork一个新的进程来对AOF文件进行内容的压缩。

 

五、AOF如何恢复数据

首先需要启动AOF服务，在配置文件中设置appendonly为yes。

将有保存数据的AOF文件复制一份到相应的目录下，重新启动redis服务，恢复数据

如果是因为异常关闭，需要使用redis-check-aof-fix修复AOF文件，再继续操作。

 

六、AOF的优势与劣势

优势：灵活（有多种的同步策略）、数据的完整性比RDB强（每秒，或者每个操作就进行一次同步）

劣势：相同的数据集下，AOF的文件会远比RDB大（因为AOF需要保存每次的写操作）

AOF的运行效率会比RDB慢（AOF需要依次执行每一条写操作）

 

 

五、RDB和AOF使用总结

RDB持久化能在指定的时间间隔对数据进行快照存储

AOF持久化能记录每次对服务器的写操作，通过重复执行写操作来恢复数据

如果只想让redis进行缓存服务，那么可以不开启RDB与AOF持久化服务

如果需要，官方建议同时开启两种持久化方式，其中主要使用AOF来进行数据的恢复，RDB作为一个备用的手段，因为AOF在不断的变化，不好备份，而且可以防止AOF出现了什么BUG导致数据的丢失。

关于性能方面的配置：