之前 看过了 tm端的 AT模式的 事物的开始 commit 与rollback 的代码 接下来 看看 这些请求的下一个要去的地方 server。这个是用来决定 事务 到底是执行 commit 还是 rollback 的东东 同时还会记录 undo日志(数据操作前的原始数据)
先从 第一个接口 事务开启说起
可以看到是一个抽象的方法 看看他的实现类
可以看到只有一个 实现类 是 DefaultCoordinator
看看这个方法 做了啥
可以看到 调用core对象的 begin方法 并设置 xid。在此可以知道 xid是在这里生成的
看看 这个core的begin方法 做了啥
首先是 new了一个session 出来 然后 添加了 sessionmanager的监听器 然后调用begin方法
这里会调用 监听器的 onbegin方法 点进去之后 发现是
下面的writesession 方法
可以看到 是 往db或者 file里面写入 session 这里可以注意一点 如果 你是 分布式的 设计 使用seata的时候 server就不能 写到文件里了 要使用数据库 但是你 单机除外(应该没人会用 单机吧)
下面是一个eventbus post的方法 进去看看做了啥
这个发布了一个事件。通过 @Subscribe 找到 他的 订阅方 (用于没有用spring的框架 所以没用 spring的 订阅发布模式 我个人 比较喜欢 spring的)
获取了 map中对应的方法 因为是begin。那就是调用 第一个 begin
点进去之后 是 一个map 维护的计数器
看到使用的是 atomiclong。不过 阿里开发手册 建议 用longadder 至于两者区别 自己看去吧 简单说一下 在并发下 longadder 性能要比 前者好 实现原理 自己看去
最后是就 begin 的结尾了 返回 xid 到此 begin 就结束了 接下来 看看 commit
假设 现在 我们的业务代码 已经 开启 然后 全部执行成功 接下来 就是 执行 commit 方法了
这里 首先 通过 xid 去寻找 session。这里肯定能找到(按照正常流程)
这里就看到了 如果 你使用文件存储 不使用数据库 在分布式模式下 极可能出现session 为null的情况 我感觉 这个地方 少了校验。 应该 在请求来的时候 带上 存储类型 如果 是文件 还是分布式 那应该报错 (谨代表个人观点) 但是 你要是 改造一下 使用 流去读取 远程文件。也是可以的
如果是 begin 则 将状态 改为 commiting 并返回true
这里尝试 去 异步 commit 进去看看做了啥
可以看到 如果是 tcc模式 返回false 就是 tcc模式 不能 异步 这里埋个疑惑 为啥 tcc不能呢
上面就是 执行 commit 的方法了
这里不说了 应该还是 计数
这里判断是否是 saga模式 即长事物模式
这里看到 如果是第一阶段 失败 则 继续循环 不继续执行
这里是继续执行的代码 开始 发送请求 到 rm端了
是异步的发送请求出去
下面的代码 是 判断 返回的内容是否成功
这里成功 则移除这个session
这里 是 发送之后 当返回的内容 是不重试
我们看看 失败之后的处理
跟到下面 是讲session的状态 改为失败 并保存
我们来看看 这个 方法
看名字 应该是 放到队列里面 在重试
放到这个监听里面 降状态 改为重试
最后看看 真正的 commit 成功 之后的代码
将session 改为成功 并重写到 db
至此commit 方法就结束了 接下来 看看。回滚的方法
Rollback
这里可以看到 先调用了 close 方法 上面有一段话
意思是 先关闭 session。然后其他的 分支 就不能注册到这个session 上来了 因为要回滚了嘛
还是放到了 监听者里面
这里 当判断 状态 是begin 时候 表示可以 回滚了
上面 是具体的 回滚的方法。
跟提交方法 类似 只是调用的接口 不一样了 其他的重试 就不说了 但是 这个方法 下面 有一段话
意思是 当 db中 事物回滚(这里说的是 存储session的db) 会导致 数据不一致的问题会发生 (为认为是小概率事件 但是 不代表不会发生)
好了 至此已经 结束了 server 端的代码分析 大厂真的是大厂 好贴心
