分布式事务

传统数据库事务

严格意义上的事务实现应该具备原子性、一致性、隔离性和持久性,简称ACID.

// 原子性（Atomicity)
可以理解为一个事务内的所有操作要么都执行，要么都不执行
// 一致性（Consistency）
可以理解为数据是满足完整性约束的，也就是不会存在中间状态的数据，比如你账上有400，我账上有100，你给我打200块，此时你账上的钱应该是200，我账上的钱应该是300，不会存在我账上钱加了，你账上钱没扣的中间状态.
// 隔离性（Isolation）
指的是多个事务并发执行的时候不会互相干扰，即一个事务内部的数据对于其他事务来说是隔离的。
// 持久性（Durability）
指的是一个事务完成了之后数据就被永远保存下来，之后的其他操作或故障都不会对事务的结果产生影响。

CAP定理

CAP定理表明，在分布式系统中，无法同时满足这三个要素，因此在设计系统时需要根据特定需求权衡这三个方面，选择最合适的策略。

// Consistency（一致性）
指的是分布式系统中的所有节点，在同一时间具有相同的数据视图。即使系统在发生更新后，所有节点也会立即看到最新的数据。
在一致性要求下，读取操作会返回最新写入的数据，确保系统中的所有节点在任何时刻看到的数据都是一致的.
// Availability（可用性）
指的是系统能够对用户的请求做出及时响应，并且在有限的时间内返回有效的结果。可用性保证系统在面对请求时能够继续提供服务，即使在出现部分故障或节点失效的情况下也不会影响系统的整体可用性。
// 分区容错性（Partition Tolerance）
指的是系统在面对网络分区（部分节点失去联系或无法通信）的情况下仍然能够继续运行。分区容错性保证了即使系统内部的通信发生故障或丢失连接，系统仍能够继续工作。

分布式事务

分布式事务顾名思义就是要在分布式系统中实现事务，它其实是由多个本地事务组合而成。在多个数据库中，可能会出现情况，在一个业务逻辑中，可能一个事务1已经提交成功，而另一个事务2提交失败，由于事务1已经提交无法回滚，就会导致数据不一致的情况.

分布式事务解决方案目前分为以下几种：

2PC

2PC（Two-phase commit protocol），中文叫二阶段提交。 二阶段提交是一种强一致性设计，2PC 引入一个事务协调者的角色来协调管理各参与者（也可称之为各本地资源）的提交和回滚，二阶段分别指的是准备（投票）和提交两个阶段。

// 阶段一
1.一阶段协调者会向所有参与者发送prepare请求。
2.各个参与者执行本地事务,但都不提交
3.返回协调者结果，会有两种可能：所有都返回Yes或者1个多个返回No。

// 第二阶段
// 分为2种情况：
1、如果所有参与者都返回成功，那么协调者向所有参与者节点发出Commit请求，参与者收到Commit请求，提交本地事物，并在完成提交之后释放整个事务执行期间占用的事务资源。
2.任何一个参与者向协调者反馈了No响应,或者等待超时之后,协调者尚未收到所有参与者的反馈响应。协调者向所有参与者节点发出RoollBack请求。参与者接收到RoollBack请求后,会回滚本地事务。

// 总结
第一阶段：通过协调者发送请求给各个服务，各个服务执行逻辑，但是暂时不提交本地事务，返回给协调者状态yes/no
第二阶段：协调者判断第一阶段返回的请求结果，如果全都为yes，则发送commit要求服务提交本地事务;如果存在no，则发送rollbak，要求服务回滚本地事务
// 优点
1.确保了分布式系统中的事务一致性，保证了所有节点要么全部提交要么全部回滚。
2.简单易懂，实现相对直观。
// 缺点
1.单点故障：事务协调者是2PC中的单点，一旦事务协调者发生故障，整个系统的可用性会受到影响。
2.性能问题：由于需要等待所有参与者响应，2PC可能会导致一些性能上的开销，特别是在大规模系统中。

3PC

3PC（Three-Phase Commit，三阶段提交）是在2PC的基础上发展而来的一种改进型分布式事务处理协议。它旨在解决2PC中的一些问题，尤其是在一些特殊情况下的阻塞和单点故障。

