分布式事务解决方案之2PC

最新推荐文章于 2023-02-14 20:26:28 发布

做时间的朋友。

最新推荐文章于 2023-02-14 20:26:28 发布

阅读量3k

点赞数 2

分类专栏：分布式文章标签：分布式

本文链接：https://blog.csdn.net/weixin_44335140/article/details/110762850

版权

分布式专栏收录该内容

5 篇文章 0 订阅

订阅专栏

在介绍了分布式事务的理论基础后，针对不同的分布式场景常见的解决方案有2PC、TCC、可靠消息最终一致性、最大努力通知这几种，这次我们来介绍2PC。

什么是2PC

2PC(2 prepare phase commit phase)：俩阶段提交，俩阶段提交是一种强一致性的设计。

在2PC中由事务协调者和事务参与者组成(一般是数据库)

准备阶段(prepare phase)：事务协调者给每个事务参与者发送Prepare消息，事务参与者收到消息后执行各自的本地事务，但是没有提交。（第一阶段中，除了没提交事务，其他的都做了）
提交阶段(commit phase)：事务协调者根据事务参与者准备阶段的执行情况决定给每个参与者发送回滚(Rollback)消息还是提交(commit)消息。

第二阶段发送commit的情况
在这里插入图片描述

当所有的事务参与者第一阶段都执行成功响应OK时，事务协调者(TM )会像所有的事务参与者都发送Commit消息，事务参与者收到Commit后，就会提交本地事务，并释放锁资源。也就是说，之前事务的状态一直都是未提交状态！

第二阶段发送rollback的情况
在这里插入图片描述

如果说有一个数据库执行本地事务失败，那么事务协调者就会像其他数据库发送Rollback消息。

在第一阶段失败的话，会触发Rollback，那么第二阶段会不会失败呢？

会的，这里有俩种情况：

第二阶段执行的是回滚操作，如果第二阶段失败了，那么它会不断的重试，直到所有的事务参与者都回滚成功，否则那些第一阶段准备成功的参与者将会一直阻塞的
第二阶段执行的是提交操作，那么它也会不断的重试，因为可能有一些参与者的事务已经提交了，此时已经无路可走，只能不断的重试，直到成功为止，最后还是不行只能人工介入了。

2PC是一个同步阻塞协议，在第一阶段中协调者会等待所有参与者的响应才会进入下一个阶段。在第一阶段中协调者有超时机制，假设因为网络的原因或者参与者挂了，那么超时后会判断事务失败，向所有参与者发送回滚命令

在第二阶段协调者没法超时，只能按照我们上面说的不断尝试

协调者故障分析

协调者是一个单点，存在单点故障问题。

1、假设协调者在发出第一阶段命令之前挂了。此时参与者都没收到命令，事务没有开始，也就啥事都没发生。

2、假设协调者在发出第一阶段命令之后挂了。此时参与者只会执行到第一阶段，在第一阶段中，事务无法提交，且会锁定一些公共资源而阻塞系统的一些其他操作

3、假设协调者在发出回滚命令之前挂了。那么第一阶段执行成功的参与者事务将被一直被阻塞，占据资源。

4、假设协调者在发出回滚命令之后挂了。如果参与者回滚都成功了，那就没问题。但是如果出现网络分区问题，某些参与者将因为收不到命令而一直阻塞着。

5、假设协调者在发出提交命令之前挂了。此时所有的参与者事务都将一直被阻塞着。

6、假设协调者在发出提交命令之后挂了。同样，如果参与者都提交成功，就没问题，但是如果出现网络分区问题，某些参与者将因为收不到命令而一直阻塞着。

协调者故障，通过选举得到新的协调者

由于协调者存在单点问题，所以我们可以选举出一个新的协调者来顶替。由于新来的协调者并不知道参与者的执行情况，所以它需要去询问每个询问者的状态，如果一切正常的话，这是没有问题的。

但是假设其中有一个参与者挂了，此时新的协调者无法知道这个挂掉的参与者的状态：

如果是在第一阶段的话，不知道就不知道吧，大不了全部回滚，因为这个阶段的事务都还没提交。
如果是第二阶段的话，假设只有挂掉的参与者状态是不OK的，此时新来的协调者在询问了在场的参与者后，得到的反馈都是OK，那么它就会发送提交命令，此时就造成了数据不一致。

