Redis repl-disable-tcp-nodelay配置

Base： Redis 2.8.7

Redis的Replication有一个配置“repl-disable-tcp-nodelay”，如下

# Disable TCP_NODELAY on the slave socket after SYNC?

#

# If you select "yes" Redis will use a smaller number of TCP packets and

# less bandwidth to send data to slaves. But this can add a delay for

# the data to appear on the slave side, up to 40 milliseconds with

# Linux kernels using a default configuration.

#

# If you select "no" the delay for data to appear on the slave side will

# be reduced but more bandwidth will be used for replication.

#

# By default we optimize for low latency, but in very high traffic conditions

# or when the master and slaves are many hops away, turning this to "yes" may

# be a good idea.

repl-disable-tcp-nodelay no

解释：

在slave和master同步后（发送psync/sync），后续的同步是否设置成TCP_NODELAY

假如设置成yes，则redis会合并小的TCP包从而节省带宽，但会增加同步延迟（40ms），造成master与slave数据不一致

假如设置成no，则redis master会立即发送同步数据，没有延迟

前者关注性能，后者关注一致性

代码分析：

命令配置，sync&psync都配置响应为syscCommand：

Redis.c

{"sync",syncCommand,1,"ars",0,NULL,0,0,0,0,0},

{"psync",syncCommand,3,"ars",0,NULL,0,0,0,0,0},

syscCommand函数：

Replication.c

void syncCommand(redisClient *c) {
     ......
    if (!strcasecmp(c->argv[0]->ptr,"psync")) {//增量同步
        if (masterTryPartialResynchronization(c) == REDIS_OK) {
            server.stat_sync_partial_ok++;
            return; /* No full resync needed, return. */
        } else {
            char *master_runid = c->argv[1]->ptr;
            if (master_runid[0] != '?') server.stat_sync_partial_err++;
        }
    } else {//全量同步
        c->flags |= REDIS_PRE_PSYNC;
    }

    /* Full resynchronization. */
    server.stat_sync_full++;

    /* check是否需要生成rdb文件*/
    if (server.rdb_child_pid != -1) {
        ......
    } else {
        //fork子进程生成RDB文件
        ......
    }

    //调用setsockopt设置TCP_NODELAY
    if (server.repl_disable_tcp_nodelay)
        anetDisableTcpNoDelay(NULL, c->fd); /* Non critical if it fails. */
    ......
}

TCP_NODELAY

TCP/IP协议发送数据过程：

1. 发送方发送数据

2. 接收方接收到数据后，回复ACK向发送者确认接收

为了尽可能利用网络带宽，TCP/IP使用了Nagle算法（一般服务器默认开启）

Nagle算法是为了避免网络上充斥着小数据包，其基本定义：任意时刻，最多只能有一个还没有接收到ACL确认的数据块。

具体规则如下：

IF 有新的数据要发送

IF 窗口大小> = MSS

立即发送

ELSE IF有未确认的数据仍然在等待

在接收缓冲区中的排队，直到一个应答

ELSE

立即发送

FI

FI

Nagle算法缓存了小数据包，提高了网络效率，但会单来一个不可预测延迟的问题。

但仅仅是Nagle算法并不会带来前文所说的40ms延迟的问题

A向B发送消息，B回馈ACK，A继续发送下一条，没有问题！

40ms是Nagle和TCP确认延迟机制共同作用的结果

TCP确认延迟机制：当Server端收到数据之后,它并不会马上向client端发送ACK,而是会将ACK的发送延迟一段时间，这个时间大概为40ms

A向B发送消息，B延迟40ms发送ACK（TCP确认延迟），由于B没有回复ACK，A不能发送下一条（Nagle），此时带来延迟

想深入理解Nagle和Tcp确认延迟的同学，推荐一篇非常好的文章，再探linux下的tcp延迟确认机制