分布式事务问题？问题场景引入

如图：订单系统中的本地事务A，远程调用了库存系统中的本地事务B；如果事务A遇到了问题，事务A会回滚，但是事务B如果正常执行，不会回滚，这就产生了问题：

订单创建是失败的，订单确实没有生成，但是库存却减少了；这显然要出问题

显然我们想要实现的是：要么一起执行完，要么一起回滚掉，这样就不会产生问题。所以如何解决这个问题？

如图：订单系统中的本地事务A，远程调用了库存系统中的本地事务B；如果事务A遇到了问题，事务A会回滚，但是事务B如果正常执行，不会回滚，这就产生了问题：

订单创建是失败的，订单确实没有生成，但是库存却减少了；这显然要出问题

显然我们想要实现的是：要么一起执行完，要么一起回滚掉，这样就不会产生问题。所以如何解决这个问题？

分布式事务的理论标准

BASE理论

ACID只适合于本地事务，对于分布式系统来说，应该有全新的标准 ==> BASE

附：acid理解

BASE Transaction

Basically Available（基本可用）、Soft-state（ 软状态/柔性事务）、Eventual Consistency（最终一致性）

BASE是基于CAP定理演化而来，是对CAP中一致性和可用性权衡的结果。核心思想：即使无法做到强一致性，但每个业务根据自身的特点，采用适当的方式来使系统达到最终一致性。

1. 基本可用：指分布式系统在出现故障的时候，允许损失部分可用性，保证核心可用。但不等价于不可用。比如：搜索引擎0.5秒返回查询结果，但由于故障，2秒响应查询结果；网页访问过大时，部分用户提供降级服务等。
2. 软状态：软状态是指允许系统存在中间状态，并且该中间状态不会影响系统整体可用性。即允许系统在不同节点间副本同步的时候存在延时。
3. 最终一致性：系统中的所有数据副本经过一定时间后，最终能够达到一致的状态，不需要实时保证系统数据的强一致性。最终一致性是弱一致性的一种特殊情况。BASE理论面向的是大型高可用可扩展的分布式系统，通过牺牲强一致性来获得可用性。（事务的ACID是传统数据库常用的概念设计，是追求强一致性模型）。

If we call transactions that satisfy ACID features as hard transactions, then transactions based on BASE features are called soft transactions. BASE is the abbreviation(n.略语;缩写词;缩写形式;) of basically available（基本可用）, soft state（持久化写入没必要一定要写入一致） and eventually consistent（最终一致） those there factors.

1. Basically available feature means not all the participants（n. 参与者; 参加者;）of distributed transactions have to be online at the same time.
2. Soft state feature permits some time delay in system renewal（n. 恢复; 更新; 重新开始; (对合同等的) 有效期延长，展期，续订; 改进; 复兴; 振兴;）, which may not be noticed by users.
3. Eventually consistent feature of systems is usually guaranteed by message availability.

• 补偿

compensation：n. 补偿(或赔偿)物; (尤指) 赔偿金，补偿金; 赔偿; 使坏的情况变好的事物; (对不利局面的) 补偿;

补偿就是指的一个事务中的某个一个操作片段。具体说来可以是一个远程的操作，也可以是一个本地的操作，可以是一个更新操作，也可以是一个取消操作。

eg: 比如我把500元从某个银行卡账户转入到微信钱包。那么对微信这边的转入接口进行的操作便是一个补偿操作。比如直接去调用现有的远程接口就是一种补偿操作。

附CAP理论

CAP理论指的是一个分布式系统最多只能同时满足一致性（Consistency）、可用性（Availability）和分区容错性（Partition tolerance）这三项中的两项。

• C: Consistency,强一致性。在分布式系统中的所有数据备份，在同一时刻具有同样的值，所有节点在同一时刻读取的数据都是最新的数据副本。

• P: Partition tolerance,分区容错性。分布式系统中的某个节点或者网络分区出现了故障的时候，整个系统仍然能对外提供满足一致性和可用性的服务，也就是说部分故障不影响整体使用。（分布式必然是模块系统分离使用网络的，网络有必然会有延迟等问题，这就会影响集群内的数据同步，即影响强一致性）

