分布式事务

分布式事务

1.事务

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

• 原子性（Atomicity），可以理解为一个事务内的所有操作要么都执行，要么都不执行。
• 一致性（Consistency），可以理解为数据是满足完整性约束的，也就是不会存在中间状态的数据，比如你账上有400，我账上有100，你给我打200块，此时你账上的钱应该是200，我账上的钱应该是300，不会存在我账上钱加了，你账上钱没扣的中间状态。

• 隔离性（Isolation），指的是多个事务并发执行的时候不会互相干扰，即一个事务内部的数据对于其他事务来说是隔离的。
• 持久性（Durability），指的是一个事务完成了之后数据就被永远保存下来，之后的其他操作或故障都不会对事务的结果产生影响。

事务就是为了使得一些更新操作要么都成功，要么都失败。

2.分布式事务

分布式事务顾名思义就是要在分布式系统中实现事务，它其实是由多个本地事务组合而成。

2.1 单体系统访问多个数据库

一个服务需要调用多个数据库实例完成数据的增删改操作

2.2 多个微服务访问同一个数据库

多个服务需要调用一个数据库实例完成数据的增删改操作

2.3 多个微服务访问多个数据库

多个服务需要调用一个数据库实例完成数据的增删改操作

3. 2PC

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

让我们来看下两个阶段的具体流程。

准备阶段协调者会给各参与者发送准备命令，你可以把准备命令理解成除了提交事务之外啥事都做完了。

同步等待所有资源的响应之后就进入第二阶段即提交阶段。

提交阶段：假如在第一阶段所有参与者都返回准备成功，那么协调者则向所有参与者发送提交事务命令，然后等待所有事务都提交成功之后，返回事务执行成功。

让我们来看一下流程图。

3.1 故障分析

准备阶段失败：第一阶段协调者会等待所有参与者响应才会进行下一步操作，当然第一阶段的协调者有超时机制，假设因为网络原因没有收到某参与者的响应或某参与者挂了，那么超时后就会判断事务失败，向所有参与者发送回滚命令。

提交阶段失败：这里有两种情况。

第一种是第二阶段执行的是回滚事务操作，那么答案是不断重试，直到所有参与者都回滚了，不然那些在第一阶段准备成功的参与者会一直阻塞着。

第二种是第二阶段执行的是提交事务操作，那么答案也是不断重试，因为有可能一些参与者的事务已经提交成功了，这个时候只有一条路，就是头铁往前冲，不断的重试，直到提交成功，到最后真的不行只能人工介入处理。

协调者故障分析：

协调者故障，通过选举得到新协调者。实现的时候我们可以灵活的让协调者将自己发过的请求在哪个地方记一下，也就是日志记录，这样新协调者来的时候不就知道此时该不该发提交命令了。

但是就算协调者知道自己该发提交请求，那么在参与者也一起挂了的情况下没用，因为你不知道参与者在挂之前有没有提交事务。

如果参与者在挂之前事务提交成功，新协调者确定存活着的参与者都没问题，那肯定得向其他参与者发送提交事务命令才能保证数据一致。

如果参与者在挂之前事务还未提交成功，参与者恢复了之后数据是回滚的，此时协调者必须是向其他参与者发送回滚事务命令才能保持事务的一致。

所以说极端情况下还是无法避免数据不一致问题。

3.2 总结

2PC 是一种尽量保证强一致性的分布式事务，因此它是同步阻塞的，而同步阻塞就导致长久的资源锁定问题，总体而言效率低，并且存在单点故障问题，在极端条件下存在数据不一致的风险。

2PC 适用于数据库层面的分布式事务场景，而我们业务需求有时候不仅仅关乎数据库，也有可能是上传一张图片或者发送一条短信。

4. 3pc

3PC 包含了三个阶段，分别是准备阶段、预提交阶段和提交阶段，对应的英文就是：CanCommit、PreCommit 和 DoCommit。

3PC 的出现是为了解决 2PC 的一些问题，相比于 2PC 它在参与者中也引入了超时机制，并且新增了一个预提交阶段使得参与者可以利用这一个阶段统一各自的状态。

准备阶段：询问参与者的自身状况，是否挂掉、负载重不重等这类问题。目的是确定各个参与者是否有条件参与到整个任务中。

预提交阶段：除了事务的提交该做的都做了。

提交阶段：执行提交或者回滚。

