ema*_*man 8 web-services tcp finagle
在webservices的上下文中,我已经看到使用术语"TCP连接流失".特别是Twitter finagle有办法避免它发生.怎么会发生？这是什么意思？
这个术语可能有多种用途,但我总是看到它用于在很短的时间内制作许多TCP连接的情况,从而导致客户端和服务器上的性能问题.
这通常发生在编写客户端代码时,它会自动连接任何类型的TCP故障.如果在连接成功之前(或者在协议交换的早期阶段)发生连接失败,则客户端可以进入接近忙碌的环路,不断进行连接.这可以在客户端导致性能问题 - 首先,有一个非常繁忙的循环吸了CPU周期的过程,其次,每个连接尝试消耗一个客户端端口号 - 如果进展速度不够快的软件可以环绕当他们达到最大端口号时(因为端口只有16位数,这当然不是不可能的).
虽然编写健壮的代码是一个有价值的目标,但这种简单的"自动重试"方法有点过于幼稚.您可以在其他上下文中看到类似的问题 - 例如,父进程不断重新启动立即崩溃的子进程.避免它的一种常见机制是某种增加的退缩.因此,当第一个连接失败时,您立即重新连接.如果它在短时间内(例如30秒)再次失败,那么在重新连接之前等待,比如2秒.如果它在30秒内再次失败,则等待4秒,依此类推.阅读有关指数退避的维基百科文章(或此博客文章可能更适合此应用程序),了解有关此技术的更多背景知识.
这种方法的优点是它不会压倒客户端或服务器,但它也意味着客户端仍然可以在没有手动干预的情况下恢复(这对于无人值守服务器上的软件尤为重要,例如,在大型集群中).
在恢复时间至关重要的情况下,TCP连接创建的简单速率限制也是非常可能的 - 可能每秒不超过1次.但是,如果每个服务器有许多客户端,这种更简单的方法仍然可以使服务器被接受然后关闭高连接速率的负载所淹没.
如果您计划采用指数退避,有一点需要注意 - 我建议强制执行最长等待时间,或者您可能会发现,一旦服务器端开始再次接受连接,长时间的故障会导致客户端花费太长时间才能恢复.在大多数情况下,我建议将5分钟作为合理的最大值,但当然这取决于应用程序.