分布式事务是非常核心的分布式系统，也是大厂经常考察对象，下面我就重点详解分布式事务及原理实现@mikechen
分布式事务
分布式事务指的是涉及多个独立服务的操作，这些服务可能分布在不同的节点、主机甚至不同的数据中心中。
如下图所示：
图片
上图一次大的事务操作，由不同的小事务操作组成，这些小事务的操作分布在不同的服务器上，这些操作要么全部成功，要么全部失败。
分布式事务的目标是确保跨多个服务的一系列操作要么全部成功，要么全部回滚，以保持数据的一致性和完整性。
分布式事务的关键问题是如何协调和管理多个服务之间的事务状态，以保证最终的一致性。
分布式事务实现方案
常见的分布式事务解决方案有两阶段提交（Two-Phase Commit，简称2PC）、TCC（Try-Confirm-Cancel）和消息队列等。
1.两阶段提交（Two-Phase Commit，2PC）
2PC是一种经典的分布式事务协议，在2PC中一个事务协调器（Transaction Coordinator）负责协调多个参与者（Participants）的操作。
2PC协议分为两个阶段：准备阶段和提交阶段。
图片
第一阶段：prepare
每个参与者执行本地事务但不提交，进入 ready 状态，并通知协调者已经准 备就绪。
第二阶段：commit
当协调者确认每个参与者都 ready 后，通知参与者进行 commit 操作，如果有 参与者 fail ，则发送 rollback 命令，各参与者做回滚。
2.TCC（Try-Confirm-Cancel）
TCC是一种基于补偿机制的分布式事务解决方案，在TCC模式中，每个服务都提供三个操作：Try（尝试）、Confirm（确认）和Cancel（取消）。
图片
第一阶段：CanCommit阶段
协调者向参与者发送CanCommit请求，参与者如果可以提交就返回Yes响应，否则返回No响应。
第二阶段：PreCommit阶段
协调者根据参与者的反应情况来决定是否可以继续事务的PreCommit操作。
第三阶段：DoCommit阶段
协调者基于每个参与者PreCommit阶段的反馈结果，决定真正提交事务，还是中断事务。
当一个事务涉及多个服务时，每个服务的Try操作会执行一系列预操作，如果所有服务的Try操作都成功，则执行Confirm操作，否则执行Cancel操作来回滚之前的操作。
TCC模式需要开发人员手动实现事务的补偿逻辑，适用于一些需要自定义补偿逻辑的场景。
3.消息队列
用消息队列作为分布式事务的解决方案，也是一种常见的方式。
在这种模式下，将事务操作封装成消息发送到消息队列，然后由消息队列来确保消息的可靠传递和处理。
如下图所示：
图片
消费者服务接收到消息后执行相应的操作，保证了数据的一致性，常用的消息队列包括：RabbitMQ、Apache Kafka等。