此时的问题就在于，每个参与者自身的状态只有自己和协调者知道，因此新的协调者无法通过在场的参与者状态推断出挂了的参与者是什么情况。

虽然协议上没说，不过在实现的时候，我们可以让协调者在自己发过请求的地方记录一下，也就是日志记录，这样新的协调者就知道该发什么命令了。

但是，在极端情况下，还是可能会出现不一致。极端情况（这是一个比我大不了多少的大佬写的文章）

总结

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

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

2PC实现方案

1. XA方案

传统的2PC方案是在数据库的层面实现的，如Oracle、MySQL都支持2PC协议，为了减少业内不必要的对接成本，国际开放标准组织Open Group定义了分布式事务处理模型DTP（Distributed Transaction Processing Reference Model）以及接口标准。

为了让大家更明确XA方案的内容程，下面新用户注册送积分为例来说明：
在这里插入图片描述
执行流程如下：

应用程序（AP）持有用户库和积分库两个数据源。
应用程序（AP）通过TM通知用户库RM新增用户，同时通知积分库RM为该用户新增积分，RM此时并未提交事务，此时用户和积分资源锁定。
TM收到执行回复，只要有一方失败则分别向其他RM发起回滚事务，回滚完毕，资源锁释放。
TM收到执行回复，全部成功，此时向所有RM发起提交事务，提交完毕，资源锁释放。

DTP模型定义的角色：

AP(Application Program)：即应用程序，可以理解为使用DTP分布式事务的程序。
RM(Resource Manager)：资源管理器，可以理解为事务参与者，一般情况下指的是一个数据库实例，通过资源管理器对数据库进行控制，资源管理器控制着分支事务
TM(Transaction Manager)：事务管理器，负责协调和管理事务，事务管理器控制着全局事务，管理事务生命周期，并协调各个RM。
DTP模型定义TM和RM之间通讯的接口规范为XA，可以简单理解为数据库提供的2PC接口协议，基于数据库的XA协议来实现2PC又成为XA方案。

2.seata实现分布式事务

seata是什么

Seata 是一款开源的分布式事务解决方案，致力于提供高性能和简单易用的分布式事务服务。Seata 将为用户提供了 AT、TCC、SAGA 和 XA 事务模式，为用户打造一站式的分布式解决方案。

seata实现2PC与传统2PC的区别

架构层面：传统的2PC方案RM是数据库层面的，本质上就是数据库自身基于XA协议实现的。而seata的RM是以jar包的形式作为中间件部署在应用程序一侧的。

俩阶段提交方面：传统的2PC方案事务锁定的资源自由等到第二阶段完成才会释放。而seata得做法是在第一阶段就将本地事务提交，这样省去第二阶段持锁得时间，提高整体效率。

seata的设计思想

事务的回滚除了由数据库自己控制外，其实还可以通过回滚日志来进行控制（实际上数据库也是通过回滚日志实现的回滚）。我们在执行SQL语句的同时，记录该SQL语句的反向操作，这样即使事务提交了，我们还是以通过执行反向操作来达到回滚的效果。

如：
执行更新操作，我们就可以将更新前数据记录下来。
执行删除操作，我们就可以记录与之相反的插入操作
执行插入操作，我们就可以记录与之相反的删除操作

Seata设计思想也是这样，通过回滚日志协助回滚，实现无业务侵入的2PC方案，并解决传统2PC方案面临的问题。

Seata的分布式事务由一个全局事务以及若干个分支事务组成。我们知道在一个分布式事务中往往存在多个本地事务，本地事务就是一个个的分支事务，而一个全局事务管理的多个本地事务，并负责协调本地事务的提交和回滚。
在这里插入图片描述

seata的执行过程

与传统2PC的模型类似，seata定义了3个组件来协调分布式事务的处理过程：
在这里插入图片描述

Transaction Coordinator (TC)：事务协调器，它是一个独立的中间件，需要独立部署。它用于维护全局事务的状态，接受TM发起的全局事务提交与回滚，负责与RM通信协调各个分支事务的提交与回滚
Transaction Manager ™：事务管理器，嵌入到应用程序中工作，负责开启一个全局事务，并最终向TC发起全局提交或全局回滚的指令
Resource Manager (RM)：资源管理器，负责分支注册、状态汇报，并接受事务协调器的指令，驱动分支(本地)事务的提交与回滚。

