redis配置详解（五）---AOF配置

    默认情况下，Redis会异步的将数据持久化到磁盘。这种模式在大部分应用程序中已被验证是很有效的，但是在一些问题发生时，比如断电，则这种机制可能会导致数分钟的写请求丢失。

    如上半部分中介绍的，AOF是一种更好的保持数据一致性的方式。即使当服务器断电时，也仅会有1秒钟的写请求丢失，当Redis进程出现问题且操作系统运行正常时，甚至只会丢失一条写请求。

    官方建议，AOF机制和RDB机制可以同时使用，不会有任何冲突。

• appendonly yes

    我们还可以设置AOF文件的名称：

• appendfilename "appendonly.aof"

    fsync()调用，用来告诉操作系统立即将缓存的指令写入磁盘。一些操作系统会“立即”进行，而另外一些操作系统则会“尽快”进行。

    Redis支持三种不同的模式：

    （1）no：不调用fsync()。而是让操作系统自行决定sync的时间。这种模式下，Redis的性能会最快。

    （2）always：在每次写请求后都调用fsync()。这种模式下，Redis会相对较慢，但数据最安全。

    （3）everysec：每秒钟调用一次fsync()。这是性能和安全的折衷。

    默认情况下为everysec。

• appendfsync everysec

    当fsync方式设置为always或everysec时，如果后台持久化进程需要执行一个很大的磁盘IO操作，那么Redis可能会在fsync()调用时卡住。目前尚未修复这个问题，这是因为即使我们在另一个新的线程中去执行fsync()，也会阻塞住同步写调用。

    为了缓解这个问题，我们可以使用下面的配置项，这样的话，当BGSAVE或BGWRITEAOF运行时，fsync()在主进程中的调用会被阻止。这意味着当另一路进程正在对AOF文件进行重构时，Redis的持久化功能就失效了，就好像我们设置了“appendsync none”一样。如果Redis有时延问题，那么可以将下面的选项设置为yes。否则请保持no，因为这是保证数据完整性的最安全的选择。

• no-appendfsync-on-rewrite no

    我们允许Redis自动重写aof。当aof增长到一定规模时，Redis会隐式调用BGREWRITEAOF来重写log文件，以缩减文件体积。

    Redis是这样工作的：Redis会记录上次重写时的aof大小。假如Redis自启动至今还没有进行过重写，那么启动时aof文件的大小会被作为基准值。这个基准值会和当前的aof大小进行比较。如果当前aof大小超出所设置的增长比例，则会触发重写。另外还需要设置一个最小大小，是为了防止在aof很小时就触发重写。

• auto-aof-rewrite-percentage 100

• auto-aof-rewrite-min-size 64mb

    如果设置auto-aof-rewrite-percentage为0，则会关闭此重写功能。

    指Redis在恢复时，会忽略最后一条可能存在问题的指令，默认值yes。即在aof写入时，可能存在指令写错的问题(突然断电，写了一半)，这种情况下，yes会log并继续，而no会直接恢复失败。

• aof-load-truncated yes

转载于:https://my.oschina.net/u/3296302/blog/848875