1.需求
在传统的Web小规模并发的情况下，单个Tomcat容器往往就能胜任请求的负载与处理，如图1所示的方案一。方案一的好处在于，部署简单，维护方便，在Web服务发生变更之后，能够快速升级；除此之外，在用户Session管理方面也十分简单：将所有Session存储至本地服务器即可。但是该方案存在并发规模小、单点故障等原因。
![image]( "image")
图1 单节点Tomcat示意图
针对方案一存在的负载小、单点故障等因素，方案二进行了大规模的改进。首先，使用NGINX+keepalived取代原来的单节点Tomcat，同时以NGINX作为反向代理服务器，管理多个Tomcat服务节点。如图2所示。
![image]( "image")
图2 多节点Tomcat部署示意图
从图2可以看出，单节点部署的用户请求负载，从单个Tomcat服务器转移到了Nginx负载（还有其他负载均衡方式）下的多个Tomcat节点，从而实现了单个Web服务的负载均衡与备份。而各个Tomcat节点与NGINX之间，则是采用反向代理的形式进行通信，具体方法有以下五种：
**1、轮询（默认）
每个请求按时间顺序逐一分配到不同的后端服务器，如果后端服务器down掉，能自动剔除。
upstream backserver {
server 192.168.0.14;
server 192.168.0.15;
} **
**2、指定权重
指定轮询几率，weight和访问比率成正比，用于后端服务器性能不均的情况。
upstream backserver {
server 192.168.0.14 weight=10;
server 192.168.0.15 weight=10;
} **
**3、IP绑定 ip_hash
每个请求按访问ip的hash结果分配，这样每个访客固定访问一个后端服务器，可以解决session的问题。
upstream backserver {
ip_hash;
server 192.168.0.14:88;
server 192.168.0.15:80;
}
**
**4、fair（第三方）
按后端服务器的响应时间来分配请求，响应时间短的优先分配。
upstream backserver {
server server1;
server server2;
fair;
} **
**5、url_hash（第三方）
按访问url的hash结果来分配请求，使每个url定向到同一个后端服务器，后端服务器为缓存时比较有效。
upstream backserver {
server squid1:3128;
server squid2:3128;
hash $request_uri;
hash_method crc32;
} **
具体NGINX+Keepalived+Tomcat的负载均衡搭建请参考我的另一篇博客。
2.带来的问题
