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的大小是＆＃34;完整的连接队列＆＃34; （三次握手完成，所描述的内容为here）或＆＃34;未完成的连接队列＆＃34;？

如果这意味着＆＃34;完成连接队列＆＃34;那么我为什么要提出tcp_max_syn_backlog来限制一个不完整的连接队列的大小？

Answer 1

tcp-backlog的大小是＆＃34;完整的连接队列＆＃34; （三次握手完成，这里描述的内容）或＆＃34;不完整的连接队列＆＃34;？

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

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

如果这意味着＆＃34;完成连接队列＆＃34;那我为什么要提出tcp_max_syn_backlog来限制一个不完整的连接队列的大小？

引用您提到的文档：

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

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

如果你有一个较小的somaxconn tcp_max_syn_backlog，那么你可能没有足够的项目移动到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队列和一个由应用程序指定大小的接受队列。 < / p>

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

如果这意味着＆＃34;完成连接队列＆＃34;，那么我为什么要提出tcp_max_syn_backlog来限制未完成连接队列的大小？

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

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

Answer 3

昨天，我读了约书亚卡尔顿的Redis In Action第6章写道：“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字节？

什么＆＃34; tcp-backlog＆＃34;在redis.conf中

3 个答案: