一、AOF是什么
以日志的形式来记录每个写操作，将Redis执行过的所有写指令记录下来(读操作不记录)，只许追加文件但不可以改写文件，redis启动之初会读取该文件重新构建数据，换言之，redis重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作。
二、AOF保存的是什么AOF保存的是appendonly.aof文件
三、AOF的配置位置 573 ############################## APPEND ONLY MODE ###############################
574
575 # By default Redis asynchronously dumps the dataset on disk. This mode is
576 # good enough in many applications, but an issue with the Redis process or
577 # a power outage may result into a few minutes of writes lost (depending on
578 # the configured save points).
579 #
580 # The Append Only File is an alternative persistence mode that provides
581 # much better durability. For instance using the default data fsync policy
582 # (see later in the config file) Redis can lose just one second of writes in a
583 # dramatic event like a server power outage, or a single write if something
584 # wrong with the Redis process itself happens, but the operating system is
585 # still running correctly.
586 #
587 # AOF and RDB persistence can be enabled at the same time without problems.
588 # If the AOF is enabled on startup Redis will load the AOF, that is the file
589 # with the better durability guarantees.
590 #
591 # Please check http://redis.io/topics/persistence for more information.
592
593 appendonly no
594
595 # The name of the append only file (default: "appendonly.aof")
596
597 appendfilename "appendonly.aof"
598
599 # The fsync() call tells the Operating System to actually write data on disk
600 # instead of waiting for more data in the output buffer. Some OS will really flush
601 # data on disk, some other OS will just try to do it ASAP.
602 #
603 # Redis supports three different modes:
604 #
605 # no: don't fsync, just let the OS flush the data when it wants. Faster.
606 # always: fsync after every write to the append only log. Slow, Safest.
607 # everysec: fsync only one time every second. Compromise.
608 #
609 # The default is "everysec", as that's usually the right compromise between
610 # speed and data safety. It's up to you to understand if you can relax this to
611 # "no" that will let the operating system flush the output buffer when
612 # it wants, for better performances (but if you can live with the idea of
613 # some data loss consider the default persistence mode that's snapshotting),
614 # or on the contrary, use "always" that's very slow but a bit safer than
615 # everysec.
616 #
617 # More details please check the following article:
618 # http://antirez.com/post/redis-persistence-demystified.html
619 #
620 # If unsure, use "everysec".
621
622 # appendfsync always
623 appendfsync everysec
624 # appendfsync no
625
626 # When the AOF fsync policy is set to always or everysec, and a background
627 # saving process (a background save or AOF log background rewriting) is
628 # performing a lot of I/O against the disk, in some Linux configurations
629 # Redis may block too long on the fsync() call. Note that there is no fix for
630 # this currently, as even performing fsync in a different thread will block
631 # our synchronous write(2) call.
632 #
633 # In order to mitigate this problem it's possible to use the following option
634 # that will prevent fsync() from being called in the main process while a
635 # BGSAVE or BGREWRITEAOF is in progress.
636 #
637 # This means that while another child is saving, the durability of Redis is
638 # the same as "appendfsync none". In practical terms, this means that it is
639 # possible to lose up to 30 seconds of log in the worst scenario (with the
640 # default Linux settings).
641 #
642 # If you have latency problems turn this to "yes". Otherwise leave it as
643 # "no" that is the safest pick from the point of view of durability.
644
645 no-appendfsync-on-rewrite no
646
647 # Automatic rewrite of the append only file.
648 # Redis is able to automatically rewrite the log file implicitly calling
649 # BGREWRITEAOF when the AOF log size grows by the specified percentage.
650 #
651 # This is how it works: Redis remembers the size of the AOF file after the
652 # latest rewrite (if no rewrite has happened since the restart, the size of
653 # the AOF at startup is used).
654 #
655 # This base size is compared to the current size. If the current size is
656 # bigger than the specified percentage, the rewrite is triggered. Also
657 # you need to specify a minimal size for the AOF file to be rewritten, this
658 # is useful to avoid rewriting the AOF file even if the percentage increase
659 # is reached but it is still pretty small.
660 #
661 # Specify a percentage of zero in order to disable the automatic AOF
662 # rewrite feature.
663
664 auto-aof-rewrite-percentage 100
665 auto-aof-rewrite-min-size 64mb
666
667 # An AOF file may be found to be truncated at the end during the Redis
668 # startup process, when the AOF data gets loaded back into memory.
669 # This may happen when the system where Redis is running
670 # crashes, especially when an ext4 filesystem is mounted without the
671 # data=ordered option (however this can't happen when Redis itself
672 # crashes or aborts but the operating system still works correctly).
673 #
674 # Redis can either exit with an error when this happens, or load as much
675 # data as possible (the default now) and start if the AOF file is found
676 # to be truncated at the end. The following option controls this behavior.
677 #
678 # If aof-load-truncated is set to yes, a truncated AOF file is loaded and
679 # the Redis server starts emitting a log to inform the user of the event.
680 # Otherwise if the option is set to no, the server aborts with an error
681 # and refuses to start. When the option is set to no, the user requires
682 # to fix the AOF file using the "redis-check-aof" utility before to restart
683 # the server.
684 #
685 # Note that if the AOF file will be found to be corrupted in the middle
686 # the server will still exit with an error. This option only applies when
687 # Redis will try to read more data from the AOF file but not enough bytes
688 # will be found.
689 aof-load-truncated yes
690
- appendonly yes 启用AOF模式
- appendfilename “appendonly.aof” 设置AOF记录的文件名
- appendfsync always 同步持久化 每次发生数据变更会被立即记录到磁盘 性能较差但数据完整性比较好
- appendfsync everysec 出厂默认推荐，异步操作，每秒记录 如果一秒内宕机，有数据丢失
- appendfsync no 向磁盘进行数据刷写的频率,按照OS自身的刷写策略来进行，速度最快
- no-appendfsync-on-rewrite no 当主进程在进行向磁盘的写操作时，将会阻止其它的fsync调用
- auto-aof-rewrite-percentage 100 aof文件触发自动rewrite的百分比，值为0则表示禁用自动rewrite
- auto-aof-rewrite-min-size 64mb aof文件触发自动rewrite的最小文件size
- aof-load-truncated yes 是否加载不完整的aof文件来进行启动
1、复制一份redis.config文件为redis_aof.config，如下图： 
2、修改复制后的redis_aof.conf配置文件，把appendonly no为appendonly yes，如下图： 
3、删除dump.rdb文件，因为只演示aof备份，删除之前演示的rdb备份文件dump.rdb文件，删除后的安装目录文件夹如下图： 
4、用复制的redis_aof.conf配置文件启动redis，启动成功后在redis的安装目录下，会生成appendonly.aof格式的备份文件，如下图： 
5、往redis数据库中set值后，执行flushall清空数据库名令，并且停止、退出redis，查看redis安装目录，为了只演示aof备份，因此删除dump.rdb备份文件，如下图： 
6、查看appendonly.aof备份文件，该文件中都是执行过的写操作命令，如下图： 
7、用redis_aof.conf配置文件重新启动redis，看数据是否被恢复，如下图：数据为空，没有被恢复 
8、数据没有被恢复的原因，如下图： 
9、把appendonly.aof备份文件的最后一行flushall命令删除掉，重启redis，数据恢复成功。如下图：
1、复制一份redis.config文件为redis_aof.config，如下图： 2、修改复制后的redis_aof.conf配置文件，把appendonly no为appendonly yes，如下图： 3、删除dump.rdb文件，因为只演示aof备份，删除之前演示的rdb备份文件dump.rdb文件，删除后的安装目录文件夹如下图：
4、用复制的redis_aof.conf配置文件启动redis，启动成功后在redis的安装目录下，会生成appendonly.aof格式的备份文件，如下图： 5、往redis数据库中set值后，并且停止、退出redis，查看redis安装目录，为了只演示aof备份，因此删除dump.rdb备份文件，如下图： 
6、查看appendonly.aof备份文件，该文件中都是执行过的写操作命令，如下图： 
7、故意损坏appendonly.aof备份文件（编辑appendonly.aof，加入一直随意字符），重启redis，查看是否启动成功。如下图重启失败：
8、如何恢复异常的aof文件，步骤如下图： 
9、再查看appendonly.aof文件，不符合的字符被删除掉了。 
10、重启redis，查看数据恢复成功。如下图： 
1、rewrite是什么：
AOF采用文件追加方式，文件会越来越大为避免出现此种情况，新增了重写机制,当AOF文件的大小超过所设定的阈值时，Redis就会启动AOF文件的内容压缩，只保留可以恢复数据的最小指令集.可以使用命令bgrewriteaof
2、重写原理
AOF文件持续增长而过大时，会fork出一条新进程来将文件重写(也是先写临时文件最后再rename)， 遍历新进程的内存中数据，每条记录有一条的Set语句。重写aof文件的操作，并没有读取旧的aof文件， 而是将整个内存中的数据库内容用命令的方式重写了一个新的aof文件，这点和快照有点类似
3、触发机制
Redis会记录上次重写时的AOF大小，默认配置是当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发
七、AOF优势- 每修改同步：appendfsync always 同步持久化 每次发生数据变更会被立即记录到磁盘 性能较差但数据完整性比较好
- 每秒同步：appendfsync everysec 异步操作，每秒记录 如果一秒内宕机，有数据丢失
- 不同步：appendfsync no 从不同步
- 相同数据集的数据而言aof文件要远大于rdb文件，恢复速度慢于rdb
- aof运行效率要慢于rdb,每秒同步策略效率较好，不同步效率和rdb相同
