什么是分布式事务?

典型回答

分布式事务是指在分布式系统中涉及到多个数据库或多个应用程序之间的事务处理，这些数据库或应用程序可能分布在不同的物理节点上，甚至可能位于不同的地理位置。在分布式事务中，需要确保所有参与者的事务操作都能够保持一致性，即所有参与者的事务要么全部提交成功，要么全部回滚。
举个例子，假设一个电商系统，用户下单后需要扣减库存、扣减账户余额、生成订单等操作。在单机环境下，可以将这些操作放在同一个事务中，保证原子性、一致性和持久性。但在分布式环境下，可能存在多个服务(如库存服务、账户服务、订单服务)分布在不同的物理节点上，此时需要确保所有服务操作的事务都能够同步进行，避免出现数据不一致的情况。

为了解决分布式事务的问题，出现了一些分布式事务解决方案，如XA协议、TCC事务、最大努力通知等。这些解决方案的实现方式各不相同，但都需要考虑如何确保所有参与者的事务操作能够保持一致性，以及如何处理可能出现的异常情况。

常见的分布式事务有哪些?

分布式事务的目的是保证分布式系统中的多个参与方的数据能够保证一致性。即所有参与者，在一次写操作过程中要么都成功，要么都失败。
至于这个一致性到底是怎样的一致性，是强一致性、还是最终一致性，不同的分布式事务方案其实达到的效果并不相同。
如果想要实现强一致性，那么就一定要引入一个协调者，通过协调者来协调所有参与者来进行提交或者回滚。所以，这类方案包含基于XA规范的二阶段及三阶段提交、以及支持2阶段提交。

1、有了2阶段提交为什么还需要3阶段提交?

阶段提交(Two-phaseCommit)是XA分布式事务中一个重要的方案，二阶段提交的算法思路可以概括为:参与者将操作成败通知协调者，再由协调者根据所有参与者的反馈情报决定各参与者是否要提交操作还是中止操作。
所谓的两个阶段是指:第一阶段:准备阶段(投票阶段)和第二阶段:提交阶段(执行阶段)。但是2PC本身存在着同步阻塞问题、单点故障问题、数据不一致问题等，所以在二阶段的基础上，增加了一个预提交的阶段，组成了3阶段提交的方案。

---

如果想要实现最终一致性，那么方案上就比较简单，常见的基于可靠消息的最终一致性(本地消息表、事务消息)、最大努力通知等

---

如何基于本地消息表实现分布式事务?

本地消息表其实也是借助消息来实现分布式事务的。
这个方案的主要思想是将分布式事务拆分为本地事务和消息事务两个部分，本地事务在本地数据库中进行提交或回滚，而消息事务则将消息写入消息中间件中，以实现消息的可靠投递和顺序性。
般来说的做法是，在发送消息之前，先创建一条本地消息，并且保证写本地业务数据的操作，和，写本地消息记录的操作在同一个事务中。这样就能确保只要业务操作成功，本地消息一定可以写成功。

然后再基于本地消息，调用MQ发送远程消息。
消息发出去之后，等待消费者消费，在消费者端，接收到消息之后，做业务处理，处理成功后再修改本地消息表的状态。
这个过程中，可能有几个步骤都可能发生失败，那么如果失败了怎么办呢?

1、2如果失败，因为在同一个事务中，所以事务会回滚，3及以后的步骤都不会执行。数据是一致的。
3如果失败，那么就需要有一个定时任务，不断的扫描本地消息数据，对于未成功的消息进行重新投递
5如果失败，则依靠消息的重投机制，不断地重试。
6、7如果失败，那么就相当于两个分布式系统中的业务数据已经一致了，但是本地消息表的状态还是错的。这种情况也可以借助定时任务继续重投消息，让下游幂等消费再重新更改消息状态，或者本系统也可以通过定时任务去查询下游系统的状态，如果已经成功了，则直接推进消息状态即可。

---

可靠消息实现最终一致性的方案其实就是借助支持事务消息的中间件，通过发送事务消息的方式来保证最终一致性，过程及原理可以参考:

RocketMQ的事务消息是如何实现的?

RocketMQ的事务消息是通过TransactionListener接囗来实现的。
在发送事务消息时，i首先向RocketMQ Broker发送一条“half消息”(即半消息)，半消息将被存储在Broker端的事务消息日志中，但是这个消息还不能被消费者消费。
接下来，在半消息发送成功后，应用程序通过执行本地事务来确定是否要提交该事务消息。
如果本地事务执行成功，就会通知RocketMQ Broker提交该事务消息，使得该消息可以被消费者消费;否则，就会通知RocketMQ Broker回滚该事务消息，该消息将被删除，从而保证消息不会被消费者消费。

拆解下来的话，主要有以下4个步骤:

