redis.conf中的“tcp-backlog”是什么

Question

我对redis.conf中的tcp-backlog感到困惑：

# TCP listen() backlog.
#
# In high requests-per-second environments you need an high backlog in order
# to avoid slow clients connections issues. Note that the Linux kernel
# will silently truncate it to the value of /proc/sys/net/core/somaxconn so
# make sure to raise both the value of somaxconn and tcp_max_syn_backlog
# in order to get the desired effect.
tcp-backlog 511

tcp-backlog的大小是“完整连接队列”（三次握手完成， 这里描述的是什么）还是“不完整的连接队列”？

如果它意味着“完整的连接队列”那么我为什么要提出tcp_max_syn_backlog来限制一个不完整的连接队列的大小？

Answer 1

tcp-backlog的大小是“完整连接队列”（三次握手完成，这里描述的是什么）还是“不完整的连接队列”？

tcp-backlog是完整连接队列的大小。 实际上，Redis将此配置作为listen(int s, int backlog)调用的第二个参数传递。

@GuangshengZuo已经对这个问题有了一个很好的答案。 所以我会专注于另一个。

如果它意味着“完整的连接队列”那么我为什么要提出tcp_max_syn_backlog来限制一个不完整的连接队列的大小？

从你提到的文档引用：

该实现使用两个队列，一个SYN队列（或不完整的连接队列）和一个接受队列（或完整的连接队列）。 状态SYN RECEIVED中的连接被添加到SYN队列，并且当它们的状态变为ESTABLISHED时，即当接收到3次握手中的ACK数据包时，移动到接受队列。 顾名思义，接受调用然后只是为了使用来自接受队列的连接而实现。 在这种情况下，listen syscall的backlog参数确定接受队列的大小。

我们可以看到， 在项目complete connection queue从移动incomplete connection queue 。

如果你有一个带有小tcp_max_syn_backlog的大型somaxconn ，那么你可能没有足够的项目移动到complete connection queue ，并且complete connection queue可能永远不会满。 许多请求可能已经从第一个队列中删除，然后才有机会被移动到第二个队列。

所以只提高somaxconn的值可能不起作用。 你必须提高他们两个。

Answer 2

tcp-backlog是接受队列或完整连接队列的大小。

正如你提到的文档说：

在Linux上，事情是不同的，如listen syscall的手册页中所述：

使用Linux 2.2更改了TCP套接字上的backlog参数的行为。 现在它指定了等待接受的完全建立的套接字的队列长度，而不是未完成的连接请求的数量。 可以使用/ proc / sys / net / ipv4 / tcp_max_syn_backlog设置不完整套接字的队列的最大长度。

这意味着当前的Linux版本使用具有两个不同队列的第二个选项： 具有由系统范围设置指定的大小的SYN队列和具有由应用程序指定的大小的接受队列。

Redis服务器使用tcp-backlog的配置来指定listen（）接受队列的大小。 SYN队列大小由linux的管理员决定。

如果它意味着“完整连接队列”，那么我为什么要提出tcp_max_syn_backlog来限制不完整连接队列的大小？

提升tcp_max_syn_backlog旨在避免缓慢的客户端连接问题 。 如果有一些慢速客户端正在与redis服务器进行3次握手，并且这些客户端读取响应和发送请求的速度很慢，那么他们将长时间使用redis服务器的SYN队列，因为它们很慢。

在某些情况下，SYN-queue将被填充，因为这些低效的客户端。 如果SYN队列已填满，则redis服务器无法接受新客户端。 所以你应该提高tcp_max_syn_backlog来处理这个问题。

Answer 3

昨天，我阅读了Redis In Action中的第6章，其中Joshua Carlton写道：“Redis发布和订阅模型的一个缺点是客户端必须始终连接以接收消息，断开连接会导致客户端丢失消息，如果订阅者很慢，Redis的旧版本可能会变得无法使用，崩溃或被杀死。“

然后，Joshua Carlton表示，“尽管推送消息传递可能很有用，但是当客户因某种原因无法始终保持连接时，我们会遇到问题。为了解决这个限制，我们将编写两种不同的拉消息方式，可以用作PUBLISH / SUBSCRIBE的替代品。我们首先从单收件人消息开始，因为它与我们的先进先出队列有很多共同之处。在本节后面，我们将转到我们可以拥有多个收件人的方法。有多个收件人，当我们需要我们的邮件到达所有收件人时，我们可以替换Redis PUBLISH和SUBSCRIBE，即使它们已断开连接“我们有兴趣知道它是否会更高效将Josis PUBLISH和SUBSCRIBE替换为Joshua Carlton的6.5.2节多用户发布/订阅替换，而不是利用UDP协议来检测和修复断开连接丢失。

 Could we set a high tcp_max_syn_backlog in redis.conf to prevent either of

Joshua Carlson的单一收件人消息传递和多重收件人消息传递方法，每秒消息超过20,000条消息，每条消息为20字节？