目录
在技术面试中,经常会遇到像 “谈谈你对 seata 的理解” 这类问题。今天我们就来深入了解一下 seata。
一、分布式事务问题的产生
在微服务架构里,由于数据库和应用服务被拆分,原本在一个事务单元内的多个 DML(数据操作语言)操作,变成了跨进程或者跨数据库的多个事务单元的多个 DML 操作。传统的数据库事务无法处理这类问题,于是就引出了分布式事务的概念。
二、分布式事务的本质与常见解决方案
(一)本质
分布式事务的本质是解决跨网络节点的多个事务的数据一致性问题。
(二)常见解决方案
- 强一致性
所有事务参与者要么全部成功,要么全部失败。全局事务协调者需要知晓每个事务参与者的执行状态,据此决定数据的提交或回滚。不过基于 CAP 定理,强一致性方案会对应用的性能和可用性产生影响。 - 最终一致性(弱一致性)
多个网络节点的数据允许暂时不一致,但在某个最终时间点一定会达成一致。对于数据一致性要求不高的场景,通常会采用最终一致性算法。
三、分布式事务在实践中的实现方式
(一)强一致性实现
可通过基于 XA 协议下的二阶段提交来实现。
(二)弱一致性实现
可以基于 TCC 事务模型、可靠性消息模型等方案实现。
四、Seata 是什么
Seata 是阿里开源的分布式事务解决方案,它为我们提供了高性能且简单易用的分布式事务服务。
(一)Seata 中的分布式事务模型
- AT 模式
这是一种基于本地事务加二阶段协议来实现的最终数据一致性方案,也是 Seata 默认的解决方案。以下是一个简单的 Java 示例代码,展示在一个假设的基于 Spring Boot 和 Seata 的项目中如何使用 AT 模式(这里只是示例,实际项目中需要根据具体情况配置相关依赖和参数):
// 假设这是一个服务层的类,用于处理业务逻辑和事务相关操作
@Service
public class YourService {
@Autowired
private DataSource dataSource;
@Transactional(rollbackFor = Exception.class)
public void yourBusinessMethod() {
// 获取数据库连接,这里假设使用 Seata 自动管理分布式事务
Connection connection = dataSource.getConnection();
try {
// 这里执行你的业务逻辑中的 SQL 操作
PreparedStatement preparedStatement = connection.prepareStatement("INSERT INTO your_table (column1, column2) VALUES (?,?)");
preparedStatement.setString(1, "value1");
preparedStatement.setString(2, "value2");
preparedStatement.executeUpdate();
// 其他业务逻辑和数据库操作
} catch (SQLException e) {
e.printStackTrace();
// 如果出现异常,Seata 会根据 AT 模式的机制自动回滚事务
}
}
}
- TCC 模型
TCC 是 try、confirm、cancel 三个词语的缩写。简单来说,就是把一个完整的业务逻辑拆分成三个阶段,然后通过事务管理器在业务逻辑层面,根据每个分支事务的执行情况,分别调用业务的 confirm 或者 cancel 方法。 - SA 模式
在 SA 模式中,业务流程中的每个参与者都要提交本地事务,当出现任何一个参与者失败的时候,则通过补偿的方案把之前成功的事务参与者进行回滚。 - XA 模式
XA 可以认为是一种强一致性事务解决方案,它利用了事务资源(如数据库、消息服务等)对 XA 协议的支持,以 XA 协议的机制来管理分支事务的一种事务模型。
总的来说,Seata 是一个一站式分布式事务解决方案,在不同的业务场景中,我们可以使用它的不同事务模型来解决分布式事务问题。希望大家通过这样的分析,能在面试中遇到相关问题时回答得更加清晰有条理。