分布式事务是大型架构的基石，下面我重点详解分布式事务@mikechen
分布式事务
分布式事务指的是在分布式系统中，多个独立的数据库、或服务共同完成一个业务操作时。
需要保证所有操作要么全部成功，要么全部失败，简单来说，就是确保数据在多个节点之间的一致性。
例如，一个电商平台的订单创建流程，可能涉及以下服务：
- 订单服务：创建订单记录；
- 库存服务：扣减商品库存；
- 支付服务：处理支付。
如果这三个服务在一个业务流程中，当订单创建成功，但扣减库存失败了，那么就会出现用户下单成功，但实际上商品没有库存的问题。
为了避免这种情况，就需要使用分布式事务来保证。
分布式事务解决方案
为了应对上述挑战，业界提出了多种分布式事务解决方案，各有优缺点，适用于不同的场景：
两阶段提交 (2PC)
两阶段提交 (2PC)：通过一个协调者（Coordinator），来协调所有参与者（Participants）的操作。
整个过程分为两个阶段，如下图所示：
准备阶段（Prepare）：协调者首先询问所有参与者是否准备好提交，所有参与者都同意后，协调者再通知所有参与者进行提交。
提交阶段（Commit）：协调者根据所有参与者的反馈决定下一步。
优点： 尽量保证了强一致性。
缺点： 存在同步阻塞、单点故障（协调者）和数据不一致的风险。
比如：在第二阶段，如果协调者宕机、或网络分区，可能导致部分参与者提交，部分参与者未提交。
三阶段提交 (3PC)
3PC是对2PC的改进，引入了CanCommit阶段，并加入了超时机制，减少了阻塞时间。
CanCommit 阶段：协调者询问所有参与者是否可以执行事务，参与者只返回是否可以执行，不执行任何操作。
PreCommit 阶段：协调者收到所有参与者的肯定回复后，向它们发送预提交请求。
DoCommit 阶段：协调者发送正式提交或回滚请求。
优点： 解决了2PC的同步阻塞问题，降低了单点故障的风险。
缺点： 仍无法完全避免数据不一致，并且协议更复杂。
TCC (Try-Confirm-Cancel)
TCC是一种业务层面的分布式事务解决方案，它将一个完整的业务逻辑拆分为三个操作：
Try： 尝试执行，完成所有业务检查，并预留必要的业务资源。
Confirm： 确认执行，真正执行业务操作，不进行任何业务检查，只使用Try阶段预留的资源。
Cancel： 取消执行，释放Try阶段预留的业务资源。
优点： 实现了业务层面的数据最终一致性，性能较好，适用于长事务。
缺点： 侵入性较强，需要业务系统自己实现Try、Confirm、Cancel三个接口，开发成本较高。
消息队列最终一致性方案
通过消息队列来异步通知其他服务进行业务操作，从而达到最终一致性。
发送方完成自己的业务操作并发送消息，如果消息发送失败则回滚，接收方消费消息并执行自己的业务操作，如果执行失败则进行重试。
优点： 实现了服务的解耦，吞吐量高，性能好。
缺点： 只能保证最终一致性，不适用于对实时性要求极高的场景。需要考虑消息的可靠投递、幂等性消费等问题。