哪种更好的负载平衡算法可以在一组服务器上分配传入请求？我已经读到他们是像Round Robin这样的算法..但是我想知道你对哪个算法更好或至少是最常用的算法的看法。
希望你们能帮助我。
答案 0 :(得分：1)
答案是：这取决于。在考虑特定于服务的多个因素时，实现了最佳负载平衡。例如，假设您有一个提供API来编码字符串的服务，其中编码完全取决于字符串的内容。您有N个服务正在运行的副本。
一种简单的方法是简单地使用客户端选择服务索引i = hash（string）/ N.假设输入字符串在散列空间上均匀分布，这将很好地工作并且非常容易实现。
现在说由于某种原因，字符串在散列空间上分布不均匀（例如，可能会重复很多字符串）。在这种情况下，您可以使用简单的循环方法，或随机选择索引。您还可以从服务器获得一定的背压：例如，如果RPC调用是同步的，您可以在客户端测量需要多长时间，并且在字符串编码的情况下，可以将其除以串;如果客户端注意到这个数字上升，则可能意味着该服务无法跟上，客户端可能会减少它发送给此类客户端的流量。这显然有点复杂。
TLDR：负载均衡有很多选择，其中一个是最好的选择，最好的＆＃34;取决于被缩放问题的具体性质。
答案 1 :(得分：0)
答案 2 :(得分：0)
对于HTTP服务器，Round Robin，Weight Round Robin和Random可能是最常用和最安全的模式，因为它们不会创建由于尝试确定要发送至哪个主机而引起的热点。
我知道可以使用多层方法来平均分配请求。在这里，您有2个经过轮询的集群，每个集群都有几台服务器，这些服务器具有随机分布。
最少的连接和最快的响应取决于根据过去的性能预测每个服务器的性能。尽管它们对于某些类型的负载很有用（例如，许多长时间运行的连接），但它们对于高流量的Web服务器可能会出现问题，因为它们可能导致对新部署的服务器或刚崩溃的服务器的请求泛滥。
理想的负载平衡算法是HTTP并没有真正支持的算法-“竞争消费者”。这是许多队列系统（例如RabbitMq）工作的方式。客户端拉出消息而不是将消息推送给他们。最快上班的那个 -因此将是最有可能执行它的人。
HTTP Web服务器基于推送而非拉动，因此这种模式并不适合。
但是，可以使用实现请求-响应模式的中介代理自己构建这种解决方案，但这带来了自己的挑战。