高并发问题排查方案

我们的测试环境突然就不能承受一万并发量了

起因是我们的测试人员,在测试某个接口的时候,做了一万并发的压测,
第一次发送一万并发还都会正常响应,第二次发的时候就会部分请求错误了.
具体的错误是服务端拒绝连接,这就说明了并不是接口内部错误,而是资源不足

这个时候身为开发的我,就需要排查问题了.

第一步. 我排查了下 请求的速度 以及 请允许的超时时间

	一个请求响应大概在100毫秒内,这说明是个轻量级请求,完成能承受万级并发
	超时时间在测试环境我都有故意设大,整个架构链路设置成了60秒,所以可以排除.

第二步 cpu与内存

	我把所有链路里的容器内存和cpu占用都看了,使用率远远小于资源的限制,也可以忽略.

第三步 架构能承受的最高并发量

	从负载均衡到nginx-ingress在到nginx在到api服务最后到rpc服务以及缓存和数据库
	这些我也提早设置了最大并发量,每个端都有三个节点,每个节点最大并发量为1万,所以是能够承受住至少3万的并发的.

第四步 宽带

	我登录后台看了下,果然是宽带超了 哭笑不得
	但是为什么第一次并发一万宽带就没超,过了一会第二次一万就宽带超了呢

	随后 我去问了下 测试人员的测试思路
	他们使用的是jmeter测试,配置好请求,点击执行,过去了5千并发,
	过了一会,继续点击执行,又过去了五千并发.

	这超宽带的问题,就在这第二次的五千并发
	因为第一次请求的五千并发,由于还没有完全断开,
	在tcp还在保持连接的状态下
	它的保持活动（Keep-Alive）数据包 以及 拥塞控制机制、又或者是四次挥手
	都是需要占用小量的宽带的,但由于并发数上去,占用的宽带就不会那么小了.

	随后第二次一万并发来了,由于第一次的tcp连接还没有关闭,又创建了一万个新的tcp连接,所以当时最高的并发数已经不是一万了,而是到达了一万五左右.
	
	随后我写了一份脚本,交给测试人员测试,大概就是 一万并发过去后,等待5秒,
	会复用之前的连接,再次发送一万并发过去.
	这样的话那些tcp没断开的连接,就会重新使用,不会全部创建新的连接了.

	测试就成功通过了.

	又或者改变http的Keep-Alive策略,让其连接立马关闭,这样http当断开的时候,服务端也会立马关闭,不会保持活跃.
	
	但一般的情况下,其实前端发送http请求还是会使用Keep-Alive策略的,要不然每发送一次http请求,就真的完全去重新创建tcp连接,在请求发送频繁的情况下,这个开销远远大于保持连接.