记一次dubbo连接超时分析

先来说说具体原因，具体原因就是provider端没有进行backlog设置，导致用的jdk默认配置50个，客户端超过百台，所以每次进行灰度发布后，客户端出现大量超时

这里dubbo的灰度发布我会单独写一篇文章在讲一下，这里暂且忽略

下面说下公司的应用场景

客户端以我们团队的为例，共有400台的客户端，服务端以用户团队为例，共有110多台

由于公司有个监控团队，会进行代码错误行统计，如果user每周进行二次发布，每次发布每台机器导致出现的链接超时报警统计为1条，则有400*110，就是44000，这样必定帮上有名了，这样导致团队压力巨大

那就想要进行线下模拟，先来说下异常出现的场景

服务端进行灰度发布，每次选择10台左右的数量，先进行服务端的下线，停服务，启动，上线

上线后，会通过zookeeper通知到客户端，这里会导致瞬间的链接压力

模拟

最初运维团队提供了大约50台测试机器，每台机器起两到三个进程，按照线上流程进行模拟，为出现异常

再次感谢运维团队，后来让运维团队提供了百台机器做测试机器，部署线上的服务，进行测试，问题重现

错误如下

并进行抓包

增加dubbo层nettyHandler中日志输出

增加netty层NioServerSocketPipelineSink中获取连接处的日志输出

netty层日志未见任何异常，dubbo层有断开连接的异常，最初怀疑是netty层boss线程处理不过来，但是分析抓包日志后，发现客户端发出syn包后，服务端没有给出及时响应，客户端必须要在次重发syn包

服务端的日志也同样说明了这个现象

基本断定是backlog太小了，导致服务端三次握手的队列太小了，开始进行系统层面的参数调优

cat /proc/sys/net/core/netdev_max_backlog cat /proc/sys/net/core/somaxconn cat /proc/sys/net/ipv4/tcp_max_syn_backlog

未起作用，同事说会不会是代码层面进行了配置，于是又去翻netty的源码，发现

这里未设置时是0，于是取jdk的默认配置为50个，修改该参数值，问题得以解决

正常的TCP链接