Appearance
什么是？
分布式事务是指涉及多个独立的系统或服务的事务操作。在分布式系统中，每个系统或服务都有自己的本地事务，但由于涉及多个系统之间的数据操作和一致性要求，需要确保这些本地事务要么全部提交成功，要么全部回滚。
传统的关系型数据库事务（ACID事务）只适用于单个数据库的情况，无法满足分布式系统中跨多个数据库或服务的事务一致性需求。在分布式环境下，由于网络延迟、部分节点故障等原因，要保证多个操作的一致性变得更加复杂。
分布式事务解决了这个问题，它提供了一种机制来协调多个参与者执行的事务操作，以确保最终一致性。在分布式事务中，通常会有一个协调者（Coordinator）和多个参与者（Participant）。协调者负责协调和管理事务的执行，而参与者执行具体的事务操作。
分布式事务的执行通常遵循以下流程：
- 事务发起：客户端或应用程序发起一个事务请求。
- 协调者创建事务：协调者创建一个全局唯一的事务标识，并将该标识发送给所有的参与者
- 参与者执行本地事务：参与者根据接受到的事务标识执行本地事务操作，并记录操作的undo和redo日志。
- 参与者反馈事务状态：参与者将事务操作的执行结果以及undo和redo日志发送给协调者。
- 协调者决策：协调者收集所有参与者的反馈，根据反馈信息进行决策。如果所有参与者都成功执行了本地事务，协调者发送提交请求；否则，协调者发送回滚请求。
- 参与者完成事务：参与者根据协调者的决策执行提交或会滚操作，并释放相关资源。
- 事务结束：协调者通知客户端或应用程序事务的最终结果。
分布式事务的实现方式有很多，常见的包括两阶段提交（2PC）、三阶段提交（3PC）、补偿事务等。每种实现方式都有其优缺点和适用场景，开发者需要根据具体需求选择合适的分布式事务方案。
总而言之，分布式事务是一种用于确保跨多个独立系统或服务的事务一致性的机制。通过协调者和参与者之间的协作，分布式事务可以实现多个操作的原子性、一致性、隔离性和持久性，保证分布式系统中的数据操作的正确性和可靠性。
两阶段提交（2PC）
两阶段提交（2PC）是一种经典的分布式事务协议，用于确保跨多个参与者的事务操作的一致性。它由一个协调者和多个参与者组成，在进行事务提交前需要经过两个阶段的协调和确认。
具体流程如下：
- 准备阶段： 协调者向所有参与者发送事务准备请求，要求参与者对事务进行准备操作，并在本地执行事务的准备工作，但不提交事务。如果所有参与者都成功完成准备，则向协调者发送"同意"消息；如果有任何一个参与者出现问题，向协调者发送"中止"消息。
- 提交阶段： 如果所有的参与者都已经准备就绪，协调者向所有参与者发送事务提交请求。参与者在接收到提交请求后，执行事务的提交操作，并释放相关资源。如果有任何一个参与者在准备阶段发生了问题或者协调者未能收到所有参与者的“同意”消息，协调者将发送中止请求，所有参与者将回滚之前的操作。
然而，两阶段提交存在着诸多问题，主要包括协调者单点故障、性能瓶颈以及长时间锁定资源等。为了解决这些问题，三阶段提交（3PC）被提出。
三阶段提交（3PC）
三阶段提交在两阶段提交的基础上增加了一个准备（canCommit）阶段，其具体流程如下：
- 准备阶段（canCommit）： 类似于两阶段提交的准备阶段，不同之处在于这一阶段不再等待参与者的响应，而是要求参与者预执行事务，并记录是否可以提交。
- 准备确认阶段（preCommit）： 协调者向所有参与者发送预提交请求，参与者在接收到请求后，检查自己的事务是否可以提交，然后向协调者发送“同意”或“中止”消息。如果所有参与者都发送“同意”，则协调者进入提交阶段；否则，协调者进入中止阶段。
- 提交阶段（doCommit）： 协调者向所有参与者发送正式的提交请求，要求参与者执行事务的提交操作。
尽管三阶段提交相对于两阶段提交解决了部分问题，但仍然存在着性能开销大、复杂度高等缺点。因此，在实际应用中，有时候会采用补偿事务来处理分布式系统中的事务一致性问题。
补偿事务是一种通过补偿操作来实现事务一致性的机制。在补偿事务中，当发现事务无法完成或者出现异常情况时，系统会执行相应的补偿操作来回滚或修正之前的操作，以确保系统最终达到一致的状态。补偿事务常用于处理分布式系统中的长时间事务或者无法保证强一致性的场景。