Always
Redis每写入一个命令，always会把每条命令都刷新到硬盘的缓冲区当中然后将缓冲区里的数据写入到硬盘里。 这种模式下，Redis即使用遭遇意外停机，也不会丢失任何自己已经成功执行的数据Everysec
Redis每一秒调用一次fdatasync,将缓冲区里的命令写入到硬盘里， 这种模式下，当Redis的数据交换很多的时候可以保护硬盘 即使Redis遭遇意外停机时，最多只丢失一秒钟内的执行的数据No
服务器不主动调用fdatasync,由操作系统决定任何将缓冲区里面的命令写入到硬盘里，这种模式下，服务器遭遇意外停机时，丢失的命令的数量是不确定的 3.2.5 AOF三种方式比较 运行速度：always的速度慢，everysec和no都很快 always不丢失数据，但是硬盘IO开销很多，一般的SATA硬盘一秒种只能写入几百次数据 everysec每秒同步一次数据，如果Redis发生故障，可能会丢失1秒钟的数据 no则系统控制，不可控，不知道会丢失多少数据 3.2.6 AOF重写功能简介随着服务器的不断运行，为了记录Redis中数据的变化，Redis会将越来越多的命令写入到AOF文件中，使得AOF文件的体积来断增大
为了让AOF文件的大小控制在合理的范围，redis提供了AOF重写功能，通过这个功能，服务器可以产生一个新的AOF文件：
AOF重写功能就是把Redis中过期的，不再使用的，重复的以及一些可以优化的命令进行优化，重新生成一个新的AOF文件，从而达到减少硬盘占用量和加速Redis恢复速度的目的
3.2 7 AOF重写触发方式1.向Redis发送BGREWRITEAOF命令
类似于BGSAVE命令，Redis主进程会fork一个子进程，由子进程去完成AOF重写
这里的AOF重写是将Redis内存中的数据进行一次回溯，得到一个AOF文件，而不是将已有的AOF文件重写成一个新的AOF文件
2.通过配置选项自动执行BGREWRITEAOF命令
auto-aof-rewrite-min-size
触发AOF重写所需的最小体积：只要在AOF文件的大小超过设定的size时，Redis会进行AOF重写，这个选项用于避免对体积过小的AOF文件进行重写auto-aof-rewrite-percentage
指定触发重写所需的AOF文件体积百分比：当AOF文件的体积大于auto-aof-rewrite-min-size指定的体积，并且超过上一次重写之后的AOF文件体积的percent%时，就会触发AOF重写，如果服务器刚启动不久，还没有进行过AOF重写，那么使用服务器启动时载入的AOF文件的体积来作为基准值。 将这个值设置为0表示关闭自动AOF重写功能只有当上面两个条件同时满足时才会触发Redis的AOF重写功能
3.2.8 AOF重写的流程如上图所示：
1.无论是执行bgrewriteaof命令还是自动进行AOF重写，实际上都是执行BGREWRITEAOF命令 2.执行bgrewriteaof命令,Redis会fork一个子进程， 3.子进程对内存中的Redis数据进行回溯，生成新的AOF文件 4.Redis主进程会处理正常的命令操作 5.同时Redis把会新的命令写入到aof_rewrite_buf当中，当bgrewriteaof命令执行完成，新的AOF文件生成完毕，Redis主进程会把aof_rewrite_buf中的命令追加到新的AOF文件中 6.用新生成的AOF文件替换旧的AOF文件 3.2.9 配置文件中AOF相关选项 appendonly no # 改为yes，开启AOF功能 appendfilename "appendonly.aof" # 生成的AOF的文件名 appendfsync everysec # AOF同步的策略 no-appendfsync-on-rewrite no # AOF重写时，是否做append的操作 AOF重写非常消耗服务器的性能，子进程要将内存中的数据刷到硬盘中，肯定会消耗硬盘的IO 而正常的AOF也要将内存中的数据写入到硬盘当中，此时会有一定的冲突 因为rewrite的过程在数据量比较大的时候，会占用大量的硬盘的IO 在AOF重写后，生成的新的AOF文件是完整且安全的数据 如果AOF重写失败，如果设置为no则正常的AOF文件中会丢失一部分数据 生产环境中会在yes和no之间进行一定的权衡，通过优先从性能方面进行考虑，设置为yes auto-aof-rewrite-percentage 100 # 触发重写所需的AOF文件体积增长率 auto-aof-rewrite-min-size 64mb # 触发重写所需的AOF文件大小 3.2.10 Redis的AOF功能示例