Redis repl-disable-tcp-nodelay配置

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

  1. void syncCommand(redisClient *c) {
  2.      ……
  3.     if (!strcasecmp(c->argv[0]->ptr,“psync”)) {//增量同步
  4.         if (masterTryPartialResynchronization(c) == REDIS_OK) {
  5.             server.stat_sync_partial_ok++;
  6.             return/* No full resync needed, return. */
  7.         } else {
  8.             char *master_runid = c->argv[1]->ptr;
  9.             if (master_runid[0] != ‘?’) server.stat_sync_partial_err++;
  10.         }
  11.     } else {//全量同步
  12.         c->flags |= REDIS_PRE_PSYNC;
  13.     }
  14.     /* Full resynchronization. */
  15.     server.stat_sync_full++;
  16.     /* check是否需要生成rdb文件*/
  17.     if (server.rdb_child_pid != -1) {
  18.         ……
  19.     } else {
  20.         //fork子进程生成RDB文件
  21.         ……
  22.     }
  23.     //调用setsockopt设置TCP_NODELAY
  24.     if (server.repl_disable_tcp_nodelay)
  25.         anetDisableTcpNoDelay(NULL, c->fd); /* Non critical if it fails. */
  26.     ……
  27. }

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

发表评论

电子邮件地址不会被公开。 必填项已用*标注

This blog is kept spam free by WP-SpamFree.