我对使用 nginx/HAProxy 等实现 Web 应用程序负载平衡非常在行。据我了解，在这些情况下，您主要受到并发连接数和 TLS 握手数等因素的限制，但每个请求传输的数据量相对较小。
我目前正在开发一项服务，每次请求都会传输大量数据。想象一下通过我的服务器代理的视频流或点对点文件传输。
我想知道对此类情况进行负载平衡的典型方法是什么？即使 HAProxy 可以处理带宽，让所有内容都通过单个 VPS 也会很容易使其网络饱和（至少在 DigitalOcean 上如此；也许 AWS 25Gbps 实例就足够了）。我认为重定向可能是可行的方法，但我想避免这种情况，并想看看是否有更好的方法。
关于我的服务的另一条信息是，对同一 URL 的请求必须发送到同一上游服务器。但它只关心路径。查询参数、标头等并不重要。
我在 youtube 上做了一个快速检查，看起来他们使用重定向到几乎看起来随机的域名，例如r5---sn-qxo7rn7l.googlevideo.com，r1---sn-qxoedn7e.googlevideo.com。
编辑：应蒂姆的要求补充详细信息：
数据应被视为不可缓存。假设对等点 1 有一个 4GB 的视频文件，他们想与对等点 2 分享。对等点 1 连接到lb.example.com/path并等待对等点 2 连接。对等点 2 连接到lb.example.com/path，并且数据通过服务器从对等点 1 流式传输到对等点 2。
我将使用重定向来实现这一点，即 peer1 连接到lb.example.com/path。路径经过哈希处理，哈希值用于确定是否将 peer1 重定向到instance1.example.com或instance2.example.com。当 peer2 连接到相同路径时，它最终会到达相同的上游实例。哈希空间将在实例 1 和实例 2 之间均匀分配。
我同意 AWS 出口太昂贵了，这也是我尝试设计一个不依赖于单个大型网络管道的可扩展解决方案的重要原因。
答案1
对于点对点，您可能能够直接连接到另一个节点，从而完全消除基础架构的瓶颈。并且每个会话的入口和出口带宽成本。对于恢复全局寻址的 IPv6 尤其可行。匹配和防火墙穿越可能很棘手。
haproxy 可以扩展到数十万个连接，但您可能也想扩展。25 Gb 以太网的拥有成本相对较低，但租用成本较高。因此，节点数量众多是必然的。
对于负载均衡器，请尽可能少地保留状态。无状态 4 级路由。直接服务器返回，以便后端直接响应客户端。两者都使一些负载均衡器技巧变得困难，但这就是简单而快速的无状态的代价。
以 Vincent Bernat 的实验室为例使用 Linux 实现多层负载平衡。IPVS + keepalived 提供无状态 L4。haproxy 提供 L7 终止，由于 ，可直接返回服务器send-proxy。
无论您的设计如何，提供给用户的总带宽都需要超过峰值传输。您可以启动多个具有快速接口的负载均衡器实例，也可以从您的云中租用负载均衡器作为服务。