1 缘起
补充事务相关知识过程中，
发现，默认的知识都是基于单体服务的事务，比如ACID，
然而，在一些复杂的业务系统中，采用微服务架构构建各自的业务，
就有了分布式事务的概念，比如，一致性在单体服务和分布式服务中的场景是有一定差别的，
但是，都是为了尽最大努力保证：原子性、一致性、持久化，
单体服务中事务的一致性是强一致性，而分布式服务的事务一致性会分为：强一致性、弱一致性和最终一致性，
因此，有必要学习下分布式事务相关的知识，
分享如下，帮助轻松应对知识交流和考核。
单体服务事务相关文章：
https://blog.csdn.net/Xin_101/article/details/102246522
https://blog.csdn.net/Xin_101/article/details/102240949
2 分布式事务
2.1 为什么
为什么会有分布式事务？
既是业务问题，又是技术问题。随着业务的多元化与复杂度的增加，在技术实现层面进行了合理的业务划分，当完成业务划分后，本应该在一个会话或命令空间中的操作，散落到各个服务中，于是，有了分布式事务相关的问题。
有人会想，这不是自己给自己挖坑吗？为什么要把服务分开，都在一起不就好了？其实，对于技术实现而言，只有相对合理，没有绝对边界，在这里挖坑的土，可能是填另外一个坑的原料，虽然业务拆分有分布式等相关问题，但是，也解决了一部分其他问题，比如服务耦合、服务庞大一荣俱荣，一损俱损等（微服务带来的优势）。
关于为什么有分布式事务这个问题以及方案，不同的业务会有不同见解，不是所有业务都要考虑分布式相关的问题，因地制宜即可，我们在学习或研究某些方案的过程中，不见得会立马用到，而是为了填充我们的知识库，当遇到问题时，多一些思路，多一些方案，最终解决问题。
2.2 方案
分布式事务方案可分为两类。
（1）基于事务的分布式事务方案；
（2）基于业务的分布式事务方案。
其中，
（1）基于事务的分布式事务是将各个事务串联，首先各个服务开启各自事务，然后执行CURD，将执行结果上报至统一事务管理器，统一事务管理器汇总各个事务结果，然后向各个事务发布提交或回滚的指令。
（2）基于业务的分布式事务在各自服务中维护完整的事务生命周期，与其他相关联的事务进行隔离，同时维护中间状态的数据，各个服务将各自的事务执行结果上报至统一事务管理器，统一事务管理器汇总各个事务结果，然后向各个服务发布提交或回滚的指令。
根据上述指导思想，出现了两种实际的方案：
两阶段提交和TCC。
2.1 两阶段提交（2PC，Two-phrase commit）
两阶段提交就是基于事务的分布式事务解决方案。
将分布式事务分成两个执行阶段：
（1）一阶段开启事务，执行操作；
（2）二阶段提交或回滚事务；
由统一事务管理器控制事务的执行。
2.1.1 一阶段
一阶段各个服务开启事务并执行相关的操作，将执行结果汇报给统一事务管理器，各个服务不会自动提交事务，只是上报执行结果。
一阶段执行示意图如下图所示，由图可知，
统一事务管理器接收到用户请求后，向各个本地事务管理器发送开启事务并执行CURD的指令，
在第一阶段，各个事务完成了除了提交的所有操作。
2.1.2 二阶段
二阶段统一事务管理器将各个服务事务的执行结果汇总，最终决定向各个事务发布提交或者回滚的指令；
（1）提交：全部服务事务执行结果均成功；
（2）回滚：任意一个服务事务出现失败；
提交
二阶段提交示意图如下图所示，由图可知，本地事务管理器将执行状态上报给统一事务管理器，
统一事务管理器综合处理后，给各个本地事务管理器发送指令，
当本地事务管理器的执行结果均成功时，统一事务管理器向各个本地事务管理器发送提交指令，
完成事务提交。
回滚
当任意一个本地事务管理器执行失败时，
统一事务管理器会向各个本地事务管理器发送回滚指令，
事务回滚。
2.1.3 存在的问题
（1）同步阻塞：当参与的事务使用公共资源时，其他事务参与者只能阻塞等待；
（2）单点故障：统一事务管理器出现故障时，整个系统不可用；
（3）数据不一致：二阶段，如果统一事务管理器只发送了提交指令，刚好网络异常，只有部分本地事务管理器接收到提交指令，另外一部分无法提交事务，数据不一致；
（4）不确定性：统一事务管理器发送提交指令后，部分本地事务管理器收到提交指令，刚好统一事务管理器和接收到提交指令的事务宕机，重新选举的统一事务管理器无法确定该消息是否提交成功。
2.2 TCC方案（Try-Confirm-Cancel）
TCC是基于业务的分布式事务方案。将完整的事务分成三个业务阶段独立维护执行：
Try-Confirm-Cancel。
其中，
Try：独立维护事务，操作预留数据，为后续提交或回滚做准备；
Confirm：独立维护事务，原始数据CURD，完成提交；
Cancel：独立维护事务，原始数据CURD，同时操作预留数据，完成回滚；
同样，需要一个统一事务管理器，基于业务的协调者，向各个独立的事务发布操作指令。
执行过程：
（1）提交：各个服务进入Try阶段，Try阶段全部执行成功，进入Confirm阶段，Confirm阶段全部执行成功：提交；
（2）回滚：各个服务进入Try阶段，Try阶段任意一个事务失败，进入Cancel阶段：回滚；
（3）回滚：各个服务进入Try阶段，Try阶段全部执行成功，进入Confirm阶段，Confirm阶段任意一个事务失败：回滚。
2.2.1 提交
TCC提交示意图如下图所示，由图可知，
基于业务的分布式事务，在各个服务中的各个阶段（Try，Confirm和Cancel），
维护自己的事务，执行完成后，将执行结果上报至统一事务管理器，
然后由统一事务管理器分发下一个阶段的指令。
（1）用户请求后，统一事务管理器将执行消息分发到各个服务，各个服务进入Try阶段，将Try阶段执行结果上报至统一事务管理器；
（2）统一事务管理器收集到Try阶段执行结果后，所有结果均是成功的，统一事务管理器向各个服务发送进入Confirm的指令，开始执行Confirm阶段的任务，各个服务将执行结果上报至统一事务管理器；
（3）统一事务管理器收集到Confirm阶段执行结果后，所有结果均是成功的，完成提交。
2.2.2 回滚
回滚则有两种情况：
（1）Try阶段异常：回滚；
（2）Confirm阶段异常：回滚；
Try阶段回滚
Try阶段回滚示意图如下图所示，由图可知，
（1）用户请求后，统一事务管理器将执行消息分发到各个服务，各个服务进入Try阶段，将Try阶段执行结果上报至统一事务管理器；
（2）统一事务管理器收集到Try阶段执行结果后，发现有Try异常，有Try正常，统一事务管理器向各个服务发送进入Cancel的指令，开始执行Cancel阶段的任务，完成回滚。
Confirm阶段回滚
Confirm阶段回滚示意图如下图所示，由图可知，
（1）用户请求后，统一事务管理器将执行消息分发到各个服务，各个服务进入Try阶段，将Try阶段执行结果上报至统一事务管理器；
（2）统一事务管理器收集到Try阶段执行结果后，所有结果均是成功的，统一事务管理器向各个服务发送进入Confirm的指令，开始执行Confirm阶段的任务，各个服务将执行结果上报至统一事务管理器；
（3）统一事务管理器收集到Confirm阶段执行结果后，有Confirm异常，有的Confirm正常，统一事务管理器向各个服务发送进入Cancel的指令，开始执行Cancel阶段的任务，完成回滚。
2.3 TCC操作分析
2.3.1 提交
提交操作应用的梳理，纠正了我对整个框架的理解，
（1）最终成功提交所有事务经历了TCC的完整过程；
（2）Cancel阶段是清空预留数据的，因为，Confirm必须保证全部执行才能清空预留数据，否则，无法回滚预留数据。
提交过程如下图所示，由图可知，
（1）统一事务管理器通知所有服务进入Try阶段：
Try阶段构建预留数据，不操作原始数据，所有服务均成功；
（2）统一事务管理器通知所有服务进入Confirm阶段：
Confirm阶段，根据预留数据操作原始数据，所有服务均成功；
（3）统一事务管理器通知所有服务进入Cancel阶段：
Cancel阶段，清空预留数据，提交事务。
2.3.2 Try回滚
Try异常回滚过程如下图所示，由图可知，
（1）统一事务管理器通知所有服务进入Try阶段：
Try阶段构建预留数据，不操作原始数据，服务1失败，服务2成功；
（2）统一事务管理器通知所有服务进入Cancel阶段：
Cancel阶段，服务1异常，没有提交事务，不用回滚数据，服务n清空预留数据，回滚数据。
2.3.3 Confirm回滚
Confirm回滚过程如下图所示，由图可知，
（1）统一事务管理器通知所有服务进入Try阶段：
Try阶段构建预留数据，不操作原始数据，所有服务均成功；
（2）统一事务管理器通知所有服务进入Confirm阶段：
Confirm阶段，根据预留数据操作原始数据，服务1失败，服务n成功；
（3）统一事务管理器通知所有服务进入Cancel阶段：
Cancel阶段，服务1清空预留数据，服务n回滚原始数据并清空预留数据，回滚数据。
3 小结
（1）两阶段分布式事务方案基于事务（数据库层面）的分布式方案，TCC分布式事务方案基于业务的分布式方案；
（2）两阶段提交是强一致方案，但是仍有数据不一致的情况，统一事务管理器存在单点故障问题，导致整个系统不可用；
（3）TCC是基于业务的方案，在业务层面，业务侵入性大，实现复杂；
（4）提交：所有阶段均成功；回滚：任意阶段出现异常、失败等。
【参考文献】
[1]https://xiaomi-info.github.io/2020/01/02/distributed-transaction/
[2]https://zhuanlan.zhihu.com/p/183753774?utm_source=wechat_session
[3]https://blog.csdn.net/qq_45066628/article/details/119192658