最近再看项目代码,发现很多的service里面,喜欢在事务内部再去调用HTTP请求,简单分析下此种方式的利弊与解决策略。
概述
在数据库内部嵌套TCP连接(一般是HTTP调用或是RPC远程调用)。
java
@Transactional(rollbackFor = Exception.class)
public Boolean inviteUser(..){
// service 调用
userService.add(..);
// HTTP调用
httpClient.post(..,20)
}
优点:
- 保障两个操作间的原子性、隔离性。
- 事务控制: 建立TCP连接可以使数据库管理系统更好地控制和监视事务。它可以跟踪连接的状态和事务的执行进度,从而更容易实现事务管理和恢复。
- 性能优化: 内部TCP连接可以针对特定的事务进行性能优化。例如,可以为事务分配更多的系统资源,以提高其执行速度。
- 安全性: 内部TCP连接可以通过加密和认证来增强安全性,确保只有授权的用户或应用程序能够访问数据库
弊端:
- TCP连接可能会超时,导致事务变成长事务。
- 网络抖动出现异常,可能会导致前一个正常的操作回滚。
- 资源消耗: 每个TCP连接都需要消耗系统资源,包括内存和处理能力。在高负载情况下,内部建立TCP连接可能导致资源耗尽,影响其他事务的执行。
- 连接维护开销: 维护大量的TCP连接可能会增加数据库管理系统的开销。每个连接都需要管理、维护和监视,这可能会导致性能下降。
- 复杂性: 内部TCP连接引入了更复杂的架构,需要更多的管理和维护工作。这可能需要更多的开发和管理工作,并增加了系统的复杂性。
- 连接延迟: 建立和维护TCP连接需要时间,这可能会导致事务的启动延迟。对于需要快速响应的事务,这可能是一个不利因素。
解决方案
评估审视多个操作调用之间是否有强一致性。
- 有强一致性
必须手动开启事务,根据HTTP调用的返回码进行手动事务提交或回滚。事务传播级别,尽量使用当前事务。
- 无强一致性
手动开启事务,或是使用自动事务注解,但最后可以通过事件监听器回调事务接口的afterCommit
方法,再进行HTTP调用。事务传播级别,尽量使用当前事务。