设计负载均衡器或 Dropbox 修补程序

需求

互联网规模的网络服务处理来自全球的高流量。然而，单个服务器在同一时间只能处理有限数量的请求。因此，通常会有一个服务器集群或大型服务器集群来共同承担流量。问题来了：如何路由这些请求，以便每个主机能够均匀地接收和处理请求？

由于从用户到服务器之间有许多跳数和负载均衡器层，因此这次我们的设计要求是

注意：如果服务 A 依赖于（或消费）服务 B，则 A 是 B 的下游服务，而 B 是 A 的上游服务。

为什么负载均衡很难？答案是很难收集准确的负载分布统计数据并相应地采取行动。

随机和轮询通过请求分配流量。然而，实际负载并不是每个请求 - 有些在 CPU 或线程利用率上很重，而有些则很轻。

为了更准确地评估负载，负载均衡器必须维护每个后端服务器的观察到的活动请求数量、连接数量或请求处理延迟的本地状态。基于这些信息，我们可以使用诸如最少连接、最少时间和随机 N 选择等分配算法：

最少连接：请求被传递给活动连接数最少的服务器。

基于延迟（最少时间）：请求被传递给平均响应时间最少和活动连接数最少的服务器，同时考虑服务器的权重。

然而，这两种算法仅在只有一个负载均衡器的情况下效果良好。如果有多个负载均衡器，可能会出现 羊群效应。也就是说，所有负载均衡器都注意到某个服务瞬时更快，然后都向该服务发送请求。

随机 N 选择（在大多数情况下 N=2 / 也称为 二选一的力量）：随机选择两个并选择两个中的更好选项，避免选择更差的选项。

本地负载均衡器对全局下游和上游状态并不知情，包括

有三种选项可以准确收集负载统计数据，然后采取相应的行动：

Dropbox Bandaid 团队选择了第三种选项，因为它很好地适应了他们现有的 随机 N 选择 方法。

然而，他们并没有像原始的 随机 N 选择 那样使用本地状态，而是通过响应头使用来自后端服务器的实时全局信息。

服务器利用率：后端服务器配置了最大容量并计算正在进行的请求，然后计算利用率百分比，范围从 0.0 到 1.0。

需要考虑两个问题：