深度解析数据库连接The last packet successfully received from the server was *xxx* milliseconds ago

数据库连接The last packet successfully received from the server was *xxx* milliseconds ago"/>

深度解析数据库连接The last packet successfully received from the server was *xxx* milliseconds ago

相信很多人都遇到过这个问题，看到提示信息，或许大家都明白这不就是获取到的数据库连接超时了嘛，没错，问题的本质也的确如此，常见的解决办法也很简单，比如说从数据库连接池中获取连接的时候判断下连接状态是否正常，这样就可以避免此类问题的发生，如果都是此问题，那么就不会再有本文来赘述问题和解决方案，下面一起来看看造成该问题的几个原因和解决方法。

1.从连接池获取到超时的连接

从数据库连接池获取到超时的连接，目前这种情况大多数数据库连接池中间件都有相应的处理策略，一种是定期扫描连接池中的连接，探测到失效连接后剔除功能，这样可以保证连接池中连接的有效性。另一种则是从连接池中获取连接的时候再判断连接的有效性。这两种策略在连接池中间件中都是可配置的，只要配置好相关参数，这类问题基本可以消除。

2.连接池连接最大存活时长超过数据库配置

这个引起问题的情况不多，不过也不容易忽视，如果连接池中的连接时长超过数据库的配置，那么就会出现数据库已经关闭了该连接，但连接池中依然有效，业务获取到该连接后进行数据库操作，必然会出错。如果开启了从连接池获取连接时有效性校验，这个问题基本可以规避，不过此时性能会有所损耗，所以还是从配置上解决该问题较为合理。

3.长事务导致的超时

这类问题是相对比较少见的，但也不是不可能，我们知道，在Java应用中，进入事务方法后，就会获得一个数据库连接，此时获得的连接是经过检查的，所以当前状态是可用的，一旦在事务方法中做了比较耗时的操作，在超时时间内没有处理完，这个时候，这个连接已经被数据库关闭了，最后当业务执行数据库操作时就会收到一个标题的错误消息。

总结

第1、2类问题比较常见，而且目前都已有成熟的解决方案，但第三类属于编码层面的问题。而且长事务导致的这类问题比较隐晦，也比较难排查，因为大多数情况下不会出现，而且如果涉及到网络操作的，依赖于网络环境，时好时坏，就更难排查了。另外数据库连接是昂贵的资源，长时间占有会严重影响服务性能，而且还会引起其他线程获取连接超时的问题，所以，对于事务问题，时间要尽可能的短，才能让数据库连接发挥应有的作用。此类问题就是笔者维护的项目前人无意留下的“彩蛋”。

2023-05-02更

长事务导致连接超时的解决方案

对于长事务导致的连接超时问题有一种解决方案，就是区分“领域服务”和“业务服务”，将事务放置在领域服务层，领域服务层只处理当前领域逻辑和DB的逻辑，这样可以将一些IO操作放置在业务服务层处理，不会对领域服务层造成长事务的影响。以下是个人理解的“领域服务”和“业务服务”。

领域服务

领域服务和持久层一一对应，负责处理持久层需要的相关逻辑。

业务服务

可以聚合多个领域服务，处理跨领域服务的相关逻辑，同时可以支持跨领域服务的事务，保障数据的一致性。