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

EN

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

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

对于这个问题，@广胜左已经有了一个很好的答案。所以我将重点放在另一个上面。

如果它意味着“完整的连接队列”，那么为什么我要引发限制未完成连接队列大小的tcp_max_syn_backlog？

引用您提到的文档中的内容：

实现使用两个队列，SYN队列(或不完整连接队列)和接受队列(或完整连接队列)。状态为SYN received的连接被添加到SYN队列中，并且稍后当它们的状态变为ESTABLISHED时，即当接收到3次握手中的ACK分组时，被移动到accept队列。顾名思义，accept调用的实现只是为了使用来自accept队列的连接。在这种情况下，侦听syscall的backlog参数决定了接受队列的大小。

我们可以看到，complete connection queue incomplete connection queue.中的项目已从中移出

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

因此，仅提高somaxconn的值可能不起作用。你必须把它们都养大。

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服务器进行三次握手，并且这些客户端读取响应和发送请求的速度都很慢，那么它们会因为速度慢而占用redis服务器的SYN队列很长时间。

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

昨天，我读到了Redis in Action的第6章，其中Joshua Carlton写道：“Redis发布和订阅模型的缺点之一是客户端必须始终保持连接才能接收消息，断开连接可能导致客户端丢失消息，而较旧版本的Redis可能会变得无法使用、崩溃或被终止，如果订阅者速度较慢。”

然后，Joshua Carlton说，“尽管推送消息可以是有用的，但当客户端由于这样或那样的原因而不能一直保持连接时，我们就会遇到问题。为了解决这个限制，我们将编写两个不同的pull消息传递方法，它们可以用来替代发布/订阅。我们将首先从单一收件人消息传递开始，因为它与先进先出队列有许多共同之处。在这一节的后面，我们将介绍一种方法，在该方法中，我们可以有多个消息收件人。有了多个接收者，当我们需要我们的消息到达所有接收者时，我们可以替换Redis发布和订阅，即使他们已经断开连接。“我们有兴趣知道用Joshua Carlton的第6.5.2节多接收者发布/订阅替换来替代Redis发布和订阅是否会比利用UDP协议来检测和修复断开连接更有效。

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

Joshua Carlson的单收件人消息传递，以及在每秒20,000条消息的负载下断开连接的多个-recipient消息传递方法，其中每条消息是20字节？