// 三阶段提交（3PC）的工作流程：
// 1.准备阶段（CanCommit Phase）
1.事务协调者（Coordinator）向所有参与者发送事务准备请求。
2.参与者收到请求后，执行事务的准备工作，并向协调者发送准备好（Ready）或未准备好（Not Ready）的响应。
// 2.准备提交阶段（PreCommit Phase）
事务协调者根据收到的所有参与者的响应情况进行判断：
1.如果所有参与者都准备好了，协调者向所有参与者发送可以提交的请求（Pre-Commit）。
2.如果任何一个参与者未准备好或者出现问题，协调者直接发送中止请求（Abort）。
// 3.提交阶段（DoCommit Phase）
1.如果协调者发送了预提交请求：
参与者在收到预提交请求后，再次确认自身是否可以提交。
参与者确认后，向协调者发送最终的提交请求。
2.如果协调者发送了中止请求：
参与者收到中止请求后，放弃执行事务并回滚本地事务。

// 优点
1.减少了2PC中的某些阻塞情况。如果在第一阶段中发现有参与者未准备好，直接中止事务，不必等待超时。
2.缩短了提交阶段的时间，避免了2PC中在第二阶段的不确定状态.
// 缺点
仍然存在单点故障问题。虽然3PC相对于2PC降低了某些阻塞情况，但仍然依赖于协调者的稳定性。
// 总结
尽管3PC相对于2PC有一些改进，但仍然存在单点故障和分区问题。因此，在实际的分布式系统中，可能会使用更为复杂的分布式事务协议或者采取其他方式来处理事务，以更好地满足系统的需求。

TCC

TCC（Try-Confirm-Cancel）是一种分布式事务处理的思想和模式，它通过将事务分解为三个步骤来实现分布式事务的一致性。

// 工作原理
// Try（尝试）
用于预留资源和执行业务检查.
在这个阶段，事务参与者尝试锁定资源、检查业务逻辑，但并不立即执行真正的操作。如果所有参与者都成功完成了“尝试”阶段，表示可以继续事务，否则会中止事务。
// Confirm（确认）
确认阶段用于执行实际的业务操作。
在此阶段，事务参与者执行之前预留的操作，确保资源被真正地使用或修改。如果某个参与者在确认阶段失败，可以进行回滚或补偿操作，确保一致性。
// Cancel（取消）
取消阶段用于回滚操作
如果在确认阶段某个参与者失败或者发生异常，需要执行取消操作，即回滚之前预留的资源或者撤销之前的操作。

可以看到流程还是很简单的，难点在于业务上的定义，对于每一个操作你都需要定义三个动作分别对应Try - Confirm - Cancel。
因此 TCC 对业务的侵入较大和业务紧耦合，需要根据特定的场景和业务逻辑来设计相应的操作。并且撤销和确认操作的执行可能需要重试，因此还需要保证操作的幂等。相对于 2PC、3PC ，TCC 适用的范围更大，但是开发量也更大。

事务消息

事务消息是一种用于在分布式系统中实现消息传递和事务性操作的机制。它能够确保消息在发送和接收之间的可靠传递，并且支持事务性地处理消息的发送和消费。

// RocketMQ 就支持了消息事务,以此为例说明.大致流程：
// 生产者发送半消息：
生产者将事务消息发送到RocketMQ Broker，Broker返回半消息的 ACK（发送成功的响应）。
// Broker响应发送成功
Broker收到半消息后，返回发送成功的响应给生产者。
// 生产者执行本地事务
生产者收到发送成功响应后，执行本地事务操作。
// 生产者发送本地事务结果
生产者向Broker发送本地事务的执行结果,执行Commit或Rollback 操作。
若Rollback操作则Broker会丢弃该半消息，不会投递给消费者。
若Commit操作则Broker将消息投递
// 订阅者接受该消息
执行本地事务：消费者接收到消息后，执行本地的事务操作。
若处理成功，则该事务消息算作完全提交；
若处理失败，需要采取其他手段来处理异常，比如采用补偿机制、人工介入等来解决已经提交的消息可能带来的问题.

总结

// 2PC
小规模系统或需要简单事务处理的场景。
不要求高性能和高可用性，可以接受同步阻塞的情况。
// 3PC
对于对2PC阻塞问题有所顾虑的场景，可以考虑使用3PC。
对系统性能和可用性要求不高的一些应用。
// TCC
对于需要更精细控制的业务场景，如金融交易、订单支付等。
需要高可用和高性能，可以灵活处理事务逻辑的场景。
// 事务消息
对分布式事务的一致性要求高，同时需要异步处理的场景。
需要可靠消息传递和确保一致性的异步操作。