☰

Nginx 负载平衡代理混乱

tag-icon • tag-icon nginx proxy load-balancing redirect rewrite
Nginx 负载平衡代理混乱

我目前正在尝试为一组下载镜像设置负载均衡器。在阅读此主题时，我发现 Nginx 非常适合用作负载均衡器，太棒了！但是当查看不同的配置时，我有点困惑。

你可以决定重定向或代理到后端服务器。重定向非常清楚，您告诉客户端转到其他地方，然后请求被传递和处理，负载平衡器不再起作用。

但是，如果您选择使用代理，那么这是否基本上会破坏运行多个下载镜像的整个想法？鉴于 nginx 会将请求转发到后端服务器，下载文件并将其传递给客户端？

因此，为了形象地展示我认为它的工作原理（数据包流）：

重定向：客户端 => 负载均衡器 => 后端 => 客户端

代理人：客户端 => 负载均衡器 => 后端 => 负载均衡器 => 客户端

或者代理会施展一些魔法并告诉客户端实际连接到后端来下载他的文件？

如果代理确实违背了拥有多个下载镜像以获得更多吞吐量的目的，那么重定向是唯一的选择吗？

编辑：或者我把代理的工作方式与重写的工作方式混淆了？代理是否真的像重定向一样传递请求，同时仍使用相同的 URL？

答案1

如果你使用nginx作为负载均衡器，流将是：

重定向：

Step 1 : Client => LB      (HTTP request) 
Step 2 : LB => Client      (HTTP reply)
Step 3 : Client => Backend (HTTP request)
Step 4 : Backend => Client (HTTP reply)

代理人 ：

Step 1 : Client => LB      (HTTP request) 
Step 2 : LB => Backend     (HTTP request) 
Step 3 : Backend => LB     (HTTP reply) 
Step 4 : LB => Client      (HTTP reply)

因此，在第一种情况下，负载均衡器就像您想象的那样是一个简单的 HTTP 服务器，后端直接回复客户端。在第二种情况下，它通过 nginx 一路返回到客户端。由于 nginx 不一定会等待完整的回复正文可用才开始将数据传输到客户端，因此它会根据配置使用缓冲区或临时文件将其流回。但是，您将遇到更高的数据包往返时间，因为在实际数据传输过程中您会多出一个跳转。

这就是在使用 HTTP 的情况下 OSI 第 7 层负载平衡的总体情况。现在，网络负载平衡不仅限于第 7 层和 HTTP。还有其他方法。

特别是，如果你正在寻找一种将流量传播到托管静态内容的后端服务器的方法，那么你可以使用keepalived作为直接路由模式下的负载平衡解决方案，这将使后端服务器直接回复客户端，而请求则通过负载平衡器（它是 OSI 第 4 层，因此它不知道您正在向上执行的操作，它只是安装虚拟 IP 并将 TCP 流推送到实际服务器，其中相同的虚拟 IP 安装在环回接口上）。Keepalived 还使用 VRRP（主/备份模型）处理 HA。

如果你绝对想坚持使用 nginx，那么有一个“类似”的东西叫做stream模块（出现在 nginx 1.9.0 中，不是“稳定”版本）但您需要自己重新编译它，并且即使通过在 OSI 层第 4 层工作也无法阻止跳回。

相关内容