Asynchronous AOF fsync is taking too long .

查看redis日志发现有大量的附件信息：
 Asynchronous AOF fsync is taking too long (disk is busy?). Writing the AOF buffer without waiting for fsync to complete, this may slow down Redis

老外的解释如下：
The message indicates that there's a fsync operation on the AOF file and it has been last for a little while, to protect your data from lose, redis will slow down to wait for that fsync. This often happens when:
1. you have a slow disk, or
2. you write too many data in a very short period.

You can enable persistence on slaves and disable AOF on the master to avoid this problem.
另外一个老外解释如下：

Unfortunately this is what happens when Redis is used with a very slow disk (EBS rocks at slowness), the only thing you can do is, in order to mitigate the problem, relax your AOF fsync policy from everysec to none (that in Linux this means that data will be flushed in 30 seconds at max). However even with this change if disk can't cope with I/O soon or later you'll see Redis blocking.

It's worth to spend a few words to show how this is not avoidable and is not Redis fault:

1) You ask Redis to fsync every second the AOF, to flush the kernel buffers to disk.
2) Redis will try, and usually disk will be able to receive the generated I/O without too much problems.
3) Then Redis has to rewrite the log because it is too big, so Redis creates another child to rewrite the log, however the log rewriting will use additional I/O.
4) At this point if the disk is slow, the additional I/O used to rewrite the log saturated it to the point that Redis will try to fsync data every second but the background thread is not able to accomplish the sync in a second. Redis will log a warning, and eventually if after two seconds the thread is still waiting to perform the fsync, it starts blocking, in your interest: you want data to be transmitted on disk!

So you can either relax the fsync policy, or use ephemeral storage for Redis (and move backups from time to time into EBS), and so forth.

Cheers,
Salvatore