目录
1 什么是AOP
以日志的形式记录每个写操作，将redis执行过的所有写指令记录下来(读操作不记录)，只许追加文件，但不许改写文件，redis启动之初会读取该文件重新构建数据，换言之，redis重启的话就是根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作
2?appendonly.aof文件
############################## APPEND ONLY MODE ###############################
# By default Redis asynchronously dumps the dataset on disk. This mode is
# good enough in many applications, but an issue with the Redis process or
# a power outage may result into a few minutes of writes lost (depending on
# the configured save points).
#
# The Append Only File is an alternative persistence mode that provides
# much better durability. For instance using the default data fsync policy
# (see later in the config file) Redis can lose just one second of writes in a
# dramatic event like a server power outage, or a single write if something
# wrong with the Redis process itself happens, but the operating system is
# still running correctly.
#
# AOF and RDB persistence can be enabled at the same time without problems.
# If the AOF is enabled on startup Redis will load the AOF, that is the file
# with the better durability guarantees.
#
# Please check https://redis.io/topics/persistence for more information.
appendonly no
# The name of the append only file (default: "appendonly.aof")
appendfilename "appendonly.aof"
# The fsync() call tells the Operating System to actually write data on disk
# instead of waiting for more data in the output buffer. Some OS will really flush
# data on disk, some other OS will just try to do it ASAP.
#
# Redis supports three different modes:
#
# no: don't fsync, just let the OS flush the data when it wants. Faster.
# always: fsync after every write to the append only log. Slow, Safest.
# everysec: fsync only one time every second. Compromise.
#
# The default is "everysec", as that's usually the right compromise between
# speed and data safety. It's up to you to understand if you can relax this to
# "no" that will let the operating system flush the output buffer when
# it wants, for better performances (but if you can live with the idea of
# some data loss consider the default persistence mode that's snapshotting),
# or on the contrary, use "always" that's very slow but a bit safer than
# everysec.
#
# More details please check the following article:
# http://antirez.com/post/redis-persistence-demystified.html
#
# If unsure, use "everysec".
# appendfsync always
appendfsync everysec
# appendfsync no
# When the AOF fsync policy is set to always or everysec, and a background
# saving process (a background save or AOF log background rewriting) is
# performing a lot of I/O against the disk, in some Linux configurations
# Redis may block too long on the fsync() call. Note that there is no fix for
# this currently, as even performing fsync in a different thread will block
# our synchronous write(2) call.
#
# In order to mitigate this problem it's possible to use the following option
# that will prevent fsync() from being called in the main process while a
# BGSAVE or BGREWRITEAOF is in progress.
#
# This means that while another child is saving, the durability of Redis is
# the same as "appendfsync none". In practical terms, this means that it is
# possible to lose up to 30 seconds of log in the worst scenario (with the
# default Linux settings).
#
# If you have latency problems turn this to "yes". Otherwise leave it as
# "no" that is the safest pick from the point of view of durability.
no-appendfsync-on-rewrite no
# Automatic rewrite of the append only file.
# Redis is able to automatically rewrite the log file implicitly calling
# BGREWRITEAOF when the AOF log size grows by the specified percentage.
#
# This is how it works: Redis remembers the size of the AOF file after the
# latest rewrite (if no rewrite has happened since the restart, the size of
# the AOF at startup is used).
#
# This base size is compared to the current size. If the current size is
# bigger than the specified percentage, the rewrite is triggered. Also
# you need to specify a minimal size for the AOF file to be rewritten, this
# is useful to avoid rewriting the AOF file even if the percentage increase
# is reached but it is still pretty small.
#
# Specify a percentage of zero in order to disable the automatic AOF
# rewrite feature.
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mbappendonly no
appendonly no 表示不开aof快照存储，appendonly yes表示开启快照存储
# The name of the append only file (default: "appendonly.aof")
appendfilename "appendonly.aof"
aof快照名称默认为:?appendonly.aof
# appendfsync always
appendfsync everysec
# appendfsync no
alaways: 同步持久化 每次发生数据变更会被立即记录到磁盘 性能较差但数据完整性较好
everysec：出厂异步推荐，异步操作，每秒记录 如果一秒内宕机，有数据丢失
no:
no-appendfsync-on-rewrite no
重写时是否可以运用Appendfsync,用默认no即可，保证数据安全性
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
设置重写的基准值
注意：appendonly.aof和dump.rdb可以放在同一bin目录下，启动时会优先找appendonly.aof文件。
如果此时redis启动失败，肯能是appendonly.aof文件中由于一些网络延时，丢包等原因产生了一些redis不能解析的语法，此时可以执行redis-check-aof --fix?appendonly.aof命令会自动检查并修正错误的语法。
3 Rewrite
?3.1 什么是rewrite
?AOF采用文件追加的方式，文件会越来越大为避免出现此种情况，新增了重写机制，当aof的文件大小超过所设定的阀值时，redis就会启动aof文件的内容压缩，只保留可以恢复数据的最小指令集，可以使用bgrewriteaof
3.2 重写原理
aof文件持续增长过大时，会fork出一条新进程来将文件重写(也是先写临时文件最后再rename),遍历新进程的内存中数据，每条记录都有一条set语句。重写aof文件的操作，并没有读取旧的aof文件，而是将整个内存中的数据库内容用命令的方式重新写了一个新的aof文件，这点和快照有些类似
? 3.3 触发机制
redis会记录上次重写时aof的大小，默认配置是当aof文件大小是上次rewrite后大小的一倍且文件大于64m时触发
4 AOF的优缺点
优点：可以灵活的配置同步规则
每秒同步：appendfsync?alaways: 同步持久化 每次发生数据变更会被立即记录到磁盘 性能较差但数据完整性较好
每修改同步：appendfsync?everysec：出厂异步推荐，异步操作，每秒记录 如果一秒内宕机，有数据丢失
不同步：appendfsync?no:
缺点：
1）相同数据集的数据而言aof文件要远大于rdb文件，恢复速度慢于rdb
2）aof运行效率要慢于rdb，每秒同步策略效率较好，不同步效率和rdb相同
5 总结
5.1 rdb和aof比较
RDB持久化方式能够在指定的时间间隔内对数据进行快照存储
AOF持久化方式记录每次对服务器写的?操作，当服务器重写的时候会重新执行这些命令来恢复原始的数据，AOF命令以redis协议追加保存每次写的操作到文件末尾，Redis还能对AOF文件进行后台重写，使得AOF文件的体积不至于过大
如果只希望数据在服务器运行的时候存在，也可以不选择任何持久化方式
5.2 同时开启两种持久化方式
在这种情况下，当redis重启时会优先载入AOF文件来恢复原始的数据。因为在通常的情况下AOF文件保存的数据比RDB文件保存到数据要完整。RDB的数据不实时，同时使用两者时服务器重启也会只找AOF文件(并不代表我们只使用AOF就可)，因为RDB更适合于用于备份数据库(AOF在不断变化不好备份)快速重启，而且不会有aof可能潜在的bug。