redis.conf 中的 "tcp-backlog" 是什么
What's "tcp-backlog" in redis.conf
我对 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是"complete connection queue"的大小（三次握手完成，描述的是什么here）还是"incomplete connection queue"？
如果它意味着 "complete connection queue" 那么我为什么要提高 tcp_max_syn_backlog 来限制不完整连接队列的大小？
tcp-backlog 是接受队列或完整连接队列的大小。
正如您提到的文档所说：
On Linux, things are different, as mentioned in the man page of the listen syscall:
The behavior of the backlog argument on TCP sockets changed with Linux 2.2. Now it specifies the queue length for completely established sockets waiting to be accepted, instead of the number of incomplete connection requests. The maximum length of the queue for incomplete sockets can be set using /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 队列会因为这些低效的客户端而被填满。如果 SYN 队列已满，redis 服务器将无法接受新的客户端。所以你应该提高 tcp_max_syn_backlog 来处理这个问题。
Is tcp-backlog the size of "complete connection queue" (three-way handshake complete, what is described here) or "incomplete connection queue"?
tcp-backlog 是 完整连接队列 的大小。实际上，Redis 将此配置作为 listen(int s, int backlog) 调用的第二个参数传递。
@GuangshengZuo 已经很好的回答了这个问题。所以我会专注于另一个。
If it means "complete connection queue" then why should I raise tcp_max_syn_backlog which limits the size of an incomplete connection queue?
引用您提到的文档：
The implementation uses two queues, a SYN queue (or incomplete connection queue) and an accept queue (or complete connection queue). Connections in state SYN RECEIVED are added to the SYN queue and later moved to the accept queue when their state changes to ESTABLISHED, i.e. when the ACK packet in the 3-way handshake is received. As the name implies, the accept call is then implemented simply to consume connections from the accept queue. In this case, the backlog argument of the listen syscall determines the size of the accept queue.
我们可以看到 complete connection queue 中的 项是从 incomplete connection queue 中移出的。
如果您有一个大的 somaxconn 和一个小的 tcp_max_syn_backlog，那么您可能没有足够的项目移动到 complete connection queue，并且 complete connection queue 可能永远不会吃饱。许多请求在有机会移动到第二个队列之前可能已经从第一个队列中删除。
所以只提高 somaxconn 的值可能行不通。你必须同时提高它们。
昨天，我读了 Joshua Carlton 的 Redis In Action 中的第 6 章
写道“Redis 发布和订阅的缺点之一
模型是客户端必须始终连接才能接收
消息，断开连接会导致客户端丢失消息，并且
旧版本的 Redis 可能变得不可用、崩溃或被杀死，如果
订阅者速度慢。"
然后，Joshua Carlton 指出，"Though push messaging can be useful, we run into problems when clients can’t stay connected all the time for one reason or another. To address this limitation, we’ll write two different pull messaging methods that can be used as a replacement for PUBLISH/SUBSCRIBE. We’ll first start with single-recipient messaging, since it shares much in common with our first-in, first-out queues. Later in this section, we’ll move to a method where we can have multiple recipients of a message. With multiple recipients, we can replace Redis PUBLISH and SUBSCRIBE when we need our messages to get to all recipients, even if they were disconnected"
我们很想知道用 Joshua Carlton 的第 6.5.2 节多接收者 publish/subscribe 替换 Redis PUBLISH 和 SUBSCRIBE 代替利用 UDP 协议来检测和修复断开连接丢失是否会更高效。
Could we set a high tcp_max_syn_backlog in redis.conf to prevent either of
Joshua Carlson 的单收件人消息传递和多收件人消息传递方法在每秒 20,000 条消息（每条消息为 20 字节）的负载下断开连接？
我对 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是"complete connection queue"的大小（三次握手完成，描述的是什么here）还是"incomplete connection queue"？
如果它意味着 "complete connection queue" 那么我为什么要提高 tcp_max_syn_backlog 来限制不完整连接队列的大小？
tcp-backlog 是接受队列或完整连接队列的大小。
正如您提到的文档所说：
On Linux, things are different, as mentioned in the man page of the listen syscall:
The behavior of the backlog argument on TCP sockets changed with Linux 2.2. Now it specifies the queue length for completely established sockets waiting to be accepted, instead of the number of incomplete connection requests. The maximum length of the queue for incomplete sockets can be set using /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 队列会因为这些低效的客户端而被填满。如果 SYN 队列已满，redis 服务器将无法接受新的客户端。所以你应该提高 tcp_max_syn_backlog 来处理这个问题。
Is tcp-backlog the size of "complete connection queue" (three-way handshake complete, what is described here) or "incomplete connection queue"?
tcp-backlog 是 完整连接队列 的大小。实际上，Redis 将此配置作为 listen(int s, int backlog) 调用的第二个参数传递。
@GuangshengZuo 已经很好的回答了这个问题。所以我会专注于另一个。
If it means "complete connection queue" then why should I raise tcp_max_syn_backlog which limits the size of an incomplete connection queue?
引用您提到的文档：
The implementation uses two queues, a SYN queue (or incomplete connection queue) and an accept queue (or complete connection queue). Connections in state SYN RECEIVED are added to the SYN queue and later moved to the accept queue when their state changes to ESTABLISHED, i.e. when the ACK packet in the 3-way handshake is received. As the name implies, the accept call is then implemented simply to consume connections from the accept queue. In this case, the backlog argument of the listen syscall determines the size of the accept queue.
我们可以看到 complete connection queue 中的 项是从 incomplete connection queue 中移出的。
如果您有一个大的 somaxconn 和一个小的 tcp_max_syn_backlog，那么您可能没有足够的项目移动到 complete connection queue，并且 complete connection queue 可能永远不会吃饱。许多请求在有机会移动到第二个队列之前可能已经从第一个队列中删除。
所以只提高 somaxconn 的值可能行不通。你必须同时提高它们。
昨天，我读了 Joshua Carlton 的 Redis In Action 中的第 6 章 写道“Redis 发布和订阅的缺点之一 模型是客户端必须始终连接才能接收 消息，断开连接会导致客户端丢失消息，并且 旧版本的 Redis 可能变得不可用、崩溃或被杀死，如果 订阅者速度慢。"
然后，Joshua Carlton 指出，"Though push messaging can be useful, we run into problems when clients can’t stay connected all the time for one reason or another. To address this limitation, we’ll write two different pull messaging methods that can be used as a replacement for PUBLISH/SUBSCRIBE. We’ll first start with single-recipient messaging, since it shares much in common with our first-in, first-out queues. Later in this section, we’ll move to a method where we can have multiple recipients of a message. With multiple recipients, we can replace Redis PUBLISH and SUBSCRIBE when we need our messages to get to all recipients, even if they were disconnected" 我们很想知道用 Joshua Carlton 的第 6.5.2 节多接收者 publish/subscribe 替换 Redis PUBLISH 和 SUBSCRIBE 代替利用 UDP 协议来检测和修复断开连接丢失是否会更高效。
Could we set a high tcp_max_syn_backlog in redis.conf to prevent either of
Joshua Carlson 的单收件人消息传递和多收件人消息传递方法在每秒 20,000 条消息（每条消息为 20 字节）的负载下断开连接？