持续高负荷工况下常见的背压策略
我想知道人们在他们的web服务中使用的常见的背压策略是什么？
假设您的服务在负载较重的情况下运行，并且在某个时候负载达到您容量的120%。你怎么处理这件事？
我能想到的最合理的策略就是开始拒绝连接。因此，如果一个主机达到其峰值容量(例如，所有Apache工作人员都很忙)，我将开始拒绝TCP连接，直到其中一个工作人员释放为止。这样，所有被接受的连接都会被立即处理，而不需要排队(因此延迟最小)，而超过20%的连接被拒绝，从而允许负载均衡器将它们重新分配到另一个主机，或者执行任何其他的减载策略(例如重定向到静态/缓存内容)。
我认为这种快速失败的方法比任何类型的排队都要好得多。小龙很好地吸收短突发的交通，但过多的排队，您的系统可能会在沉重的负荷下严重失败。例如，对于没有任何AQM的FIFO队列处理，当所有处理的请求都已在客户端超时时，它就会进入状态，因此系统不会向前推进。
我感到惊讶的是，这一战略并不像听起来那么容易实施。我的方法是在web服务器上设置一个小的侦听待办事项，希望所有不适合的连接都会被拒绝。但是由于LinuxKern2.2中的变化，这个策略失败了(参见http://veithen.github.io/2014/01/01/how-tcp-backlog-works-in-linux.html)。
较新的Linux内核无条件地接受连接。SYN-ACK响应被发送到客户机，而根本不考虑侦听积压大小。启用tcp_中止_在……上面_溢出选项也没有多大帮助。此选项使内核在连接不适合接受队列时发送RST，但此时客户端已经考虑到已建立的连接，并且可能已经开始发送数据。
这在HAProxy中尤其有问题。如果成功地建立了连接，它将不会将请求重新调度到另一个服务器，因为该请求可能对服务器产生了一些副作用。
所以我想我的问题是：
- 难道我是那个试图实现这样的东西的怪人吗？
- 您是否可以推荐其他应对持续高负荷的策略？
- Linux内核的tcp_abort_on_overflow坏了吗?应该应用到半开放队列中吗？
提前感谢！
回答 1
Server Fault用户
发布于 2015-05-12 05:49:11
回答你的第一个问题:是的。好吧，在我个人看来，不管怎么说，别把它当回事。问题是，您正在尝试设置TCP堆栈的限制，而在它前面有一个负载平衡器，有许多计数器和选项。如果在TCP堆栈中限制自己，则在达到这些限制时会遇到更多问题。我会检查并保持负荷平衡器本身的限制。设置会话计数器，或制作一些将验证服务器运行状况的健康脚本。到达限制后，您可以拒绝新传入的请求，或者在将后端设置为full时将它们重定向到另一台服务器。您受到Apache的限制，而不是操作系统或haproxy的限制，因此尝试在apache到达之前控制对apache的负载，从而远离系统限制。
我想这也回答了你的第二个问题。
第三个问题的答案更复杂，我认为你不会想深入到这个问题中去。在我看来，达到TCP溢出状态在调整服务器以保持高负载和通信量方面已经走得太远了。
这是我的两分钱，希望能帮上忙。
https://serverfault.com/questions/678329
复制相似问题
腾讯云开发者
