默认情况下Redis会异步的将数据导出到磁盘上。这种模式对许多应用程序已经足够了，
#但是如果断电或者redis进程出问题就会导致一段时间内的更新数据丢失（取决与配置项）
#
#这种只增文件是可选的能够提供更好的体验的数据持久化策略。
#举个例子，如果使用默认的配置数据fsync策略，在服务器意外断电的情况下redis只会丢失一秒中内的更新数据，
#或者当redis进程出问题但操作系统运转正常时，redis只会丢失一个数据更新操作。
#
#AOF 和 RDB 持久化方式可以同时启动并且无冲突。
#如果AOF开启，启动redis时会加载aof文件，这些文件能够提供更好的保证。
#请在 http://redis.io/topics/persistence 获取更多数据持久化信息。
appendonly no
# 只增文件的文件名称。（默认是appendonly.aof）
# appendfilename appendonly.aof
#调用fsync()函数会通知操作系统真正将数据写入磁盘，而不是等待缓冲区中有更多数据。
#有些操作系统会将数据输出到磁盘，有些操作系统只是ASAP。
#
#redis支持三种不同的方式：
#
#no:不调用，之等待操作系统来清空缓冲区当操作系统要输出数据时。很快。
# always: 每次更新数据都写入仅增日志文件。慢，但是最安全。
# everysec: 每秒调用一次。折中。
#
#默认是每秒中一次，因为它往往是在速度和数据安全两者之间的折中选择。
#如果你可以接受让操作系统去自动清空缓存，你可以将这项配置降低到'no'(如果你可以接受一段时间的数据丢失，默认的rdb就足够了)，
#这完全取决与你。如果你想要一个更好的体验或者从相反的角度，使用'always'，这样会很慢，但是比'everysec'安全些。
#
#请在下面的文章中获取更多细节知识：
# http://antirez.com/post/redis-persistence-demystified.html
#
#如果你不是很清楚这三项之间的区别，或者不知道哪种适合你的机器，就是用默认吧。
# appendfsync always
appendfsync always
# appendfsync no
#当AOF策略设置为'always'或者'everysec'的时候，后台的保存进程会进行很多磁盘I／O操作，
#在某些linux结构中redis会在调用sync()方法时阻塞很长时间。记住，现在还没办法解决这个问题，即使在不同进程中进行调用也会block。
#
#使用如下配置可能会缓解这个问题，这样会在存储大数据或者BIGREWRITEAOF的时候不会在主进程中调用fsync()方法。
#
# 这表示，如果另外一个子进程在进行保存操作，redis的表现如同配置为‘appendfsync no’。
#在实际应用中，这表示在最坏的情景下（使用linux默认配置）可能会丢失30秒日志。
#
#如果你有特殊的情况可以配置为'yes'。但是配置为'no'是最为安全的选择。
no-appendfsync-on-rewrite no
#自动重写只增文件。
#redis可以自动盲从的调用‘BGREWRITEAOF’来重写日志文件，如果日志文件增长了指定的百分比。
#
#它是这样工作的：每次rewrite后redis会记录日志文件的大小。（如果重启后没有重写后的大小，就默认用日志文件大小）
#
# 这个基准日志大小和当前日志大小做比较。如果当前大小比指定的百分比，重写机制就会被触发。
#同时，你也要制定一个重写下线，用来避免增长百分比够了，但是日志文件还很小的情况。
#
#指定百分比为0可以注掉自动重写日志文件功能。
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
#但是如果断电或者redis进程出问题就会导致一段时间内的更新数据丢失（取决与配置项）
#
#这种只增文件是可选的能够提供更好的体验的数据持久化策略。
#举个例子，如果使用默认的配置数据fsync策略，在服务器意外断电的情况下redis只会丢失一秒中内的更新数据，
#或者当redis进程出问题但操作系统运转正常时，redis只会丢失一个数据更新操作。
#
#AOF 和 RDB 持久化方式可以同时启动并且无冲突。
#如果AOF开启，启动redis时会加载aof文件，这些文件能够提供更好的保证。
#请在 http://redis.io/topics/persistence 获取更多数据持久化信息。
appendonly no
# 只增文件的文件名称。（默认是appendonly.aof）
# appendfilename appendonly.aof
#调用fsync()函数会通知操作系统真正将数据写入磁盘，而不是等待缓冲区中有更多数据。
#有些操作系统会将数据输出到磁盘，有些操作系统只是ASAP。
#
#redis支持三种不同的方式：
#
#no:不调用，之等待操作系统来清空缓冲区当操作系统要输出数据时。很快。
# always: 每次更新数据都写入仅增日志文件。慢，但是最安全。
# everysec: 每秒调用一次。折中。
#
#默认是每秒中一次，因为它往往是在速度和数据安全两者之间的折中选择。
#如果你可以接受让操作系统去自动清空缓存，你可以将这项配置降低到'no'(如果你可以接受一段时间的数据丢失，默认的rdb就足够了)，
#这完全取决与你。如果你想要一个更好的体验或者从相反的角度，使用'always'，这样会很慢，但是比'everysec'安全些。
#
#请在下面的文章中获取更多细节知识：
# http://antirez.com/post/redis-persistence-demystified.html
#
#如果你不是很清楚这三项之间的区别，或者不知道哪种适合你的机器，就是用默认吧。
# appendfsync always
appendfsync always
# appendfsync no
#当AOF策略设置为'always'或者'everysec'的时候，后台的保存进程会进行很多磁盘I／O操作，
#在某些linux结构中redis会在调用sync()方法时阻塞很长时间。记住，现在还没办法解决这个问题，即使在不同进程中进行调用也会block。
#
#使用如下配置可能会缓解这个问题，这样会在存储大数据或者BIGREWRITEAOF的时候不会在主进程中调用fsync()方法。
#
# 这表示，如果另外一个子进程在进行保存操作，redis的表现如同配置为‘appendfsync no’。
#在实际应用中，这表示在最坏的情景下（使用linux默认配置）可能会丢失30秒日志。
#
#如果你有特殊的情况可以配置为'yes'。但是配置为'no'是最为安全的选择。
no-appendfsync-on-rewrite no
#自动重写只增文件。
#redis可以自动盲从的调用‘BGREWRITEAOF’来重写日志文件，如果日志文件增长了指定的百分比。
#
#它是这样工作的：每次rewrite后redis会记录日志文件的大小。（如果重启后没有重写后的大小，就默认用日志文件大小）
#
# 这个基准日志大小和当前日志大小做比较。如果当前大小比指定的百分比，重写机制就会被触发。
#同时，你也要制定一个重写下线，用来避免增长百分比够了，但是日志文件还很小的情况。
#
#指定百分比为0可以注掉自动重写日志文件功能。
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb