我们项目在部署的时候，考虑到项目的高可用性以及能够处理更大的并发，
就将项目做了负载均衡。
采用的是nginx作为反向代理服务器结合tomcat来完成的。将项目分别部署到多台tomcat中，这样即便其中一台tomcat宕机了，
其他tomcat还能继续提供服务，这就是高可用。
再者一台tomcat能够处理的并发量在1500左右，那么就可以用多台tomcat处理更大
并发了。
默认情况下nginx采用的负载均衡策略是轮询策略。比如有4个请求发送过来，
nginx后跟了2台tomcat,分别是t1,t2。第一个请求被发送到t1,第二个请求被
发送到t2,第三个请求又被发送到t1,第四个请求又被发送到t2。这就是轮询策略。
除了轮询策略，常用的还有加权轮询以及ip_hash的负载均衡策略。
加权轮询可以这样理解，比如公司中的服务器，配置不一样，性能也不一样，这时候
就可以将配置高的服务器权重设置的更高些；配置低的服务器权重设置的低些，
通过weight关键字来实现。比如将t1的weight设置为3，将t2的weight设置为1。
那么当有4个请求过来时，t1处理其中的3个请求，t2处理其中的1个请求。
ip_hash就是将发送请求的客户端的ip地址进行hash化，并将其绑定到对应的tomcat
中。这样就能保证以后只要是这个客户端发送的请求都被固定的tomcat所处理，
就能解决session漂移的问题。
因为nginx默认采用的是轮询策略，所以就会产生session漂移的问题。
可以这样理解，用户在登录时，请求被发送到t1上，经过层层验证，判断
用户名密码等信息都正确的话，会在t1上生成session并把用户的信息存入session中。
但当登录成功后，跳转页面，就又会产生新的请求，这个请求就可能被发送到t2上，
这时候t2上的session中没有用户信息，经过拦截器的判断，如果session中没有用户信息，
就又重新跳转到登录页面，所以就会产生明明用户名和密码都正确，
但是登录成功的一瞬间又被跳转到了登录页面。
为了解决session漂移，可以将默认的轮询策略改为ip_hash的策略，这样同一个
客户端的请求就会被固定发送到一台tomcat上，就不会出现session漂移的问题了。
但还有个问题，如果客户端和t1通过ip_hash进行了绑定，后续这个客户端的所有
请求都会被发送到t1上，如果t1宕机了，那么新来的请求就会被发送到t2上，
而t2上不存在t1上登录成功的用户的session信息，所以就会被重定向到登录页面，
这对用户的体验度很不友好。
我们项目中最终是通过基于token的登录来解决session漂移的问题的。