REDIS fdatasync技术问题和BIO技术的引入

http://oldblog.antirez.com/post/fsync-different-thread-useless.html

这是原文作者的博客把他翻译下带上自己的一些理解看看作者引入fdatasync和bio技术上的一些探讨：【非常有用的磁盘持久化技术】

对于从kernel buffers写入到磁盘中这点是非常重要的，fdatasync就是做这个工作，当然本身磁盘本省也有cache层这层对于我们来讲可以暂时不用考虑，

对于fsync() 把文件数据和文件元信息写入强刷到磁盘中，速度是比较慢的。

REDIS提供一个持久化的模式叫做Append Only File.数据集的每个改变都会被写入到磁盘中，就是一个操作日志型的操作。所以fsync()操作是必须得用的【如果想要安全的话这是必须的操作】

因为fsync是慢的 REDIS就允许有3种不同的策略：

fsync never: 让kernel后台线程去做这个线程可能是30秒去做一次哦

fsync everysec: 一秒调用fsync

fsync always:每次有write操作到AOF里就会调用fsync

fsync erverysec 是一个很好的这种折中对于性能和安全这2个点。我们仅仅涉及一个能够每秒做一次sync但是不会阻塞我们反馈给客户端信息的操作。所以作者觉得这样做必须把fsync call调用就移到了另外一个线程里。用这种方式来处理，也许fsync会引起DISK非常繁忙但是没有用户会注意到这种延迟。因为客户端所需要的数据还是在内存里存在，redis还是照样能够很好的工作。

貌似正确但是我开始感觉这是无用的因为write调用会被阻塞如果一个fsync()去处理同一个文件的时候。

现在我们尝试的来分析下【非翻译部分】

目前而言前面探讨了这个fdatasync技术现在我们来看看BIO技术和怎么解决和提高AOF的技术。

BIO: backgroud IO .首先fsync是必须要调用的不过他多慢其次fsync必须要放在其他thread来做也就是backgroud thread.

background thread 目前redis主要做2个事情：

1 fdatasync(fd)

2 close(fd)

线程1 来做fdatasync(fd) 线程2做close(fd)

#define REDIS_BIO_CLOSE_FILE    0 /* Deferred close(2) syscall. */
#define REDIS_BIO_AOF_FSYNC     1 /* Deferred AOF fsync. */

在bio.c:

static pthread_mutex_t bio_mutex[REDIS_BIO_NUM_OPS];
static pthread_cond_t bio_condvar[REDIS_BIO_NUM_OPS];
static list *bio_jobs[REDIS_BIO_NUM_OPS];

在aof.c文件里会调用bioCreateBackgroundJob()，来创建2个JOB 放在thread1和thread2之后线程就完成了在后台处理这2个动作。

可以看下面的图：就能了解大概的做的一些动作：

这里我就假设你较为熟悉AOF机制，下期我会写下AOF持久化。这样就暴露出了一个问题：

AOF创建了一个进程之后 flushAppendOnlyFile 要把AOF文件写入到磁盘里，可以试想下：主线程一方面要调用write()把aofbuf写入到内核缓冲区，而另外一个线程调用fdatasync这就比较麻烦了这样会阻止了主线程的一个阻塞动作，影响了客户端的延迟，你懂的，这不是我们所想要的，看看redis怎么做的：

if (server.aof_fsync == AOF_FSYNC_EVERYSEC) sync_in_progress = bioPendingJobsOfType(REDIS_BIO_AOF_FSYNC) != 0;

首先判断aof_FSYNC那个线程里面有没有任务，如果有就要标记下sync_in_progress

if (server.aof_fsync == AOF_FSYNC_EVERYSEC && !force) {
        /* With this append fsync policy we do background fsyncing.
         * If the fsync is still in progress we can try to delay
         * the write for a couple of seconds. */
        if (sync_in_progress) {
            if (server.aof_flush_postponed_start == 0) {
                /* No previous write postponinig, remember that we are
                 * postponing the flush and return. */
                server.aof_flush_postponed_start = server.unixtime;
                return;
            } else if (server.unixtime - server.aof_flush_postponed_start < 2) {
                /* We were already waiting for fsync to finish, but for less
                 * than two seconds this is still ok. Postpone again. */
                return;
            }
            /* Otherwise fall trough, and go write since we can't wait
             * over two seconds. */
            server.aof_delayed_fsync++;
            redisLog(REDIS_NOTICE,"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.");
        }

sync_in_progress不等于0 是有fdatasync做这个动作，这里有2个条件让他不会真正的做而是延迟fdatasync。如果本身start还是0 设置下sart时间然后退出，或者Unixtime-start时间小于2 也返回。如果fdatasync执行有2秒钟了如果都不满足那么就要做真正的fdatasync 注意了这里就会引起write阻塞导致主服务阻塞。

nwritten = write(server.aof_fd,server.aof_buf,sdslen(server.aof_buf));

这里write可能会导致了主线程阻塞并不是write 因为wirte的aof_buf并不大基本上不会导致阻塞，而是后台的fdatasync导致write等待datasync完成了之后才调用write导致阻塞当然这个2延迟其实是可以修改的。看你自己的应用来看。当然改多了也不行权衡需要自己把握好。

接下来：

server.aof_current_size += nwritten;

    /* Re-use AOF buffer when it is small enough. The maximum comes from the
     * arena size of 4k minus some overhead (but is otherwise arbitrary). */
    if ((sdslen(server.aof_buf)+sdsavail(server.aof_buf)) < 4000) {
        sdsclear(server.aof_buf);
    } else {
        sdsfree(server.aof_buf);
        server.aof_buf = sdsempty();
    }

    /* Don't fsync if no-appendfsync-on-rewrite is set to yes and there are
     * children doing I/O in the background. */
    if (server.aof_no_fsync_on_rewrite &&
        (server.aof_child_pid != -1 || server.rdb_child_pid != -1))
            return;

然后处理了aof缓冲区部分其是说如果小于4k 就clear 如果不是就free掉这里保证了一个内存的重复利用性

如果有子进程做aof或者rdb存储工作就拒绝调用fsync。

这里又做了相关优化：因为前面调用的是fdatasync 没有修改文件大小元信息到磁盘里所以呢如果write成功之后就调用了ftruncate(server.aof_fd, server.aof_current_size)来修改aof_fd的大小。

if ((server.aof_fsync == AOF_FSYNC_EVERYSEC &&
                server.unixtime > server.aof_last_fsync)) {
        if (!sync_in_progress) aof_background_fsync(server.aof_fd);
        server.aof_last_fsync = server.unixtime;
    }

如果没有后台fsync 并且unixtime>aof_last_fsync(这个unixtime更新是一秒更新一次的 )则要进行fdatasync操作：aof_last_fsync改成当前时间然后aof_backgroud_fsync把fsync加入到后台操作里面。由此可以看出来要写出高性能的文件刷新程序是要对linux核的文件系统要非常了解以后有时间要把linux文件系统部分的内核操作要好好研究下。