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

[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上

森林:
包括你刚刚那些

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

朱:
了解了。