linux设置网络连接重连次数为无限次,记一次应用访问数据库超时的问题分析（涉及linux的keepalived机制和TCP重传机制）...

先来了解下系统部署方式：

1)这个系统使用的应用连接的是我们备用数据库；

2)备用数据库目前只给这个系统的应用使用。

下面进行两组简单的测试：

1)本地PLSQL连接，过一段时间后会断掉。(排除应用侧问题)

2)将应用配置成访问主用数据库，问题现象消失(排除应用侧问题+1)

好了，排除了应用侧的问题，那么问题就集中在了数据库侧，通过与网络工程师沟通，备用数据库独立用了一台硬件防火墙，其他都是共用的，和主库无差异。

问题基本就定位到这了：

1)备用数据库上层防火墙问题(网络工程师排查，防火墙配置与主库一致)

2)备用数据库问题(数据库工程师排查，数据库配置与主库一致)

好了，大家都说没问题，那我们就只能通过分析拿数据说话了。-----------------------------------------------------

进入正式测试阶段：

1)断开应用外部流量，重启应用，应用和DB服务器都建立了连接。

2)过几小时后，应用的连接还在，DB服务器的连接都没有。

what？DB服务器你凭什么断我应用连接啊？你断我也不告诉我吗？！！！

通过抓包发现，DB服务器当时是发送了keepalived检测消息，但是应用你没有收到啊。(DB大写的冤枉~~)

嘿，防火墙你出来，我(应用)为什么没有收到？

3)此时，通过访问请求页面已打不开，一直在请求中，通过在应用侧抓包发现，应用有发送请求给DB，DB却也没有收到。(DB你可以出来，也骂一顿应用了，哈哈)

啦啦啦：这个时候，一切的定位都指向了防火墙，等把防火墙挪掉就知道了，问题到这里基本就定位结束了。

PS：其实后来又做了一次测试，就是连接建立后过30分钟，应用和DB两侧连接都是正常的，但是前端请求就访问不了了，即DB还没触发keepalived机制，应用就触发了TCP重传机制，所以更可以说明问题不在应用和DB两侧了。

加餐话题

想知道DB是过了多久断开的吗？应用又是连了多少次才重新建立连接的吗？他们的检测机制又是什么样的呢？

加餐开始：

1、DB端的断开机制。

DB作为服务端，当2小时内都没有收到客户端(应用)的请求，就会触发操作系统的keepalived机制。

具体如下：

net.ipv4.tcp_keepalive_time = 7200 #2小时后，开始发起ack检测

net.ipv4.tcp_keepalive_probes = 9 #一共进行9次检测

net.ipv4.tcp_keepalive_intvl = 75 #每次检测间隔75秒

抓包示例：

发起的keepalived检测一共发起了9次，每次75秒，一共花费了10分钟，当都没有收到响应，就会发起RST结束当前连接。

也就是说，应用和DB建立的连接，在没有外部请求的情况下，通过DB和应用之前通讯断开的情况下，DB会在2小时10分钟后断开连接。

2、应用端的重连机制。

当外部没有请求的情况下，应用作为客户端，之前建立的连接始终“保持着”。

当外部发起请求时，会触发TCP重连机制。

具体如下：

Linux重传机制：

最小重传时间是200ms

最大重传时间是120s

重传次数为15

不信你看：

中间省略。。。

timer:(on,9.794ms,15) 具体含义分别是：TCP重传机制开启，重传倒计时，重传次数。

抓包示例：

再来看看最后一次的重传时间：

可以看出，在重传第15次后，还需要再等2分钟后，确定没收到才要关闭，即10:31:58 第16次是自我关闭连接(不再发送消息)。

通过命令分析出来的和LINUX自身的TCP重传机制(图片来自网上)其实是一样的：

可以看出，一个连接的TCP重传机制需要花费15.4分钟，才能重新创建连接。

所以，到这里，就可以解释为什么上面说的，当客户反应访问不了，过一段时间后就又可以访问的现象了。

这里应用和DB保持着10个连接，当DB侧全部超时后，第一个请求过来，会选择其中一个空闲的连接，触发了TCP重传机制，需要等待15.4分钟。一个客户访问页面可能会触发N个请求，那么就会等待15.4*N分钟。

即用户可以打开页面的时间需要等待15.4分钟~154分钟。

原文：https://blog.51cto.com/shengjian/2498970