由于测试环境、准生产环境都只有一台web前端服务器和一台后端服务器(硬件将准生产的两台后端服务器的物理ip分配错误导致只能访问到一个后端服务器)所以session不一致的问题一直没有暴露；
凌晨发版之后测试人员在输入验证码提交查询时，后端抛出异常验证码失效，问题定位到sessionId不同，此问题是因为产生验证码和校验验证码请求到了两个不同的服务器并且服务器之间的session同步出现问题导致验证报错；
后台修改session同步问题耗时较多，遂决定先从前端nginx负载均衡着手解决问题；
nginx负载均衡模块：
1. ip-hash：该模块能将统一ip下的请求指向固定的后端机器，从而让该ip下的用户在相当长的时间内与后端某个服务器建立起稳固的session
Ip_hash要在upstream配置中定义:
upstream baidu.com{
server 192.168.1.168:80;
server 192.168.1.169:80;
ip_hash;
}
在随后的测试中该放的成功解决验证码无法验证的问题，但是该法暴露出严重的问题，了解ip_hash算法之后果断放弃；
ip_hash算法的主要代码如下：
for(i = 0; i < 3; i++) {
hash = (hash * 113+ iphp->addr[i]) % 6271;
}
该算法for循环只取前三个值二ip的点分十进制表示方法将ip分成四段（如：192.168.1.1），ip_hash算法循环时只是将ip的前三个段作为参数加入hash函数。该算法的目的是保证ip地址前三位相同的用户经过hash计算将分配到相同的后端服务器，该方法弊端相当明显会导致相同网段的人在一段相当长的时间内访问同一后端机器负载均衡失效；
2. 一致性哈希 consistent_hash配置如下：
events如下定义
events {
worker_connections 1024;
}
在upstream配置中定义:
upstream baidu.com{
consistent_hash $request_uri;
server 192.168.1.168:80;
server 192.168.1.169:80;
}
