Seata 的TCC 模式问题分析（待续）

Seata 后续：
1.TCC模式，t-try prepare c-confirm c-cancel,
2.除了TM 上面的@GloadTansational,注解外，各个的RM的接口上面要有@TwoPhaseBusinessAction(name=,commitMethod=,
   rollbackMethod=)
3.如果t,出现问题，则回滚执行rollback方法，如果c,出现问题了，就不回滚
4.T-papare-尝试去做，不真正的操作业务sql，或者业务字段，第一阶段的try，只是对目标字段的尝试，不会真正的操作
  目标字段。
  C-commit一定是要成功的，代码能走到第二阶段的提交，那么第一阶段的try是成功的，必然第二阶段的commit会成功的
  。死循环去调用，是TC去调用的
  C-rollback-一旦try逻辑失败，就会调用rollback吃，需要回滚的就是第一阶段try预留的值。
5.tcc模式常见的问题，
  1.空回滚问题，调用第一阶段try的时候，由于网路拥堵导致调用超时，调用失败，TM接收不到rm的第一阶段的回滚，
  就认为调用失败了，调用第二阶段的rollback,rm的第一个阶段的try并没有执行，空回滚了
  2.悬挂问题，就是在空回滚问题的基础上，rollback执行完了，执行业务的try又活了起来，不会在执行rollback第二次了
  3.幂等性问题，在commit的时候，成功了，但是因为网络异常，tc认为失败了，频繁的执行commit。
6.效率的问题，AT.模式有一个全局的锁，性能不高。