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