• A: Availability,可用性。好的响应性能，完全的可用性指的是在任何故障模型下，服务都会在有限的时间内处理完成并进行响应；从用户角度来看就是不会出现系统操作失败或者访问超时等问题。

CAP原理指的是，这三个要素最多只能同时实现两点，不可能三者兼顾。因此在进行分布式架构设计时，必须做出取舍。而对于分布式数据系统，分区容忍性是基本要求，否则就失去了价值。因此设计分布式数据系统，就是在一致性和可用性之间取一个平衡。对于大多数web应用，其实并不需要强一致性，因此牺牲一致性而换取高可用性，是目前多数分布式数据库产品的方向。当然，牺牲一致性，并不是完全不管数据的一致性，否则数据是混乱的，那么系统可用性再高分布式再好也没有了价值。牺牲一致性，只是不再要求关系型数据库中的强一致性，而是只要系统能达到最终一致性即可，考虑到客户体验，这个最终一致的时间窗口，要尽可能的对用户透明，也就是需要保障"用户感知到的一致性"。通常是通过数据的多份异步复制来实现系统的高可用和数据的最终一致性的，"用户感知到的一致性"的时间窗口则取决于数据复制到一致状态的时间。

CP & AP的选取

• CA: 优先保证强一致性和可用性，放弃分区容错。这也意味着放弃系统的扩展性，系统不再是分布式的，有违设计的初衷。
• CP: 优先保证一致性和分区容错性，放弃可用性。在数据一致性要求比较高的场合(譬如:zookeeper,Hbase) 是比较常见的做法，一旦发生网络故障或者消息丢失，就会牺牲用户体验，等恢复之后用户才逐渐能访问。
• AP: 优先保证可用性和分区容错性，放弃一致性。NoSQL中的Cassandra就是这种架构。跟CP一样，放弃一致性不是说一致性就不保证了，而是逐渐的变得一致。

‌网络分区必然性‌：分布式系统中网络分区（P）是客观存在的，系统必须容忍分区故障‌。

C与A的互斥性‌：当分区发生时：

• 选择一致性（C）：需阻塞请求直到数据同步完成，牺牲可用性‌
• 选择可用性（A）：允许先返回旧数据，牺牲强一致性‌

Two-phase Commit，2PC

两阶段提交协议（two phase commit protocol，2PC）可以保证数据的强一致性，许多分布式关系型数据管理系统采用此协议来完成分布式事务。它是协调所有分布式原子事务参与者，并决定提交或取消（回滚）的分布式算法。同时也是解决一致性问题的一致性算法。该算法能够解决很多的临时性系统故障（包括进程、网络节点、通信等故障），被广泛地使用。

2PC系统组件

1. 协调者coordinator，通常一个系统中只有一个
2. 事务参与者 participants，cohorts或workers，一般包含多个

两阶段执行过程

1. 阶段1：请求阶段（commit-request phase，或称表决阶段，voting phase）
   • 在请求阶段，协调者将通知事务参与者准备提交或取消事务，然后进入表决过程。在表决过程中，参与者将告知协调者自己的决策：同意（事务参与者本地作业执行成功）或取消（本地作业执行故障）。
2. 阶段2：提交阶段（commit phase）
   • 在该阶段，协调者将基于第一个阶段的投票结果进行决策：提交或取消。当且仅当所有的参与者同意提交事务协调者才通知所有的参与者提交事务，否则协调者将通知所有的参与者取消事务。参与者在接收到协调者发来的消息后将执行相应的提交或取消操作。

例子说明：A将成为该活动的协调者，B、C和D将成为该活动的参与者。

1. 阶段1
   • A发邮件给B、C和D，提出下周三去爬山，问是否同意。那么此时A需要等待B、C和D的邮件。
   • B、C和D分别查看自己的日程安排表。B、C发现自己在当日没有活动安排，则发邮件告诉A它们同意下周三去爬长城。由于某种原因， D白天没有查看邮件。那么此时A、B和C均需要等待。到晚上的时候，D发现了A的邮件，然后查看日程安排，发现周三当天已经有别的安排，那么D回复A说活动取消吧。
