分布式事务
参考资料
https://baijiahao.baidu.com/s?id=1607829339793465291&wfr=spider&for=pc
TCC的介绍，一个看得懂的介绍
https://blog.csdn.net/kobejayandy/article/details/54783212
2PC
实现原理:
把事务的执行分为两个阶段，第一个阶段即 prepare 阶段，这个阶段实际上就是投票阶段，协调者向参与者确认是否可以共同提交，再得到全部参与者的所有回答后，协调者向所有的参与者发布共同提交或者共同回滚的指令，用以保证事务达到一致性优点：在于已经有较为成熟的实现方案，比如 XA。
缺点：XA 是一个阻塞协议。服务在投票后需要等待协调器的决定，此时服务会阻塞并锁定资源。由于其阻塞机制和最差时间复杂度高， 因此，这种设计不能适应随着事务涉及的服务数量增加而扩展的需要，很难用于并发较高以及子事务声明周期较长 (long-running transactions) 的分布式服务中。
举例子：A向B不同银行转账100元
- prepare阶段，check A,B账号可用，且A的余额大于100，确认之后，锁定A 和B的账号，锁定B账号的作用是防止其它线程对B账号发起禁用的操作。锁定A账号除了要保证余额足够（因为禁止发送变动）还保证A账号可用，不会被其它线程发起禁用操作。
- commit阶段：A扣款100，B增加100。A B账号释放锁，释放资源
TCC(事务补偿）
实现原理：引入了活动事务管理器，引入了一个try的阶段，只锁定事务本身需要的资源来确保事务正常进行。
TCC(Try-Confirm-Concel) 模型 [7] 同样是一种补偿性事务，主要分为 Try：检查、保留资源，Confirm：执行事务，Concel：释放资源三个阶段。
活动管理器记录了全局事务的推进状态以及各子事务的执行状态，负责推进各个子事务共同进行提交或者回滚。同时负责在子事务处理超时后不停重试，重试不成功后转手工处理，用以保证事务的最终一致性。举例子： A转账给C 100元
- try 阶段：查看 A、C账号可用，且A的余额大于100元，大于的话，冻结100元（这是核心啊，不是冻结A的所有存款，而是通过业务的手段只冻结100元，此时A账户的其它余额仍然处于可用的状态）
- commit阶段：A账号解除冻结且扣款100元，因为之前该现金已经处于冻结状态，所以肯定会扣款成功。C账号增加100元
- Canncel阶段：如果A扣款失败的话，需要回调C的回调接口，如果C增长失败的话，需要回调A账号的扣款成功。如果都成功，就不需要Cannel任何资源
事务消息（RocketMQ 4.3支持）
单应用多数据源的分布式事务
- 可以通过java的方式解决，设置不自动提交，然后开启事务，挨个提交，做好tryCatch，如果出现异常就回滚，可能要写补偿接口。如果A提交成功，B提交失败，那么需要调用A的补偿接口。
- JTA协议，atomikos 实现分布式事务，主要是DataSource要使用AtomikosDataSourceBean，管理器就可以实现。资源管理器绑定在一个公用的事务管理器上面，然后砽事务管理器 开启事务，执行事务，提交事务。
https://blog.csdn.net/benluobobo/article/details/49818017