4.1 相对2pc的改进

准备阶段 变更成不会直接执行事务，而是会先去询问此时的参与者是否有条件接这个事务，因此不会一来就干活直接锁资源，使得在某些资源不可用的情况下所有参与者都阻塞着。

预提交阶段的引入起到了一个统一状态的作用，它像一道栅栏，表明在预提交阶段前所有参与者其实还未都回应，在预处理阶段表明所有参与者都已经回应了。假如你是一位参与者，你知道自己进入了预提交状态那你就可以推断出来其他参与者也都进入了预提交状态。

引入了超时机制，参与者不会像2pc那样在提交请求还未发出去的时候，所有参与者都已经锁定资源并且阻塞等待着。如果是等待提交命令超时，那么参与者就会提交事务了，因为都到了这一阶段了大概率是提交的，如果是等待预提交命令超时，一般做法就是啥也不干了。

然而超时机制也会带来数据不一致的问题，比如在等待提交命令时候超时了，参与者默认执行的是提交事务操作，但是有可能执行的是回滚操作，这样一来数据就不一致了。

4.2 总结

3PC 的引入是为了解决提交阶段 2PC 协调者和某参与者都挂了之后新选举的协调者不知道当前应该提交还是回滚的问题。

引入了参与者超时机制，并且增加了预提交阶段使得故障恢复之后协调者的决策复杂度降低，但整体的交互过程更长了，性能有所下降，并且还是会存在数据不一致问题。所以 2PC 和 3PC 都不能保证数据100%一致，因此一般都需要有定时扫描补偿机制。

3PC 没有找到具体的实现，所以我认为 3PC 只是纯的理论上的东西，而且可以看到相比于 2PC 它是做了一些努力但是效果甚微，所以只做了解即可。

5. TCC

TCC 指的是Try - Confirm - Cancel，它属于补偿型分布式事务。

• Try： 尝试待执行的业务：这个过程并未执行业务，只是完成所有业务的一致性检查，并预留好执行所需的全部资源
• Confirm： 确认执行业务：确认执行业务操作，不做任何业务检查， 只使用Try阶段预留的业务资源。通常情况下，采用TCC则认为 Confifirm阶段是不会出错的。即：只要Try成功，Confifirm一定成功。若Confifirm阶段真的出错了，需引入重试机制或人工处理。

• Cancel： 取消待执行的业务:取消Try阶段预留的业务资源。通常情况下，采用TCC则认为Cancel阶段也是一定成功的。若Cancel阶段真的出错了，需引入重试机制或人工处理

看上去其实就是2pc的思想。撤销和确认操作的执行可能需要重试，因此还需要保证操作的幂等，TCC可以跨数据库、跨不同的业务系统来实现事务。

TCC两阶段提交与XA两阶段提交的区别是：

• XA是资源层面的分布式事务，强一致性，在两阶段提交的整个过程中，一直会持有资源的锁。
• TCC是业务层面的分布式事务，最终一致性，不会一直持有资源的锁。

TCC事务的优缺点：

• 优点：把数据库层的二阶段提交上提到了应用层来实现，规避了数据库层的2PC性能低下问题。
• 缺点：TCC的Try、Confifirm和Cancel操作功能需业务提供，开发成本高。

6. 可靠消息服务实现最终一致性

基于可靠消息服务的方案是通过消息中间件保证上、下游应用数据操作的一致性。

选择了一个网上经典的RabbitMQ实现案例，结合了本地消息表和消息事务的实现。结合图片讲解各个步骤解决的问题。

1. 如何保证生产者一定能把消息发送到mq？

正常流程：步骤2-1中，将支付系统发送的消息保存入库持久化，更新状态为待确认，同时步骤2-2返回待确认状态信息给支付系统，步骤3支付系统进行支付，步骤4支付系统返回支付成功的消息。步骤5-1可靠消息服务将支付成功的消息发送到mq，同时更新本地消息表的状态为已发送。

这里的步骤5-1，将发送消息到mq和更新本地消息表的状态为已发送控制在一个事务，发送消息到mq失败的话也会有定时任务扫描待确认的信息进行重发。

只要消息到达了可靠消息服务，可靠消息服务始终会有定时任务来扫描待处理的一些消息，即使各个服务宕机，恢复正常后，也会有任务来保证消息一定会被发送到mq。即使过程中出现了各种网络异常，也会有询问机制。支付系统除了实现正常的业务流程外，还需提供一个事务询问的接口，供消息中间件调用。