以新用户注册送积分为例解释seata分布式事务的过程：
在这里插入图片描述

用户服务TM向TC申请开启一个全局事务，TC创建全局事务并生成一个全局唯一的XID返回给TM
用户服务的RM向TC注册分支事务，该分支事务在用户服务执行新增用户逻辑，并将其纳入XID对应全局事务的管辖
用户服务执行分支事务，向用户表插入一条记录
用户服务调用积分服务，其中XID在微服务调用链路的上下文中传播
积分服务的RM向TC注册分支事务，该事务执行用户积分增加的逻辑，并将其纳入XID对应全局事务的管辖
积分服务执行分支事务，增加用户积分
TM向TC发起针对XID的全局提交或回滚决议。
TC调度XID管辖下的全部分支事务完成提交或回滚请求。

3.seata案例

业务说明

在本例子中模拟张三向李四转账，其中张三和李四的账户处于不同的银行(不同的微服务bank1、bank2)。交易的过程是，张三给李四转账，张三扣减金额，李四增加金额，这俩步操作必须要么一起成功要么一起失败。
在这里插入图片描述
seata在配置完必要信息后，实现起来非常简单，只需要在service上加一个 @GlobalTransactional注解即可，该注解用于开启一个全局事务。

为什么seata可以做到无侵入性

seata能做到业务无侵入的奥秘就在于seata代理了我们的数据源：

@Configuration
public class DatabaseConfiguration {
    @Bean
    @ConfigurationProperties(prefix = "spring.datasource.ds0")
    public DruidDataSource ds0() {
        DruidDataSource druidDataSource = new DruidDataSource();
        return druidDataSource;
    }

    //让seata去代理数据源
    @Primary
    @Bean
    public DataSource dataSource(DruidDataSource ds0)  {
        DataSourceProxy pds0 = new DataSourceProxy(ds0);
        return pds0;
    }
}

要点说明：

我们知道seata的回滚主要靠undo_log，seata代理我们的数据源后，在第一阶段中将undo_log和业务数据放在一个本地事务中提交，这样就保证了只要有业务操作就一定有undo_log。
如果一切顺利，第二阶段TC会通知各个参与者提交分支事务，由于各个参与者分支事务在第一阶段中已经提交，所以此时只需要删除对应的undo_log即可，并且可以异步执行，所以第二阶段很快可以完成。
如果第一阶段某个参与者事务执行失败，第二阶段TC就会通知各个参与者回滚日志。参与者通过XID和Branch ID找到相应的回滚日志，通过回滚日志生成反向SQL并执行，完成事务回滚，如果回滚失败则会尝试回滚操作

完整程序放在了码云上项目链接，简单的说几个要点：

让seata代理我们的数据源
由于seata需要借助回滚日志实现回滚，所以需要在每个事务参与者的数据库中都创建一个undo_log表。
使用@GlobalTransactional注解开启一个全局事务。GlobalTransactionalInterceptor会拦截@GlobalTransactional注解的方法，生成全局事务ID(XID)，XID会在整个分布式事务中传递。在远程调用时，pring-cloud-alibaba-seata会拦截Feign调用将XID传递到下游服务。

在这里插入图片描述

视频教程地址：https://www.bilibili.com/video/BV1FJ411A7mV

做时间的朋友。

关注

2
点赞
踩
12

收藏

觉得还不错? 一键收藏
1
评论
分布式事务解决方案之2PC

在介绍了分布式事务的理论基础后，针对不同的分布式场景常见的解决方案有2PC、TCC、可靠消息最终一致性、最大努力通知这几种，这次我们来介绍2PC。什么是2PC2PC(2 prepare phase commit phase)：俩阶段提交，俩阶段提交是一种强一致性的设计。在2PC中由事务协调者和事务参与者组成(一般是数据库)准备阶段(prepare phase)：事务协调者给每个事务参与者发送Prepare消息，事务参与者收到消息后执行各自的本地事务，但是没有提交。提交阶段(commit ph.
复制链接

扫一扫