2. 阶段2
   • 此时A收到了所有活动参与者的邮件，并且A发现D下周三不能去爬山。那么A将发邮件通知B、C和D，下周三爬长城活动取消。
   • 此时B、C回复A“太可惜了”，D回复A“不好意思”。至此该事务终止。

2PC缺点

1. 同步阻塞：最大的问题即同步阻塞，即所有参与事务的逻辑均处于阻塞状态。
2. 单点：协调者存在单点问题，如果协调者出现故障，参与者将一直处于锁定状态。
3. 脑裂：在阶段2中，如果只有部分参与者接收并执行了Commit请求，会导致节点数据不一致。

Three-Phase Commit，3PC

3PC，三阶段提交协议，是2PC的改进版本；协调者、参与者都引入了超时机制；三阶段 CanCommit、PreCommit（其中一个超时或者执行失败，则发起中断）和doCommit

优缺点：降低了参与者同步阻塞范围，但是又引入了数据不一致性问题（若出现网络分区）、单点问题依然存在；

三阶段执行过程

1. CanCommit阶段

3PC的CanCommit阶段其实和2PC的准备阶段很像：协调者向参与者发送commit请求，参与者如果可以提交就返回Yes响应，否则返回No响应。

2. PreCommit阶段

Coordinator根据Cohort的反应情况来决定是否可以继续事务的PreCommit操作。

根据响应情况，有以下两种可能。

A.假如Coordinator从所有的Cohort获得的反馈都是Yes响应，那么就会进行事务的预执行：

发送预提交请求。Coordinator向Cohort发送PreCommit请求，并进入Prepared阶段。
事务预提交。Cohort接收到PreCommit请求后，会执行事务操作，并将undo和redo信息记录到事务日志中。
响应反馈。如果Cohort成功的执行了事务操作，则返回ACK响应，同时开始等待最终指令。

B.假如有任何一个Cohort向Coordinator发送了No响应，或者等待超时之后，Coordinator都没有接到Cohort的响应，那么就中断事务：

发送中断请求。Coordinator向所有Cohort发送abort请求。
中断事务。Cohort收到来自Coordinator的abort请求之后（或超时之后，仍未收到Cohort的请求），执行事务的中断。

3. DoCommit阶段

该阶段进行真正的事务提交，也可以分为以下两种情况:

执行提交

A.发送提交请求。Coordinator接收到Cohort发送的ACK响应，那么他将从预提交状态进入到提交状态。并向所有Cohort发送doCommit请求。
B.事务提交。Cohort接收到doCommit请求之后，执行正式的事务提交。并在完成事务提交之后释放所有事务资源。
C.响应反馈。事务提交完之后，向Coordinator发送ACK响应。
D.完成事务。Coordinator接收到所有Cohort的ACK响应之后，完成事务。

中断事务

Coordinator没有接收到Cohort发送的ACK响应（可能是接受者发送的不是ACK响应，也可能响应超时），那么就会执行中断事务。

TTC(Try-Confirm-Cancel)

• DML <—> try : 预留业务资源
• Commit <—> confirm : 确认执行业务操作
• Rollback <—> cancel : 取消执行业务操作

1. 尝试（Try）阶段
   在尝试阶段，事务的参与者（例如不同的服务或数据库）尝试执行各自的操作。每个参与者都会锁定必要的资源，并记录下将要执行的操作。这一阶段通常不会真正提交任何数据变更，而是先进行准备。

2. 确认（Confirm）阶段
   在确认阶段，如果所有的参与者都成功执行了他们的操作并且在尝试阶段中没有失败发生，那么所有的参与者将提交他们的操作，完成事务。这一步骤确保了只有在所有参与者都准备好后，数据才会被最终写入。

3. 取消（Cancel）阶段
   如果在尝试阶段有任何参与者失败了，或者在确认阶段之前的任何时候检测到任何问题，那么所有参与者将回滚他们的操作，恢复到尝试阶段之前的状态。这一步骤确保了系统的状态不会因为部分失败的参与者而变得不一致。

eg:使用消息队列（如RabbitMQ、Kafka）可以实现异步的Try-Confirm-Cancel模式。例如：

