目录
一、回顾
1.1 回顾
分布式从来都不是简单的东西。为此写本系列文章也耗费了笔者大量脑细胞，从第一节3月底到总结篇的6月初，耗时2个多月...用经验，结合学习、测试，总算完结了。
本系列从原理、规范、组件支撑、简单样例、源码剖析多角度分析分布式事务，让大家对分布式事务有正确的概念，行之有效的实操能力、常用解决方案，底层源码的深入剖析。
1.2 目标
如果说分布式事务这一块100分的话，理论最少占了40%，实践只占60%甚至更少。一个成熟的程序员应该清楚，分布式这一块有哪些概念原理，常见解决方案。遇到问题可以一眼就看破虚妄，找到问题所在，甚至直接脑子里就有对应的实现方案。
二、灵魂问答
对于分布式事务，常见问题：
2.1.什么是事务？
事务（Transaction）是数据库区别于文件系统的重要特性之一。目前国际认可的数据库设计原则是ACID特性，用以保证数据库事务的正确执行。Mysql的innodb引擎中的事务就完全符合ACID特性。
事务根据业务场景不同可分为本地事务，分布式事务。
2.2.什么时候需要加 本地事务/分布式事务？
当需要多个增删改业务操作，同时成功或失败回滚时。如果操作的是一个RM（资源管理器），那么就是本地事务。如果操作多个RM，那就是分布式事务。
2.3.本地事务如何实现？
大部分情况下，一个服务操作一个数据库，这就是本地事务（本地事务飞机票）。ACID特性由数据库提供支持，比如mysql innodb引擎。如下图所示（网上的图，挺好直接用）：
spring 提供了2种方式实现：
- 编程式：基于transactionTemplate去实现，适合手动精准控制事务的场景，少用。
- 声明式事务注解：@Transactional加在serviceImpl的方法上即可，这也是常用的方法。
2.4.分布式事务如何实现？
当遇到复杂业务调用时，可能会出现跨库多资源调用(一个事务管理器，多个资源)/多服务调用（多个事务管理器，多个资源），期望全部成功或失败回滚，这就是分布式事务，用以保证“操作多个隔离资源的数据一致性”。
分布式业务场景下，诞生了DTP模型、XA协议，以及引申出来的TM与RM之间的二阶段提交、三阶段提交。以及后来的CAP理论，BASE理论，大部分情况下为了追求性能，我们不会追求强一致性。
强一致性：如果应用服务器不支持分布式事务，那么可以借助第三方事务管理器实现，比如分布式事务（四）简单样例Spring Boot+Atomikos(TM)+Mybatis(ORM)+Mysql(DB)。
最终一致性：多种解决方案（具体见分布式事务（一）原理概览第六节）
- 正向幂等重试+反向异步回调（最大努力通知型）
- 可靠消息最终一致（异步确保型）
- TCC（两阶段补偿型）
三、不足
1.分布式的场景很多，不可能把每种源码都写出来。比如第一章的”最终一致性解决方案“，没有附上相关源码，读者可以根据方案介绍自行实现。
2.个人能力有限，有写的不对的地方，烦请指出，共同提高，壮哉我大Java!