mytcc 2 seata 书

1 书总结：

 

 

 

 

争议：

rpc先还是注册TC先，本质是RM在rpc的客户端还是服务端？

RM需要向TC上报状态？

RM上报的状态是否影响全局？还是由TM统一处理全局？

try冻结的余额还可用吗？

confirm和cancel重试本地驱动还是远程驱动还是联合驱动？

 

结论：

TM决定全局

TC也可发起超时全局回滚，不过有可能还会收到TM发来的全局提交/回滚，我就不在TC处理了

 

 

不重要：

AT怎么处理空回滚和幂等-事务日志；没有日志不执行回滚；

前后镜像与业务sql/事务日志同一个本地事务（只读事务）

autocommit

AT如何全局读已提交——select for update AOP，拿全局锁

AT流程：

　　代理

　　解析sql

　　前镜像for update（防止前后镜像中间有独立事务改数据）

　　执行

　　后镜像no for update（因为update等已经拿到锁了）

　　全局锁（应该快速失败，释放数据库锁）

　　事务日志

　　提交

AT二阶段提交先放锁，再删事务日志

 

 

 

2 rpc先还是注册先

 我的结论：

rpc先于分支事务注册，出现空回滚的概率与1一样，但悬挂的可能非常小（不是没有，看“RM另一种可能”）

seata用的是2

 

3 seata会不会空回滚，https://seata.apache.org/zh-cn/blog/seata-tcc/

 

seata的RM注册由RPC的服务端进行，不存在分支注册后RPC调用失败

seata会出现空回滚甚至空提交，但不是这种形式；出现在seata call TC注册失败超时时，try就不执行了，但TM是有可能：

向TC发出回滚，TC调用RM回滚方法

向TC发出提交指令的（比如TM吞掉rpc的异常），然后TC调用RM提交方法——空提交

 

 

4 同库模式，https://seata.apache.org/zh-cn/blog/seata-tcc-fence/

上报状态是多余的；注册是不是多余的？

 

有两个问题：

“然后向TC发送消息获取全局事务状态”-TC都发消息了，肯定状态已经有了，为什么要多一次查询？

不注册TC怎么找到RM？

顺着逻辑，唯一的可执行方案是：

不注册，TC也不发消息给RM，RM直接每秒轮询TC

 

 

 5 强调下显而易见又容易忽略的异步提交/回滚

try执行完成后，分布式事务即返回客户端，接下去就靠重试对账人工了，confirm和cancel异步执行必须成功