小知识，大挑战！本文正在参与“程序员必备小知识”创作活动。
上边的文章中我们已经把 RDB 的持久化方式讲完了，本文我们先来说一下 AOF 持久化的配置相关的内容。
AOF
为了解决RDB方式在宕机时丢失数据过多的问题，从1.1 版本开始，Redis增加了一种durable的持久化方式：AOF。
AOF是Append Only File的缩写，默认不开启。AOF以日志的形式来记录每个写操作，只允许追加文件但不可以改写文件，当服务器重启的时候会重新执行这些命令来恢复原始的数据。
我们再来看一下配置文件中的APPEND ONLY MODE:
配置文件
appendonly no
默认为关闭状态，改为yes打开持久化。AOF和RDB可以同时启用而不会出现问题。
appendfilename "appendonly.aof"
文件默认名称，启动即创建。加载先于dump.rdb文件
appendfsync
同步策略：系统函数fsync() 告诉操作系统在磁盘上实际写入数据。Redis支持三种不同的模式
appendfsync always //每次发生数据变更会被立即记录到磁盘，性能较差但数据完整性比较好
appendfsync everysec //默认推荐，异步操作，每秒记录，如果宕机，有1秒内数据丢失
appendfsync no //不同步，只有在操作系统需要时在刷新数据
aof-load-truncated yes
当AOF文件被截断时，即AOF文件的最后命令不完整，如果此时启动Redis，会将AOF数据加载回内存，此时便会出现问题。
- yes：加载一个截断的
AOF，Redis服务器开始发出日志，通知用户该事件； - no：服务器将中止并出现错误，拒绝启动。
当我们得知AOF文件报错时，可以用以下方法来修复出错的 AOF 文件：
-
为现有的
AOF文件创建一个备份； -
使用
Redis附带的redis-check-aof命令，对原来的AOF文件进行修复；-
redis-check-aof –fix -
redis-check-aof --fix appendonly.aof修复命令，杀光不符合规范的语法
-
-
（可选）使用
diff -u对比修复后的AOF文件和原始AOF文件的备份，查看两个文件之间的不同之处； -
重启
Redis服务器，等待服务器载入修复后的AOF文件，并进行数据恢复。
至于 AOF 的其他配置需要配合“日志重写”来讲解，所以我们在下文中进行系统的学习。如果你有不同的意见或者更好的idea，欢迎联系阿Q，添加阿Q可以加入技术交流群参与讨论呦！
