连接池设置错误导致的问题
1.故障背景
故障表现1
打开页面时，偶现阻塞住，但是刷新后又正常了（第一次进去页面卡住）
查看日志
其实是超时了，超时的日志没打印出堆栈，通过jstack也可以看到代码阻塞在socket0
故障表现2
在上传文件前调用check接口时偶现超时（这个接口很快），一次可能是网络问题，但是经常出现就不一定是网络问题了，这个接口通常就几毫秒就返回了。
总结问题的现象：
1.有时候第一次进应用页面时页面一直在加载中，但是刷新后又没问题，后面再怎么操作都没问题了；
2.过一段时间不操作，重新又进入页面，又会重复上述问题，而且问题出现即为频繁；
总结下整个服务的流程：
1.取数服务抓取需要计算的数据，打包成zip文件
2.取数服务调用计算sass服务的check接口，主要是校验目前计算sass服务的负载是否大，返回true说明负载不大，计算sass可以接受服务；为false则取数服务会重试check，一直到check为true（有个时间限制3小时）； ----调用这里超时了
3.调用上传文件接口将数据传输给计算sass服务；
2.原因分析过程
代码问题分析
首先检查是不是自己写的代码的问题，因为httpclient这块做了简单的封装，虽然底层都是基于httpclient，上层是被封装的
private CloseableHttpClient createHttpClient(HttpTemplateConfig httpTemplateConfig) {
RegistryBuilder<ConnectionSocketFactory> registryBuilder = RegistryBuilder.create();
Registry<ConnectionSocketFactory> registry = registryBuilder
.register("http", PlainConnectionSocketFactory.getSocketFactory())
.register("https", SSLConnectionSocketFactory.getSocketFactory()).build();
PoolingHttpClientConnectionManager cm = new PoolingHttpClientConnectionManager(registry);
cm.setMaxTotal(httpTemplateConfig.getMaxTotal());
cm.setDefaultMaxPerRoute(httpTemplateConfig.getDefaultMaxPerRoute());
Map<String, RouteConfig> routes = httpTemplateConfig.getRoutes();
if (routes != null)
routes.forEach((name, routeConfig) -> {
HttpRoute route = HttpTemplateUtils.determineRoute(routeConfig.getHostname(), routeConfig.getPort(), routeConfig.getScheme());
cm.setMaxPerRoute(route, routeConfig.getMaxPerRoute());
});
return HttpClients.custom()
.setConnectionManager(cm)
.evictIdleConnections(3600, TimeUnit.SECONDS)
.evictExpiredConnections()
.setRetryHandler(new DefaultHttpRequestRetryHandler(0, false))
.build();
}
.................
通过检查没发现代码中存在的问题，唯一觉得不靠谱的地方就是
最后也是因为这块的原因，刚开始只是怀疑，但是没证据，只能当没问题处理，然后把底层的代码撸了一遍，这块其实和线程池很像，空闲的连接/失效的连接定时任务会定期清理，看了一下底层清理的代码：
遍历所有可用的连接，如果这些连接是不可用的/空闲的就清理，这些代码都是底层代码，如果有问题也轮不到我们发现，所以从代码上分析不出问题了。
2.容器问题分析
因为线上取数服务是K8S部署的，所以怀疑可能是K8S的问题，网上找到一篇文章，没看懂，但是怀疑是不是网络设置这块会有问题，上面的现象也有点类似，也是偶现的
https://blog.csdn.net/Jerry_Pan1990/article/details/103201866
但是逼迫我需要用抓包工具去验证了，为了验证是不是这个原因，通过抓包工具tcpdump来验证问题
3.网络问题分析
先看了nginx日志和业务日志，比较麻烦，这里的过程就省去了
tcpdump可以抓取这个机器上所有入和出的网络包，因为测试环境的来源太多（客户端调用的地方太多了），所以必须加一些条件去监控,如果调用方的ip是：127.0.0.1,接收方的ip为：127.0.0.2，则
进入127.0.0.1服务器，这个服务器是调用方
tcpdump dst host 127.0.0.1
进入127.0.0.2服务器，这个服务器是接受方
tcpdump src host 127.0.0.1 and dst port 443
当页面一直load的情况
127.0.0.1监控结果：
127.0.0.2监控结果：
没有收到信息
在前端刷新后：
127.0.0.1监控结果：
127.0.0.2监控结果：
现象总结：
页面卡住的那次，信息发出去了，但是接收端没收到信息，这个连接会一直等待到超时(5分钟)；再刷新一次，发现端口号变了，其实就是新建了一个连接，这个接口没问题，因为我们系统用的是连接池，所以这个连接会一直使用，除非这个连接被使用了，才会新开连接。
这里的P.和FP.，搜索了下FP其实就是销毁这个连接，验证一下连接是否是复用的多请求几次：
用的都是同一个连接，所以连接池是生效的，到这里问题大概定位出来了
根本原因：
目前设置的连接池超时时间是3600s，意思是每3600s定时任务才会将空闲/过期的连接删除，而tcp协议中，客户端和服务端的连接，服务端定时会将连接删除（四次挥手），这样就导致了其实服务端已经将这个连接断开了，但是客户端不知道，还维护这个连接，然后通过这个连接请求后服务端没法收到这个接口的响应而超时，一旦超时后，客户端会认为这个连接已经失效了，客户端会把这个连接从连接池中移出掉，所以后面的请求也正常了。
解决方案：
1.连接池定时扫描的时间设置为 < 服务端断开的超时时间，
挥手超时时间一般是大于30s的，这里我们设置为10s，10会清理空闲的连接池，保证客户端不会使用已经过期的连接
- 加keep-alive保活(此方法不需要)
通过谷歌浏览器请求后端接口，请求表头会自动带这个表头
这个表示该连接不关闭，下一次请求还是会复用这个连接，但是也会有风险，理论上客户端连接是不会断开的，但是保不齐服务端因为各种原因,例如服务端网络挂了，机器重启等，就会导致这个连接池维护的客户端连接其实已经失效了，而客户端是没法知道这个情况的，会导致拿这个连接去请求的话就会有问题了。
连接池为什么需要定时清理机制：
很难保证。传统阻塞I/O模型，只有当I/O操做的时候，socket才能响应I/O事件。当TCP连接交给连接管理器后，它可能还处于“保持连接”的状态，但是无法监听socket状态和响应I/O事件。如果这时服务器将连接关闭的话，客户端是没法知道这个状态变化的，从而也无法采取适当的手段来关闭连接。
针对这种情况，HttpClient采取一个策略，通过一个后台的监控线程定时的去检查连接池中连接是否还“新鲜”，如果过期了，或者空闲了一定时间则就将其从连接池里删除掉。ClientConnectionManager提供了 closeExpiredConnections和closeIdleConnections两个方法。
所以最后的问题还聚焦到了这个连接池的连接为什么会失效？
搜索了一些资料，因为后端http调用协议是http1.1，所以默认不指定用的就是keep-alive方式，连接按道理来说是不会失效的，然后找了下连接可能失效的几个可能：
1.tomcat关闭
据说默认是60s，但是测试过1分钟没啥问题，所以感觉又不是tomcat的问题
2.nginx关闭连接
去测试环境找到nginx配置
好家伙看到了配置，10分钟，正好和我们平时遇到的问题的时间有点差不多，抓包看了下大概也是10分钟后端会发送断开连接的报文
然后去看了下线上的配置
线上的时间是3600s，难怪线上超时问题比测试环境要低，这个时间和连接池的时间一样（设置相同还是概率会遇到，连接池轮训时间应该要小于这个时间）。
3.云商中间环节关闭（可能性最大）
因为通过netstat检测到客户端和服务端的连接都是存在的，没有关闭，所以云商中间环节关闭这个连接可能性比较大
https://learn.microsoft.com/zh-cn/azure/load-balancer/load-balancer-tcp-reset
4.防火墙关闭
尝试关闭防火墙后问题还有，所以应该不是这个问题
.......
3.总结
1.为增大并发，线上的连接断开时间尽量短一点，例如nginx的timeout时间设置10分钟内比较合适，太长的话会占用大量无用的资源；
2.客户端的空闲连接失效时间要小于服务端的超时时间，可以设置为一半，避免服务端主动释放连接后，客户端感知不到拿失效的连接去请求导致超时的异常，误认为是网络问题导致
