一次连接超时问题排查的历程

我们有一个 java 应用，启动的时候要初始化连接池，在连接一堆 sharding 过的 DB 时，经常会有一部分连接超时失败的，集中在一两台后端机器上，但每次失败的后端服务器却又不固定，也并不是每次启动都能遇到。超时时间设为了 50ms，看起来有点短但是对局域网，和压力并不算大的 DB 来说，这个时间已经长得匪夷所思了。后来尝试调大成 100ms，还是有失败的。但是如果启动成功后，却没再记录到过连接超时的情况。 排查网络问题首先是抓包，本来打算看看是不是对端响应慢有啥重传的，结果发现了更神奇的事情：发起 TCP 连接的 SYN 包不够数！也就是说，有几个连接根本连 SYN 包都没发出去过。还发现有一两个连接收到了 DB 服务器的 SYN/ACK 后，居然发了 RST ！所有服务器有响应的 SYN/ACK，包括被 RST 的，延迟都不到 0.2ms，速度挺正常的。那些个丢了的 SYN 和被 RST 的是怎么回事呢？ 然后再用 strace 套着启动试试。这回也顺带了解了 java 在 linux 上连接超时的实现方式。首先发起一个非阻塞的 connect，然后用 poll 来等待直到超时，如果超时，则把 socket shutdown 了。然而在 strace 的记录里，所有的 connect 系统调用一个不少，只是在 poll 的时候超时了。这倒是可以解释前面抓包里 RST 的原因。在服务端 SYN/ACK 返回的时候，客户端已经超时 […]