• Try：发送一个准备消息到队列。
• Confirm：所有参与者处理完消息后，发送一个确认消息。
• Cancel：如果在处理过程中遇到错误，发送一个取消消息。

---

例子1说明: A,B,C三个账户事务(A：-30，B：-50，C：+80)

1. Try：尝试执行业务
   • 完成所有业务检查(一致性)：检查A、B、C的帐户状态是否正常，帐户A的余额是否不少于30元，帐户B的余额是否不少于50元。
   • 预留必须业务资源(准隔离性)：帐户A的冻结金额增加30元，帐户B的冻结金额增加50元，这样就保证不会出现其他并发进程扣减了这两个帐户的余额而导致在后续的真正转帐操作过程中，帐户A和B的可用余额不够的情况。
2. Confirm：确认执行业务
   • 真正执行业务：如果Try阶段帐户A、B、C状态正常，且帐户A、B余额够用，则执行帐户A给账户C转账30元、帐户B给账户C转账50元的转帐操作。
   • 不做任何业务检查：这时已经不需要做业务检查，Try阶段已经完成了业务检查。
   • 只使用Try阶段预留的业务资源：只需要使用Try阶段帐户A和帐户B冻结的金额即可。
3. Cancel：取消执行业务
   • 释放Try阶段预留的业务资源：如果Try阶段部分成功，比如帐户A的余额够用，且冻结相应金额成功，帐户B的余额不够而冻结失败，则需要对帐户A做Cancel操作，将帐户A被冻结的金额解冻掉。

例子2: 银行转账

• A扣钱对应服务A(ServiceA)
• B加钱对应服务B(ServiceB)
• 转账订单服务(OrderService)

x	ServiceA	ServiceB	OrderService
try()	校验余额(并发控制);冻结余额+1000;余额-1000	冻结余额+1000	创建转账订单，状态待转账
confirm()	冻结余额-1000;余额+1000;冻结余额-1000	状态变为转账成功
cancle()	冻结余额-1000;余额+1000	冻结余额-1000	状态变为转账失败

seata项目以及原理

github seata

seata只吃了2PC、TCC等方式

how to define a Distributed Transaction?

We say, a Distributed Transaction is a Global Transaction which is made up with a batch of Branch Transaction, and normally Branch Transaction is just Local Transaction.

模拟分布式事务的解决

There are 3 basic components in Seata

1. Transaction Coordinator(TC): Maintain status of global and branch transactions, drive the global commit or rollback.（事务协调器，维护全局事务的运行状态，负责协调并驱动全局事务的提交或回滚）
2. Transaction Manager™: Define the scope of global transaction: begin a global transaction, commit or rollback a global transaction.（控制全局事务的边界，负责开启一个全局事务，并最终发起全局提交或全局回滚的决议）
3. Resource Manager(RM): Manage resources that branch transactions working on, talk to TC for registering branch transactions and reporting status of branch transactions, and drive the branch transaction commit or rollback.（控制分支事务，负责分支注册、状态汇报，并接收事务协调器的指令，驱动分支（本地）事务的提交和回滚。）

A typical lifecycle of Seata managed distributed transaction:

1. TM asks TC to begin a new global transaction. TC generates an XID representing the global transaction.

2. XID is propagated through microservices’ invoke chain.

3. RM register local transaction as a branch of the corresponding global transaction of XID to TC.

4. TM asks TC for committing or rollbacking the corresponding global transaction of XID.

5. TC drives all branch transactions under the corresponding global transaction of XID to finish branch committing or rollbacking.

6. TM 向 TC 申请开启一个全局事务，全局事务创建成功并生成一个全局唯一的 XID

7. XID 在微服务调用链路的上下文中传播

8. RM 向 TC 注册分支事务，接着执行这个分支事务并提交（重点：RM在第一阶段就已经执行了本地事务的提交/回滚），最后将执行结果汇报给TC

9. TM 根据 TC 中所有的分支事务的执行情况，发起全局提交或回滚决议

10. TC 调度 XID 下管辖的全部分支事务完成提交或回滚请求

如下图，其中，TM是一个分布式事务的发起者和终结者，TC负责维护分布式事务的运行状态，而RM则负责本地事务的运行。