根据这十来年的开发经验，在项目框架搭建的时候，一定贴合业务需要来搭建框架，绝不可上来就搞一个“四海皆可用”的超级微服务，分布式，高扩展的架构。要不然就会出现:开发人少了自己累，开发人多了，公司累的情况。
原则是：能用单体服务的，绝不用微服务，能nginx水平集群扩展的，绝不用微服务，就算用了微服务，能不拆分的就不要拆分，能一个人干 的活，绝不分成n多个人干。用微服务并不是了“微”而拆的，而是为了业务边界。比如订单和库存，强耦合，就放在一个服务里面，就不拆分，但是和物流服务边界就比较清晰了，可以把物流服拆分出来。
那为什么还要学习分布式事务呢？ 80%是为了面试，剩下的20%是为了涨知识，为以后可能用到做准备，因为可能刚入职的公司已经在使用了，你没得选择。
先来看一下事务的根本特性，ACID
主要的分布式方案及实现有：
1. 2PC事务模式
2PC是基于数据库实现的强一致性事务实现。
2PC （Prepare->Confirm）需要两步执行。它引入了一个事务管理者的角色，来管理各个微服务的事务执行。它有两个阶段：准备阶段和提交,回滚阶段，即准备->提交成功， 或准备->回滚，或准备->提交失败回滚。
第一阶段，事务管理者会发送一个准备命令，每个事务参与者收到命令之后，就会执行事务相关操作，开启事务流程，但是不会提交事务。然后都返回成功给管理者。
第二阶段，事务管理者根据各个事务参与者反馈的结果，如果反馈的都是成功，就会给所有的参与者再发送一个提交命令。如果有任何一个参考者反馈了失败，就会给所有参与者发送一个回滚的命令。参与者根据命令来执行提交或回滚。
它的优点是利用数据库本身的事务提交与回滚。不会侵入业务代码。完全由数据库完成事务的流程。
至于缺点也非常明显，因为在某个时间段内，存在事务未提交的状态，如果这个时间有更多的请求过来，那么这些请求将会被阻塞，并发量上不去。还有一个问题，如果有3个事务参与者，其中有一个失败了，那么其两个参与者还会正常执行事务但不提交，而且其它的事务百分之一百会再回滚，这样会造成一些资源上面的浪费。
因此，在2PC的基础之上，又增加了一个新的准备阶段，出现了3PC 的流程.
2. 3PC事务模式
3PC事务模式有三个阶段:
1. 准备阶段，用户来判断每个事务参与是否正常。
2. 预提交命令 （与2PC一样）
3. 提交或回滚 （与2PC一样）
2PC和3PC都是强一致的事务体现，一般在对强一致要求比较高的业务中使用这两个分布式事务，比如金融，为了保证资金安全，会使用这种强一致性方案。
3. AT事务模式
AT模式是基于最终一致性的技术方案。也是Seata最流行和最常用的事务解决方案，因为它对业务代码的侵入性比较小，并且能够提供良好的并发性能。
AT思想是基于UNDO LOG的最终一致性，在UNDO LOG中记录了数据的原始值，也就是数据快照，用于在事务回滚的时候恢复数据，可以分成两个阶段：
第一阶段：每个事务参与者执行事务的相关操作，并且直接把事务提交，同时把数据的原始值记录在undo log中，最后返回事务状态，成功或失败
第二阶段：协调者根据第一阶段的返回结果，成功就通知事务参与者异步删除undo log，如果失败，根据undo log恢复数据，再异步删除undo log。
这里说的undo log是Seata框架自动实现的，不需要开发人员介入，所以对业务代码的侵入性比较小，基本没有。
4. TCC事务模式
TCC 指的是Try, Confirm, Cancel ，也是业务层要实现的三个方法，所以它的代码侵入度非常高，要完全依赖于开发人员自己实现事务的相关过程。TCC分为两个阶段，第一阶段是资源检查预留阶段，第二阶段是提交或回滚阶段。因这它每个阶段都有事务提交，对比2pc阻塞力度变小了。说白了就是TCC就需要开发人员自己根据业务就实现每一步的操作，且每一步的操作是可以回滚的，就是命令模式一样，可以撤销某个操作。
第一阶段就像是考试时，先把题做一遍，但是答案先不写到答题卡上面，而是先写到草稿纸上面。
第二阶段会等第一阶段全部成功之后，再执行提交操作，相当于正式提交了。
比如创建了购买商品的订单，再 扣减库存的操作。在第一阶段可以先创建订单成功，状态是待支付，而库存并不是真正的扣减了，而是会设置一个冻结字段，当前字段先占用一定数量。到第二阶段时，订单状态不变，创建成功，库存再减少库存数量，然后冻结数量变为0，如果第一阶段有失败的，那就会回滚，删除已创建的订单，并删除冻结数量. 这些操作都需要开发都自己通过接口实现。
感觉TCC虽然代码入侵度高，与AT模式比起来 ，更加灵活些。
5. Saga事务模式
Saga模式是一种分布式异步事务，一种最终一致性事务，是一种柔性事务。
Saga事务模型又叫做长时间运行的事务（Long-running-transaction）, 它是由普林斯顿大学的H.Garcia-Molina等人提出，它描述的是另外一种在没有两阶段提交的的情况下解决分布式系统中复杂的业务事务问题。
每个Saga由一系列sub-transaction Ti 组成，每个Ti 都有对应的补偿动作Ci，补偿动作用于撤销Ti造成的结果
可以看到，和TCC相比，Saga没有“预留”动作，它的Ti就是直接提交到库。
比如有多个需要操作的事务，Saga只有两个阶段，它是一个事务一个事务按顺序执行的，一个事务执行完成之后，通过消息或事件通知下一个事务执行，如果都执行成功了，就没有第二阶段了，如果遇到一个执行失败的事务，那么第二阶段就是回滚之前已操作成功的事务。
因为每次都是执行且提交事务，那么在有些场景下，就需要考虑无法回滚数据的情况，特别是调用第三方的接口，比如发邮件，如果发邮件事务已执行成功，要回滚的话，只能再发一个撤销说明邮件。因为有可能之前的邮件已经被阅读了。
本地消息模式
本地消息方案也是最终一致性的方法，它的核心思想是：
第一阶段，在执行业务操作的同时，将相关的消息存储到本地消息表里面，然后通过异步的方式将消息发送到下游的服务中，下游服务开始执行自己的事务，执行成功或失败之后，更新消息表状态。状态一般是：待投递，投递成功，投递失败，执行失败，执行成功，待人工处理。
第二阶段，通过定时器，定期扫描待，投递失败，执行失败的消息，将这些消息重新投递到消息队列发送到下游服务。如果投递失败或执行失败，可以重试投递操作，至到达到最大重试次数，标记为待人工处理，或发送到死信队列，
Seata 是一款开源的分布式事务解决方案，致力于提供高性能和简单易用的分布式事务服务，它通过多种事务模式帮助开发者在分布式系统中保证数据一致性。
Seata 的核心组件包括Transaction Coordinator (TC)、Transaction Manager ™ 和Resource Manager (RM)，其中 TC 负责全局事务的协调与管理，以 Server 形式独立部署；TM 负责全局事务的启动、提交和回滚，集成在应用中；RM 负责管理本地资源（如数据库）并执行 TC 指令。
Seata 支持四种事务模式：
AT 模式（Automatic Transaction）：基于支持本地 ACID 事务的关系型数据库，通过两阶段提交协议实现，一阶段提交业务数据和回滚日志，释放锁；二阶段异步提交或通过回滚日志补偿。默认隔离级别为读未提交，可通过 SELECT FOR UPDATE 代理实现读已提交。
TCC 模式（Try-Confirm-Cancel）：要求每个分支事务提供自定义的 Try、Confirm 和 Cancel 逻辑，一阶段准备资源，二阶段提交或回滚。优势是灵活性高且无锁竞争，但需手动编写补偿逻辑，开发复杂度较高。
SAGA 模式：适用于长事务场景，每个本地事务独立提交，失败时通过补偿操作回滚已成功事务。优点是异步执行性能高，但一致性较难保证，需业务方处理补偿逻辑。
XA 模式：基于 XA 协议实现强一致性，通过两阶段提交协调资源。优点是符合 ACID 特性，但性能开销较大，资源占用多。
Seata 的设计目标是简化分布式事务管理，通过自动化的事务协调减少开发负担，适用于微服务架构中的跨服务数据一致性场景。
https://mp.weixin.qq.com/s/XDmcmCZKjzCOV1x2Cf9vvg
