反向代理负载均衡 注意点

反向代理负载均衡

反向代理的核心工作便是转发HTTP请求，因此它工作在HTTP层面，也就是TCP七层的应用层，所以基于反向代理的负载均衡也称为七层负载均衡。

作为负载均衡调度器的反向代理完全扮演用户和实际服务器的中间人，这意味着：
1、任何对于实际服务器的HTTP的请求都必须经过调度器。
2、调度器等待实际服务器的HTTP响应，并将它反馈给用户。

按权重分配任务

在这种全新的调度模式下，任何对于实际服务器的HTTP请求都必须经过调度器。随便说明一下，这种基于反向代理的负载均衡系统中，我们也常把实际服务器称为后端服务器(Back-end Server)。

当不同能力的后端服务器并存的时候，调度器并不希望平均分配任务给它们。本着多劳多得的原则，有些反向代理服务器可以精确的控制分配权重，这里我们用Nginx作为反向代理服务器。

假设我们有2台后端服务器，它们的80端口都运行着Apche。

10.0.1.100
10.0.1.200

这2台服务器配置不同，比如，10.0.1.100内存为8GB，10.0.1.200内存为4GB。

下面我们用另一台10.0.1.50运行Nginx，作为反向代理服务器，也就是负载均衡调度器，并配置上前面2个后端服务器：

upstream backend{
  server 10.0.1.100:80;
  server 10.0.1.200:80;
}

以上是配置的关键部分，更多配置信息查阅Nginx的官方文档。

经过这样的配置后，Nginx将任务平均分配给2个后端，但还是不够明智，因为我们知道2个后端服务器的性能是不同的。
接下来我们改变权重分配：

upstream backend{
  server 10.0.1.100:80 weight=2;
  server 10.0.1.200:80 weight=1;
}

这个就是2:1的权重分配，我们可以根据测试的实际情况来调整这个权重。

粘滞会话

我知道，当采取RR(Round Robin)调度策略时，即便是同一个用户对同一内容的多次请求，也可能被转发到了不同的后端服务器。这或许会带来一些问题：
1、当某台后端服务器启动了Session本地化来保存用户的一些数据后，下次用户的请求如果转发给了其他后端服务器，将导致之前的Session数据无法访问；
2、后端服务器实现了一定的动态内容缓存，而毫无规律的转发使得这些缓存利用率下降。

这时我们需要让调度起可识别用户，那么把用户的IP地址作为识别的标志就最为合适了，一些反向代理服务器对此都支持。比如Nginx，只需要在upstream中声明ip_hash即可：

upstream backend{
    ip_hash;
    server 10.0.1.100:80 weight=2;
    server 10.0.1.200:80 weight=1;
}

事实上，在后端服务器上保存Session数据和本地化缓存，是意见不太明智的事情。我们应该尽量避免这样的设计，采用分布式Session或者分布式缓存等，让后端服务器的应用尽量和本地无关。