使用一个nginx做全局的代理负载均衡集群时遇到了一点问题。主要是前面的nginx集群机器很多(M个)，每个nginx机器的进程也很多(N个)，然后设置的keepalive数量和upstream里的机器数量相同。
这个时候如果后端机器的连接数限制比较小就杯具了，平时每个后端机器的长链接数差不多是M*N +XX ，因此链接的利用率(XX)/(M*N+XX) 。当前面的机器和单机进程数很多的时候链接的利用率就会非常低。造成健康检测时后端的机器检查失败，直接被踢掉了，引发雪崩效应。
这个时候如果后端的应用不改，那么唯一的2种方案：
1、改成短链接。可能整体的响应时间有所增加。
2、适当降低keepalive的值，但是降低的太多会使得和短链接差不多的效果。很难定量的衡量这个值的最佳性，只能不断测试。
其实在apache的mod_jk模块里也是统一存在这样的问题
[text]
Timeout 180
KeepAlive On
MaxKeepAliveRequests 1000
KeepAliveTimeout 360
<IfModule worker.c>
StartServers 10
ServerLimit 50
MaxClients 1500
MinSpareThreads 50
MaxSpareThreads 200
ThreadsPerChild 50
MaxRequestsPerChild 10000
</IfModule>
worker.local.type=ajp13
worker.local.host=localhost
worker.local.port=7001
worker.local.lbfactor=50 # 多个woker的时候这个的权重
worker.local.cachesize=100 #每个进程的连接池大小，最好和apache里每个进程的最大线程数一致
worker.local.cache_timeout=600
worker.local.socket_keepalive=1 #是否开keepalive
worker.local.recycle_timeout=300 #空闲连接的回收时间
参考 http://tomcat.apache.org/connectors-doc/reference/workers.html
[/text]
如果前面的很容易造成的情况是apache的jk把后端tomcat的链接数(400)撑爆了，但是实际上很多链接又闲着。主要是每个进程的信息是独立的，
每个进程最多能有100个连接，整体的量就很难控制，尤其是上面这个空闲连接的回收时间设置的不合理。实际测试就是把这个回收的时间缩短，改成1，然后把cachesize降低到50 效果就好了很多。