- 三阶段的第三阶段,即 commit/rollback:
XA COMMIT xid [ONE PHASE]
XA ROLLBACK xid
- 查看处于 PREPARE 阶段的所有事务:
XA RECOVER XA RECOVER [CONVERT XID]
================================================================================
seata 是阿里推出的一款开源分布式事务解决方案,目前有 AT、TCC、SAGA、XA 四种模式。
seata 的 XA 模式是利用分支事务中数据库对 XA 协议的支持来实现的。我们看一下 seata 官网的介绍:[1]
从上面的图可以看到,seata XA 模式的流程跟其他模式一样:
-
TM 开启全局事务
-
RM 向 TC 注册分支事务
-
RM 向 TC 报告分支事务状态
-
TC 向 RM 发送 commit/rollback 请求
-
TM 结束全局事务
这里介绍一下 RM 客户端初始化关联的 UML 类图:[2]
这个图中有一个类是 AbstractNettyRemotingClient,这个类的内部类 ClientHandler 来处理 TC 发来的请求并委托给父类 AbstractNettyRemoting 的 processMessage 方法来处理。processMessage 方法调用 RmBranchCommitProcessor 类的 process 方法。
需要注意的是,「seata 的 xa 模式对传统的三阶段提交做了优化,改成了两阶段提交」:
-
第一阶段首执行 XA 开启、执行 sql、XA 结束三个步骤,之后直接执行 XA prepare。
-
第二阶段执行 XA commit/rollback。
mysql 目前是支持 seata xa 模式的两阶段优化的。
「但是这个优化对 oracle 不支持,因为 oracle 实现的是标准的 xa 协议,即 xa end 后,协调节点向事务参与者统一发送 prepare,最后再发送 commit/rollback。这也导致了 seata 的 xa 模式对 oracle 支持不太好。」
================================================================================
seata 中的 XA 模式是使用数据源代理来实现的,需要手动配置数据源代理,代码如下:
@Bean
@ConfigurationProperties(prefix = “spring.datasource”)
public DruidDataSource druidDataSource() {
return new DruidDataSource();
}
@Bean(“dataSourceProxy”)
public DataSource dataSource(DruidDataSource druidDataSource) {
return new DataSourceProxyXA(druidDataSource);
}
-
也可以根据普通 DataSource 来创建 XAConnection,但是这种方式有兼容性问题(比如 oracle),所以 seata 使用了开发者自己配置 XADataSource。
-
seata 提供的 XA 数据源代理,要求代码框架中必须使用 druid 连接池。
当 RM 收到 DML 请求后,seata 会使用 ExecuteTemplateXA来执行,执行方法 execute 中有一个地方很关键,就是把 autocommit 属性改为了 false,而 mysql 默认 autocommit 是 true。事务提交之后,还要把 autocommit 改回默认。
下面我们看一下 XA 第一阶段提交的主要代码。
1)开启 XA
上面代码标注[1]处,调用了 ConnectionProxyXA 类的 setAutoCommit 方法,这个方法的源代码中,XA start 主要做了三件事:
-
向 TC 注册分支事务
-
调用数据源的 XA Start
xaResource.start(this.xaBranchXid, XAResource.TMNOFLAGS);
- 把 xaActive 设置为 true
RM 并没有直接使用 TC 返回的 branchId 作为 xa 数据源的 branchId,而是使用全局事务 id(xid) 和 branchId 重新构建了一个。
2)执行 sql
调用 PreparedStatementProxyXA 的 execute 执行 sql。
3)XA end/prepare
public void commit() throws SQLException {
//省略部分源代码
try {
// XA End: Success
xaResource.end(xaBranchXid, XAResource.TMSUCCESS);
// XA Prepare
xaResource.prepare(xaBranchXid);
// Keep the Connection if necessary
keepIfNecessary();
} catch (XAException xe) {
try {
// Branch Report to TC: Failed
DefaultResourceManager.get().branchReport(BranchType.XA, xid, xaBranchXid.getBranchId(),
BranchStatus.PhaseOne_Failed, null);
} catch (TransactionException te) {
//这儿只打印了一个warn级别的日志
}
throw new SQLException(
"Failed to end(TMSUCCESS)/prepare xa branch on " + xid + “-” + xaBranchXid.getBranchId() + " since " + xe
.getMessage(), xe);
} finally {
cleanXABranchContext();
}
}
从这个源码我们看到,commit 主要做了三件事:
-
调用数据源的 XA end
-
调用数据源的 XA prepare
-
向 TC 报告分支事务状态
到这里我们就可以看到,seata 把 xa 协议的前两个阶段合成了一个阶段。
这里的调用关系用一个时序图来表示:
看一下 RmBranchCommitProcessor 类的 process 方法,代码如下:
@Override
public void process(ChannelHandlerContext ctx, RpcMessage rpcMessage) throws Exception {
String remoteAddress = NetUtil.toStringAddress(ctx.channel().remoteAddress());
Object msg = rpcMessage.getBody();
if (LOGGER.isInfoEnabled()) {
LOGGER.info(“rm client handle branch commit process:” + msg);
}
handleBranchCommit(rpcMessage, remoteAddress, (BranchCommitRequest) msg);
}
总结:绘上一张Kakfa架构思维大纲脑图(xmind)
其实关于Kafka,能问的问题实在是太多了,扒了几天,最终筛选出44问:基础篇17问、进阶篇15问、高级篇12问,个个直戳痛点,不知道如果你不着急看答案,又能答出几个呢?
若是对Kafka的知识还回忆不起来,不妨先看我手绘的知识总结脑图(xmind不能上传,文章里用的是图片版)进行整体架构的梳理
梳理了知识,刷完了面试,如若你还想进一步的深入学习解读kafka以及源码,那么接下来的这份《手写“kafka”》将会是个不错的选择。
-
Kafka入门
-
为什么选择Kafka
-
Kafka的安装、管理和配置
-
Kafka的集群
-
第一个Kafka程序
-
Kafka的生产者
-
Kafka的消费者
-
深入理解Kafka
-
可靠的数据传递
-
Spring和Kafka的整合
-
SpringBoot和Kafka的整合
-
Kafka实战之削峰填谷
-
数据管道和流式处理(了解即可)
a”》将会是个不错的选择。
-
Kafka入门
-
为什么选择Kafka
-
Kafka的安装、管理和配置
-
Kafka的集群
-
第一个Kafka程序
-
Kafka的生产者
-
Kafka的消费者
-
深入理解Kafka
-
可靠的数据传递
-
Spring和Kafka的整合
-
SpringBoot和Kafka的整合
-
Kafka实战之削峰填谷
-
数据管道和流式处理(了解即可)
[外链图片转存中…(img-3uwKfpwF-1719247924820)]
[外链图片转存中…(img-HHRmtmCZ-1719247924820)]