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延迟确认机制