问题描述
在Java应用中，周期性的出现后端报错 Caused by: com.mysql.jdbc.exceptions.jdbc4.CommunicationsException: Communications link failure，且伴随着The last packet successfully received from the server was 39 milliseconds ago. The last packet sent successfully to the server was 40 milliseconds ago.
通过排查堆栈日志最终锁定问题是由于 Caused by: java.net.SocketException: Connection reset at java.net.SocketInputStream.read(SocketInputStream.java:210)导致。
解决方案
因为实际的情况比较特殊，我先说下通用的解决方案：
通用方案：通常来说在Java应用报了Connection reset错误，主要是由于应用的响应服务器例如MySQL端出现了策略或者网络问题导致，堆栈日志可以证明： java.net.SocketInputStream.read(SocketInputStream.java:210)
可以看出是正在读取socket数据的时候，被rst拒绝了连接。
实际情况：因为使用了ProxySQL虚拟IP的代理模式，真实情况是由于后端虚拟IP频繁漂移导致的Java应用周期性报Communications link failure错误，解决虚拟IP漂移的就行。
原因分析
先通过架构图，简单介绍一下项目的网络架构
可以看到，在Java集群报了Connection reset错误。下面介绍问题的排查步骤及思路：
确认Connection reset根因
ProxySQL问题排查
一开始选择ProxySQL作为排查对象，检查了对应的错误统计，网络错误，超时配置，超长事务等等一系列的问题，调整参数后都没有解决问题。
MySQL问题排查
抓取MySQL错误日志和统计信息，也没有发现明显问题。
TCP抓包确认问题
在经历了上面的排查步骤后，发现这边所有的中间件不存在问题，所以从另一方面考虑是不是错误可能发生在Java应用端，考虑到Connection reset毕竟是Java封装的，虽然大部分情况都是由于被请求端的问题，但是在被请求端排查不到问题的情况下，考虑是请求端Java应用的问题，但是也不能确定，所以使用了TCP流量抓包。
在报错的应用服务器抓取和被请求端通讯的流量：
tcpdump -i any host 192.168.10.90 and port 3310 -w /tmp/java_80_to_90_3310.pcap
当然对应的MySQL也需要抓取，命令都类似。
最后在ProxySQL抓包的时候发现，可能是由于虚拟IP漂移的问题导致。
解决方案
最终锁定是Keepalived做虚拟IP的时候，需要在98和99都部署好Keepalived中间件，并且虚拟一个IP90注册到局域网，其实并没有90的真实服务器，所有的流量都是由98或者99来承接，每当虚拟IP从98转移到99或者相反转移的时候，Java应用正在执行的数据库操作确实会被瞬间切断，因为98和99是完全没有关系的两台服务器，有短暂少量的Communications link failure报错是正常的。
但是问题出在两边ProxySQL服务器正在运行的过程中，出现虚拟IP的频繁漂移，所以最终通过加入了Keepalive的容错机制也就是/etc/keepalived下面的配置文件修改，保证了Keepalive的检查脚本和心跳机制，即使出现短暂波动，也不会转移IP，当前出现极限情况，还是会转移。