AWS应用服务访问MySQL数据库报Communications link failure

       随着业务量上升，对于复杂SQL的查询，mysql耗时会越来越大，最近，在应用服务器日志中发现一些错误，其中主要错误信息是：

com.mysql.jdbc.exceptions.jdbc4.CommunicationsException: Communications link failure；

The last packet successfully received from the server was 7,214,362 milliseconds ago.  The last packet sent successfully to the server was 7,214,360 milliseconds ago.

        服务搭建基于AWS，使用了公司开发团队研发的数据库中间件，整个链路简单来讲就是：应用--->AWS_ELB--->数据库中间件--->mysql。

        错误仅发生在一些复杂的统计性SQL上面。由于能够稳定复现，排除了网络抖动的可能性。有认为是数据库连接超时，而且结合业务发现，连接建立后两个小时以后才爆出这个错误，通过检查发现，mysql各项配置并没有问题；而后认为是中间件存在bug，中间件开发人员通过日志分析，发现mysql成功返回了数据，但是时间比较长，有时候十几分钟，但是中间件的连接超时配置以及数据库配置都超过1小时，而且中间件日志显示获取到了数据也返回了，但是，应用端并没有成功获取到数据。

        日志信息表明，中间件和数据库之前并没有问题，那问题就缩小到了中间件和应用中间了。而后在应用与中间件的两端抓包，通过抓包分析，发现中间件拿到了数据并准备返回给应用，但是包发出去后，250微秒后收到了RST指令，而应用端并没有获得相应的数据包。期间测试过应用直连中间件，发现应用能够拿到结果，于是问题逐渐指向了LB这一层。

        通过AWS对于Network Load Balancers的说明，发现下面内容：

Connection Idle Timeout

For each request that a client makes through a Network Load Balancer, the state of that connection is tracked. The connection is terminated by the target. If no data is sent through the connection by either the client or target for longer than the idle timeout, the connection is closed. If a client sends data after the idle timeout period elapses, it receives a TCP RST packet to indicate that the connection is no longer valid.

Elastic Load Balancing sets the idle timeout value to 350 seconds. You cannot modify this value. Your targets can use TCP keepalive packets to reset the idle timeout.

 

        文档表明ELB设置连接默认的idle时间是350秒，且不能更改，可以通过发送TCP keepalive探测报的方法维持连接活性。而后应用服务器修改tcp keepalive时间以及频率，使keepalive探测包在350秒内就会发送并维持后续整个连接链路的活性，后续通生产环境运行发现问题得到解决。

        当应用与中间件建立连接时，经过ELB这一层，复杂查询，在没有查询缓存的情况下，耗时较长，因此中间件与mysql需要一些时间获取并组装数据，但是ELB侧，在超过350时，并没有向任何一段发送连接超时信息，当中间件拿到数据以后，向应用端返回，ELB侧就会马上返回RST响应包，但这时应用端没有收到响应，一直在等， 应用服务器配置的keepalive time 是7200秒，interval是14秒，因此，在应用服务器连接超过7214秒后，发送一个keepalive 的包后，收到RST包，并报出上面的错误。个人猜想，AWS并未在ELB这一层做这一工作应该就是为了提高效率，而其提供的CLB能够实现，但是性能却比ELB差很多。

        关于tcp keepalive详细信息可以参考：https://time-track.cn/tcp-keepalive-howto.html，这里有一个详解。

        个人的一些分析与见解，希望能为遇到同样问题的朋友提供一些帮助，同时如果有不对的地方请指正。