(自学笔记)
-----------------
3.1.什么是2PC?
2PC
即两阶段提交协议,是将整个事务流程分为两个阶段,准备阶段(
Prepare phase
)、提交阶段(
commit
phase
),
2
是指两个阶段,
P
是指准备阶段,
C
是指提交阶段。
在计算机中部分关系数据库如
Oracle
、
MySQL
支持两阶段提交协议,如下图:
1.
准备阶段(
Prepare phase
):事务管理器给每个参与者发送
Prepare
消息,每个数据库参与者在本地执行事
务,并写本地的
Undo/Redo
日志,此时事务没有提交。
(
Undo
日志是记录修改前的数据,用于数据库回滚,
Redo
日志是记录修改后的数据,用于提交事务后写入数
据文件)
2.
提交阶段(
commit phase
):如果事务管理器收到了参与者的执行失败或者超时消息时,直接给每个参与者
发送回滚
(Rollback)
消息;否则,发送提交
(Commit)
消息;参与者根据事务管理器的指令执行提交或者回滚操
作,并释放事务处理过程中使用的锁资源。注意
:
必须在最后阶段释放锁资源。
下图展示了
2PC
的两个阶段,分成功和失败两个情况说明:
成功情况:
失败情况:
3.2.
解决方案
3.2.1 XA
方案
2PC
的传统方案是在数据库层面实现的,如
Oracle
、
MySQL
都支持
2PC
协议,为了统一标准减少行业内不必要的对
接成本,需要制定标准化的处理模型及接口标准,国际开放标准组织
Open Group
定义了分布式事务处理模型
DTP
(
Distributed Transaction Processing Reference Model
)。
为了让大家更明确
XA
方案的内容程,下面新用户注册送积分为例来说明:
执行流程如下:
1
、应用程序(
AP
)持有用户库和积分库两个数据源。
2
、应用程序(
AP
)通过
TM
通知用户库
RM
新增用户,同时通知积分库
RM
为该用户新增积分,
RM
此时并未提交事
务,此时用户和积分资源锁定。
3
、
TM
收到执行回复,只要有一方失败则分别向其他
RM
发起回滚事务,回滚完毕,资源锁释放。
4
、
TM
收到执行回复,全部成功,此时向所有
RM
发起提交事务,提交完毕,资源锁释放。
DTP
模型定义如下角色:
AP
(Application Program)
:即应用程序,可以理解为使用
DTP
分布式事务的程序。
RM
(Resource Manager)
:即资源管理器,可以理解为事务的参与者,一般情况下是指一个数据库实例,通过
资源管理器对该数据库进行控制,资源管理器控制着分支事务。
TM
(Transaction Manager)
:事务管理器,负责协调和管理事务,事务管理器控制着全局事务,管理事务生命
周期,并协调各个
RM
。
全局事务
是指分布式事务处理环境中,需要操作多个数据库共同完成一个工作,这个
工作即是一个全局事务。
DTP
模型定义
TM
和
RM
之间通讯的接口规范叫
XA
,简单理解为数据库提供的
2PC
接口协议,
基于数据库的
XA
协议来实现
2PC
又称为
XA
方案
。
以上三个角色之间的交互方式如下:
1
)
TM
向
AP
提供 应用程序编程接口,
AP
通过
TM
提交及回滚事务。
2
)
TM
交易中间件通过
XA
接口来通知
RM
数据库事务的开始、结束以及提交、回滚等
总结:
整个
2PC
的事务流程涉及到三个角色
AP
、
RM
、
TM
。
AP
指的是使用
2PC
分布式事务的应用程序;
RM
指的是资
源管理器,它控制着分支事务;
TM
指的是事务管理器,它控制着整个全局事务。
1
)在
准备阶段
RM
执行实际的业务操作,但不提交事务,资源锁定;
2
)在
提交阶段
TM
会接受
RM
在准备阶段的执行回复,只要有任一个
RM
执行失败,
TM
会通知所有
RM
执行回滚操
作,否则,
TM
将会通知所有
RM
提交该事务。提交阶段结束资源锁释放。
XA
方案的问题:
1
、需要本地数据库支持
XA
协议。
2
、资源锁需要等到两个阶段结束才释放,性能较差。
3.2.2 Seata
方案
Seata
是由阿里中间件团队发起的开源项目
Fescar
,后更名为
Seata
,它是一个是开源的分布式事务框架。
传统
2PC
的问题在
Seata
中得到了解决,它通过对本地关系数据库的分支事务的协调来驱动完成全局事务,是工作
在应用层的中间件。主要优点是性能较好,且不长时间占用连接资源,它以高效并且对业务
0
侵入的方式解决微服
务场景下面临的分布式事务问题,它目前提供
AT
模式
(
即
2PC)
及
TCC
模式的分布式事务解决方案。
Seata
的设计思想如下
Seata
的设计目标其一是对业务无侵入,因此从业务无侵入的
2PC
方案着手,在
传统
2PC
的基础上演进,并解决
2PC
方案面临的问题。
Seata
把一个分布式事务理解成一个包含了若干
分支事务
的
全局事务
。全局事务的职责是协调其下管辖的分支事务
达成一致,要么一起成功提交,要么一起失败回滚。此外,通常分支事务本身就是一个关系数据库的本地事务,下
图是全局事务与分支事务的关系图:
与 传统
2PC
的模型类似,
Seata
定义了
3
个组件来协议分布式事务的处理过程:
Transaction Coordinator (TC)
: 事务协调器,它是独立的中间件,需要独立部署运行,它维护全局事务的运
行状态,接收
TM
指令发起全局事务的提交与回滚,负责与
RM
通信协调各各分支事务的提交或回滚。
Transaction Manager (TM)
: 事务管理器,
TM
需要嵌入应用程序中工作,它负责开启一个全局事务,并最终
向
TC
发起全局提交或全局回滚的指令。
Resource Manager (RM)
: 控制分支事务,负责分支注册、状态汇报,并接收事务协调器
TC
的指令,驱动分
支(本地)事务的提交和回滚。
还拿
新用户注册送积分
举例
Seata
的分布式事务过程:
具体的执行流程如下:
1.
用户服务的
TM
向
TC
申请开启一个全局事务,全局事务创建成功并生成一个全局唯一的
XID
。
2.
用户服务的
RM
向
TC
注册 分支事务,该分支事务在用户服务执行新增用户逻辑,并将其纳入
XID
对应全局
事务的管辖。
3.
用户服务执行分支事务,向用户表插入一条记录。
4.
逻辑执行到远程调用积分服务时
(XID
在微服务调用链路的上下文中传播
)
。积分服务的
RM
向
TC
注册分支事
务,该分支事务执行增加积分的逻辑,并将其纳入
XID
对应全局事务的管辖。
5.
积分服务执行分支事务,向积分记录表插入一条记录,执行完毕后,返回用户服务。
6.
用户服务分支事务执行完毕。
7. TM
向
TC
发起针对
XID
的全局提交或回滚决议。
8. TC
调度
XID
下管辖的全部分支事务完成提交或回滚请求。
Seata
实现
2PC
与传统
2PC
的差别
:
架构层次方面,
传统
2PC
方案的
RM
实际上是在数据库层,
RM
本质上就是数据库自身,通过
XA
协议实现,而
Seata
的
RM
是以
jar
包的形式作为中间件层部署在应用程序这一侧的。
两阶段提交方面,
传统
2PC
无论第二阶段的决议是
commit
还是
rollback
,事务性资源的锁都要保持到
Phase2
完成
才释放。而
Seata
的做法是在
Phase1
就将本地事务提交,这样就可以省去
Phase2
持锁的时间,整体提高效率。