P0故障谁来背锅？

务?

在许多业务非常复杂的后台系统，经常频繁操作DB，为了保证数据的一致性，能够在出错时回滚数据，通常会使用事务。

就拿最简单的单机数据库事务来说。

在事务操作期间，如果持续时间过长，只有等事务结束之后，DB连接才会释放，此类长时间占用DB连接的事务操作，称为长事务。一旦外部有大量请求，并发调用此操作，那么将会有大量的DB连接被持有而没有被释放掉，直到连接池爆满。

这个时候，如果有其他请求到来，那十有八九是以失败告终。

也就是说，连接资源被少数长事务操作占用。在这种情况下，即使是最简单接口查询，都不能够正常进行。

几粒老鼠屎，坏了一锅粥。

一些魔幻的反应

当你去排查这种问题的时候，可能会陷入僵局。jstack显示，多数请求其实是阻塞在tomcat的线程池上，而且是一些访问速度非常快的请求被阻塞。

比如，tomcat的200个线程，有180个阻塞在耗时不到1ms的/status接口上。

很多人就一脸懵逼。经验失灵。

jstack此时的输出结果，欺骗了我们。真正造成阻塞的，是那额外的20多个线程。

有哪些改善?

保证事务的短小是一个基本要求，包括但不限于：

应控制慢查询的调用频率，尽量减少慢查询。很多情况下，这条规则是自欺欺人的，需要业务做一些妥协。

事务内不应包含任何RPC调用，减少事务的粒度。通常，一些RP

（编辑：常州站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!