1. 发送半消息:应用程序向RocketMQ Broker发送一条半消息，该消息在Broker端的事务消息日志中被标记为prepared”状态.
2. 执行本地事务:RocketMO会通知应用程序执行本地事务。如果本地事务执行成功，应用程序通知RocketMQ Broker提交该事务消息，
3. 提交事务消息:RocketMO收到提交消息以后，会将该消息的状态从“prepared”改为“committed”，并使该消息可以被消费者消费，
4. 回滚事务消息:如果本地事务执行失败，应用程序通知RocketMQ Broker回滚该事务消息，RocketMQ将该消息的状态从“prepared”改为“rollback”，并将该消息从事务消息日志中删除，从而保证该消息不会被消费者消费。

---

另外，还有我们比较熟知的TCC，他也是最终一致性的一种实现方案。只不过他比基于消息的最终一致性要稍微更加靠近强一致性一些。或者说他的不一致性的时长会更短。

什么是TCC，和2PC有什么区别?

TCC是Try-Confirm-Cancel的缩写，它是一种分布式事务解决方案，采用了基于业务逻辑的补偿机制，将整个分布式事务分解为若干个子事务，每个子事务都有一个try、confirm和cancel三个操作，通过这些操作来实现分布式事务的执行和回滚

具体来说，TCC事务包括以下三个步骤:

1. Try:在try阶段，参与者尝试执行本地事务，并对全局事务预留资源。如果try阶段执行成功，参与者会返回一个成功标识，否则会返回一个失败标识。
2. Confirm:如果所有参与者的try阶段都执行成功，则协调者通知所有参与者提交事务，那么就要执行confirm阶段，这时候参与者将在本地提交事务，并释放全局事务的资源
3. Cancel:如果任何一个参与者在try阶段执行失败，则协调者通知所有参与者回滚事务。那么就要执行cancel阶段。

以下是一个简单的TCC事务的例子，假设有一个转账服务，需要从A账户中转移到B账户中100元、C账户中200元:

1. Try阶段:转账服务首先尝试将A账户的金额冻结300元
2. Confirm阶段:如果所有的try操作都执行成功，转账服务将尝试执行解冻并转账，将金额转到B账户和C账户中
3. Cancel阶段:如果try过程中，某个转账事务执行失败。那么将执行解冻，将300元解冻。如果在confirm过程中，A->C的转账成功，但是A->B的转账失败，则再操作一次C->A的转账，将钱退回去。

TCC这种事务方案有以下优缺点:

优点:

1. 灵活性:TCC适用于不同类型的业务场景，例如账户转账、库存扣减等，能够根据业务逻辑实现精细的事务控制。
2. 高可用性:TCC使用分布式锁来保证分布式事务的一致性，即使其中一个节点出现故障，也不会影响整个系统的运行。
3. 可扩展性:TCC采用分阶段提交的方式，支持向扩展，可以适应更多的并发访问和业务场景。4.性能:TCC相对于2PC来说，具有更好的性能表现

缺点:

1. 实现复杂:TCC需要实现Try、Confirm和Cancel三个操作，每个操作都需要实现正确的业务逻辑和补偿机制，代码实现比较复杂。
2. 存在悬挂事务问题:TCC的实现方式存在悬挂事务的问题，即在执行过程中可能会有部分子事务成功，而其他子事务失败，导致整个事务无法回滚或提交。
3. 空回滚问题:TCC中的Try过程中，有的参与者成功了，有的参与者失败了，这时候就需要所有参与者都执行Cancel，这时候，对于那些没有Ty成功的参与者来说，本次回就是一次空回滚。需要在业务中做好对空回滚的识别和处理，否则就会出现异常报错的情况，甚至可能导致Cancel一直失败，最终导致整个分布式事务失败。
4. 业务代码侵入性:TCC需要将事务操作拆分为Try、Confirm和Cancel三个步骤，对业务代码有一定的侵入性，需要针对不同的业务场景进行实现。

---

另外，还有一些分布式事务的组件，如Seata，他其实是一个开源的分布式事务解决方案，旨在为微服务架构提供高效且透明的事务管理。在讨论 Seata 的一致性特性时，需要明确其支持的不同事务模式，因为每种模式对一致性的保证不同。

什么是Seata?他有哪几种模式?

Seata是一个阿里开源的分布式事务解决方案(Simple Extensible Autonomous Transaction Architecture)用于在分布式系统中实现分布式事务。它旨在简化分布式事务的开发和管理，帮助解决分布式系统中的数据一致性问题。

Seata的实现原理

因为Seata的开发者坚定地认为:一个分布式事务是有若干个本地事务组成的。所以他们给Seata体系的所有组件定义成了三种，分别是Transaction Coordinator、Transaction Manager和Resource Manager
[ransaction Coordinator(TC):这是一个独立的服务，是一个独立的JM 进程，里面不包含任何业务代码，它的主要职责:维护着整个事务的全局状态，负责通知 RM 执行回滚或提交;
[ransaction Manager(TM):在微服务架构中可对应为聚合服务，即将不同的微服务组合起来成一个完成的业务流程，TM 的职责是开启一个全局事务或者提交或回滚一个全局事务;
Resource Manager(RM):RM 在微服务框架中对应具体的某个微服务为事务的分支，RM 的职责是:执行每个事务分支的操作。