问题现象
在某个时刻，后端收到了平时4-6倍的请求（保密起见，略去产品和事件），在10分钟后居然没有请求可以接进来
问题原因
经过分析，首先，是后端服务器的线程池满了，线程池满的原因：
1.server.xml中maxthread=512,导致超过512的之后的请求只能排队，等待有线程释放后，才能被处理；
2.connectiontimeout配置为10000，这个配置导致建立一个socket连接后，如果一直没有收到客户端的fin，也没有数据过来，那么此连接也必须等到10s后，才能被超时释放，巧了，现网的客户端真的不会发fin包过来，那一直陪它耗够10秒,和1一起，处理的512个线程只能等待10s后，超时释放才能处理后面排队的请求，所以浪涌一来，分分钟就满了，特慢
接下来是怎么接不进来的呢？
部分用户忍不了了，发了个登出请求，依然在特慢的排队，部分进入了队列的客户端加上前面时间一共等了几秒都没响应，客户端就发了个fin过来，说要不咱主动断开算了，后端收到请求变为close_wait状态，说你等我会，处理点事，巧了，用户这几秒也受不了了，整个重启客户端，客户端ip再来就变了，结果后端处理好后的第三次握手本该通知"我处理好了，你断吧"的请求发不过去，好死不死，后台还配的重发15次，重发15次需要大概20~30分钟左右，啊哦，于是这条请求一直占着线程20多分钟，这样的请求多点，线程就一直占着，于是别的请求就一直就接不进来咯
问题解决
1.修改maxthread=1024，提高一倍的线程数
2.修改connectiontimeout=2000，没数据了之后2秒就断，别等这么久（keepalivetimeout是请求处理完了之后等多久关闭连接，connectiontimeout是本条连接等多久没数据关连接）
3.修改/proc/sys/net/ipv4/目录下的tcp_retries2文件为4，别重发15次了，一般也用不了这么多