这样确保了上游服务逻辑处理与MQ消息的投递具备原子性。

1. 消费者消费失败，支付系统是不需要回滚事务的，如何保证用户余额系统一定消费成功？

用户余额系统采用手动ack（步骤8）应答方式保证消息被处理，处理成功则会主动通知可靠消息服务（步骤9），可靠消息服务此时就会将消息的状态更新为“已完成”。

失败的情况不会通知可靠消息服务更新消息状态，让消息状态还是“已发送”的状态，定时任务可以继续补偿。另外还可以采用mq进行补偿重试机制。用户余额系统始终需要注意幂等性问题。

注意，我们讲究的是最终一致，所以可以暂时不一致。

重试次数总归是有最大次数和时间间隔的，超过这个次数，根据业务情况引入人工处理或者程序处理，对于支付这种已经支付了的，只能人工处理。例如，在消息表中加入最大重试次数，超过5次的主动通知管理员到某一个页面去处理。例如，mq引入死信队列，将消息放到死信消费者中处理，死信消费者要做的可能是通知管理员，或者再次消费。这里之所以使用人工干预，是因为考虑到整个系统设计的复杂性。

1. 支付系统发送的消息已经成功投递到用户余额系统，此时支付系统发生错误事务回滚，如何解决？

1.用户余额系统业务上控制，更新余额前，查询支付订单状态。

2. 如果已经被消费，支付余额系统发送回滚消息到用户余额系统。

此外，针对其他业务还会引入补偿机制，比如库存系统收到订单系统的扣钱通知，发现订单不存在，则会重新构建订单。

4.消费者如何保证消息幂等性，不被重复消费

解决办法:

①使用全局MessageID判断消费方使用同一个，解决幂等性。

②同时业务逻辑保证唯一（比如订单号码）。

总结

有些mq天然支持事务，例如RocketMQ。目前RocketMQ消息中间件的使用场景比较广泛，对于需要通过MQ进行异步解耦的分布式应用系统来说，RocketMQ无疑是一个不错的技术选择,，如图，可以少开发可靠消息服务。

事实上，支付系统的数据一致性是一个复杂的问题，原因在于支付流程的各个环节都存在异步的不确定性，例如支付系统需要跟第三方渠道进行交互，不同的支付渠道交互流程存在差异，并且有异步支付结果回调的情况。

7.最大努力通知

本地消息表也可以算最大努力，事务消息也可以算最大努力。

就本地消息表来说会有后台任务定时去查看未完成的消息，然后去调用对应的服务，当一个消息多次调用都失败的时候可以记录下然后引入人工，或者直接舍弃。这其实算是最大努力了。

事务消息也是一样，当消息被commit了之后确实就是普通消息了，如果订阅者一直不消费或者消费不了则会一直重试，到最后进入死信队列。其实这也算最大努力。

所以最大努力通知其实只是表明了一种柔性事务的思想：我已经尽力我最大的努力想达成事务的最终一致了。

本地消息、事务消息和最大努力通知其实都是最终一致性事务，因此适用于一些对时间不敏感的业务。

8.seata

从前面来看，为了实现分布式事务，需要做很大的复杂度系统设计。

seata其愿景是让分布式事务的使用像本地事务的使用一样，简单和高效，并逐步解决开发者们遇到的分布式事务方面的所有难题。

Seata的设计目标是对业务无侵入，因此从业务无侵入的2PC方案着手，在传统2PC的基础上演进。它把一个分布式事务理解成一个包含了若干分支事务的全局事务。全局事务的职责是协调其下管辖的分支事务达成一致，要么一起成功提交，要么一起失败回滚。此外，通常分支事务本身就是一个关系数据库的本地事务。

8.1 AT模式

https://blog.csdn.net/qq_35067322/article/details/110914143

1. feign调用时，如何传递xid的？

在源码cloud-alibaba那个包里有和rpc框架的整合类，seata代理了feigncontext。

1. 二阶段提交时，某个服务挂了，事务如何回滚？

连得是同一个库，连同一个数据库的都是兄弟节点，其他节点会帮他解锁。如果分库的话，就只能等待对应的服务恢复正常，才能继续提交/回滚。

8.2 TCC模式

https://blog.csdn.net/huaishu/article/details/89880971