事务协调者 及 实际补偿执行的一些细节

[qcghdy]

朱: 看完整个文档，有几点理解需要确认下： 1、整个ET 提供的只是个框架，并没有一个 单独部署的的事务管理器吧？貌似是每个事务发起方通过维护excuted_trans. 并在框架层通过TransactionSynchronization来做事务调度。 2、你提到的ZK，没看懂主要用在哪里 3、服务被调方事务如果超时后，你是如何处理的？针对TCC模式

森林: 1、嗯，没有单独的事务管理器。事务管理在应用自身，每个APPID对应的实例作为事务管理器（处理crash recovery）

森林: 2、刚刚提到的，选出一个实例作为事务管理器，以及一些公共元数据的存储(目前为字符串编码的映射)，以及snowflaker取实例ID用

森林: 3、try超时的话，就抛异常，整个事务结束

森林: 其他的就重试

朱:

那我理解，事务发起方，这里的每一次调用transaction.execute。框架都有可能调用try、confirm、cancel 三个方法吧？

朱: 截图示例中，是调用了两次，那框架层面，是会先依次分别调两个try，都成功后，再依次调用confirm吧？

森林: 框架都能调用try,confirm,cancel

森林: confirm和cancel在全局事务状态确定后调用

森林: 1、嗯，没有单独的事务管理器。事务管理在应用自身，每个APPID选出一个实例作为事务管理器（处理crash recovery）

朱: 全局事务装也是记录在 事务发起方的executed_trans表中吧？

森林: 全局事务有没有完成通过 事务发起方的executed_trans表 判断

朱: 另外，刚才提到的zk，意思是，每个事务发起方的服务 的每个实例，都需要先注册到zk中吗？那谁需要通过zk获取到可用实例呢？

森林: 服务自身

森林: 服务自身获取同一appId下，还有其他什么实例

森林: 然后据此选出一个master

森林: 用以crashRecovery

朱: 意思是，假设你在3台机器上分别部署了 事务发起方的服务实例，那么三个实例都可以对外提供服务，发起事务。但补偿恢复的只能由其中1个实例来做，怎么选实例，则由zk来选。

对吧？

森林: crash导致的补偿恢复/执行异常导致的补偿恢复 由其中一个实例来做

森林: 正常情况下的补偿是在每个实例都会做的

森林: 嗯，选实例的逻辑主要在JAVA代码里，ZK只是辅助

森林: 问题可以直接提到GITHUB上

森林: 包括你刚刚那些

森林: 方便别人也可以看到

朱: 了解了。