redis的AOF 方式

[cafe3165]

为了兼顾数据和写入性能，用户可以考虑 appendfsync everysec 选项 ，让 Redis 每秒同步一次 AOF 文件，Redis 性能几乎没受到任何影响。而且这样即使出现系统崩溃，用户最多只会丢失一秒之内产生的数据。当硬盘忙于执行写入操作的时候，Redis 还会优雅的放慢自己的速度以便适应硬盘的最大写入速度。

该如何理解这句话呢？ 当硬盘忙于执行写入操作的时候，Redis 还会优雅的放慢自己的速度以便适应硬盘的最大写入速度

[LiWenGu]

1. 文档原文来自《Redis In Action》：Also, in the case where the disk is unable to keep up with the write volume that’s happening, Redis would gracefully slow down to accommodate the maximum write rate of the drive.

来自：https://redislabs.com/ebook/part-2-core-concepts/chapter-4-keeping-data-safe-and-ensuring-performance/4-1-persistence-options/4-1-2-append-only-file-persistence/

2. 答案原文：
   However if the disk can't cope with the write speed, and the background fsync(2) call is taking longer than 1 second, Redis may delay the write up to an additional second (in order to avoid that the write will block the main thread because of an fsync(2) running in the background thread against the same file descriptor). If a total of two seconds elapsed without that fsync(2) was able to terminate, Redis finally performs a (likely blocking) write(2) to transfer data to the disk at any cost.

答案来自http://oldblog.antirez.com/post/redis-persistence-demystified.html

3. 答案翻译：
   当磁盘无法满足写入速度，并且后台 fsync(2) 调用花费的时间超过 1 秒时，那么 Redis 可能会将该次 AOF 写入操作延迟最多一秒钟后执行（延迟是为了避免该写入操作会阻塞主线程，因为 fsync(2) 在后台线程是针对同一文件描述符运行的)。但是如果 fsync(2) 在这两秒内都没有正常执行完，那么 Redis 最终将强行执行（可能阻塞）write(2) 函数以将数据正确的传输到磁盘。

4. 我的理解：
   例如在 00:00 的时候，Redis 在 everysec 策略下，此时需要执行 AOF （fsync 函数）。但是在这 00:00 时刻，服务器上的另一个应用程序有大量写入的操作占用了当前磁盘的写入缓冲区。那么在这一秒，fsync 函数可能会超时失败（如果没有超时设置，那么在这 00:00，服务器上的磁盘大量写入，导致服务器所有应用（包括 Redis 自己）会导致主线程的写入阻塞）。Redis 为了优雅的解决这个问题，当 fsync 函数执行超时失败时，会使用延迟写入策略：会在 00:01 的时候写入本该 00:00 写入的文件（但是这种情况下出现异常，会导致 2s 的数据丢失？），如果在 00:01 的时候写入操作都执行超时，那么 Redis 会强行执行 write(2) 函数。

5. 具体你可以自己看源码：https://github.com/antirez/redis/blob/unstable/src/aof.c

我的理解是没有参考源码的，只是参考了答案原文网址。因为我看懂不懂 AOF 源码，就看懂了 fsync 是 BIO 方式执行 😭