MySQL-分布式事务
2021-08-09 09:09:46 0 举报AI智能生成
MySQL-分布式事务
作者其他创作
大纲/内容
分布式事务
理论
CAP
又被叫做布鲁尔定理，对于共享数据系统，最多只能同时拥有CAP其中的两个，任意两个都有其适用的场景
BASE
最终一致性，核心思想是即使无法做到强一致性，但应用可以采用适合的方式达到最终一致性
2PC
强一致性
事务的发起者称为协调者，事务的执行者称为参与者
两阶段提交，将事务的提交过程分为两个阶段来进行处理
准备阶段
提交阶段
问题
性能问题
可靠性问题
数据一致性问题
3PC
强一致性
在2PC上引入超时机制
阶段
1. canCommit
2. preCommit
3. doCommit
相比2PC
降低了阻塞范围
避免了协调者单点问题
XA
强一致性
XA是由X/Open组织提出的分布式事务的规范，基于2PC
XA主要定义了全局事务管理器（TM）和局部资源管理器（RM）之间的接口
目前主流的关系型数据库产品都是实现了XA接口
之所以需要引入TM，是因为在分布式系统中，从理论上讲两台机器理论上无法达到一致的状态，需要引入一个单点进行协调
由TM管理和协调的事务，可以跨越多个资源（数据库）和进程
TM用来保证所有事务参与者都完成了准备工作
如果TM收到所有参与者都准备好的消息，就会通知所有的事务都可以提交了
MySQL在XA事务中扮演的是参与者，而不是TM
TCC
最终一致性
Try-Confirm-Cancel，是服务化的两阶段编程模型
其3个方法均由业务编码实现
Try
操作作为一阶段，负责资源的检查和预留
Confirm
操作作为二阶段提交操作，执行真正的业务
Cancel
预留资源的取消
相比XA，解决了
协调者单点
由主业务方发起并完成业务活动
业务活动管理器可以变成多点，引入集群
同步阻塞
引入超时机制，超时后进行补偿，并且不会锁定整个资源
将资源转换为业务逻辑形式，粒度变小
数据一致性
有了补偿机制之后，由业务活动管理器控制一致性
消息队列模式
最终一致性
最初由eBay提出，基于TCC模式，消息中间件可以基于Kafka、RocketMQ等消息队列
核心是将分布式事务拆分成本地事务进行处理，将需要分布式处理的任务通过消息日志的方式来异步执行
消息日志可以存储到本地文本、数据库或MQ中间件，再通过业务规则自动或人工发起重试
事务处理流程
1. 事务主动方处理本地事务
2.事务主动方通过消息中间件，通过事务被动方处理事务通知事务待消息
事务主动方主动写消息到MQ
事务被动方接口并处理MQ中的消息
3.事务被动方通过MQ中间件，通知事务主动方事务已处理的消息，事务主动方根据反馈结果提交或回滚事务
为了数据一致性，流程中遇到错误需要重试，容错处理规则如下
步骤1处理出错，事务回滚，相当于什么都没有发生
步骤2处理出错，由于未处理的事务消息还是保存在发送方，可以重试或撤销本地业务操作
如果事务被动方消费消息异常，需要不断重试，业务处理逻辑需要保证幂等
如果事务被动方业务上处理失败，可以通过MQ通知事务主动方进行补偿或事务回滚
如果多个事务被动方已经消费消息，事务主动方需要回滚事务时需要通知事务被动方回滚
基于Saga模式
最终一致性
一个Saga事务是一个有多个短时事务组成的长时的事务
在分布式事务场景下，一个Saga分布式事务可以看作是由多个本地事务组成的事务，每个本地事务都有一个与之对应的补偿事务
Saga事务执行过程中，如果某一步执行出现异常，Saga事务会被终止，同时调用对应的补偿事务完成相关的恢复操作
这样保证Saga相关的本地事务要么都是执行成功，要么通过补偿恢复成为事务执行之前的状态
基本协议
每个Saga事务由一系列幂等的有序子事务Ti组成
每个Ti都有对应的幂等补偿动作Ci，补偿动作用于撤销Ti造成的结果
Saga是一种补偿模式，它定义了两种补偿策略
向前恢复
发生失败进行重试，适用于必须要成功的场景
向后恢复
发生错误后撤销掉之前所有成功的子事务，使得整个Saga的执行结果撤销
Seata框架AT模式
Seata：Simple Extensible Autonomous Transaction Architecture
它是一套一站式分布式事务解决方案，是阿里集团和蚂蚁金服联合打造的分布式事务框架
目前的事务模式有AI、TCC、Saga，默认AT模式（本质上是2PC的一种实现）
AT模式
模型
包含TM、RM、TC（事务协调器）
TC是一个独立的服务需要单独部署
TM和RM以Jar包的方式同业务应用部署在一起，它们同TC建立长连接，在整个事务生命周期内，保持RPC通信
机制
全局事务的发起方作为TM，全局事务的参与者作为RM
TM负责全局事务的begin和commit/rollback
RM负责分支事务的执行结果上报，并通过TC的协调进行commit/rollback
阶段
一、各个阶段本地提交操作
二、根据第一阶段情况决定是进行全局提交/回滚
执行流程
TM开启分布式事务
TM向TC注册全局事务记录
RM通过TC协调进行commit/rollback
RM向TC汇报资源准备状态
RM分支事务结束，一阶段结束
根据TC汇总事务信息，由TM发起commit/rollback操作
TC通知所有RM commit/rollback，二阶段结束
Sharding-JDBC整合
XA
说明
Java通过定义JTA接口实现了XA的模型，JTA接口里的ResourceManager需要数据库厂商提供XA的驱动实现，而TransactionManager则需要事务管理器厂商实现，传统的事务管理器需要同应用服务器绑定，因为使用成本很高
嵌入式的事务管理器可以以Jar包的形式提供服务，同ShardingSphere集成后，可保证分片后跨库事务强一致性
ShardingSphere整合XA事务时，分离了XA事务管理和连接池管理，这样接入XA时，可以做到对业务的零侵入
支持
支持数据分片后的跨库XA事务
两阶段提交保证操作的原子性和数据的强一致性
服务宕机重启后，提交/回滚中的事务可自动恢复
SPI机制整合主流的XA事务管理器，默认Atomikos
同时支持XA和非XA的连接池
提供springboot和namespace的接入端
流程
Begin 开启XA全局事务
XAShardingTransactionManager会调用具体的XA事务管理器开启XA的全局事务
执行物理SQL
ShardingSphere进行解析/优化/路由后生成SQL操作，执行引擎为每个物理SQL创建连接的同时，物理连接对应的XAResource也会被注册到当前XA事务中
事务管理器会在此阶段发送XAResource.start命令给数据库，数据库在收到XAResource.end命令之前的所有SQL操作，会被标记为XA事务
Commit/rollback 提交XA事务
XAShardingTransactionManager收到接入端的提交命令后，会委托实际的XA事务管理进行提交动作
XA事务管理器会收集当前线程里所有注册的XAResource
首先发送XAResource.end指令，用以标记此XA事务的边界
接着会依次发送prepare指令，收集所有参与XAResource投票
所有XAResource反馈结果OK，则再次调用commit指令进行最终提交
如果有任意XAResource反馈结果No，则调用rollback指令进行回滚
事务管理器发出提交指令后，任何XAResource产生的异常都会通过recovery日志进行重试，来保证提交阶段的操作原子性和数据强一致性
Saga
说明
ShardingSphere的柔性事务已通过第三方servercomb-saga组件实现，通过SPI机制注入使用
ShardingSphere基于反向SQL技术实现的反向补偿操作，它将数据库进行更行操作的SQL自动生成反向SQL，并交由Saga-actuator引擎执行
使用方则无需再关注如何实现补偿方法，将柔性事务管理器的应用范畴成功的定位回了事务的本源——数据库层面
Saga柔性事务的实现类是SagaShardingTransactionManager，ShardingSphere通过Hook的方式拦截逻辑SQL的解析和路由结果，这样，在分片物理SQL执行前，可以生成逆向SQL，在事务提交阶段再把SQL调用链交给Saga引擎处理
支持
完全支持跨库事务
支持失败SQL重试及最大努力送达
支持反向SQL、自动生成更新快照以及自动补偿
默认使用关系型数据库进行快照及事务日志的持久化，支持使用SPI的方式加载其他类型的持久化
流程
Init Saga引擎初始化
包含Saga柔性事务的应用启动时，saga-actuator引擎会根据saga.properties的配置进行初始化的流程
Begin 开启Saga全局事务
每次开启Saga全局事务时，将会生成本次全局事务的上下文（SagaTransactionContext），事务上下文记录了所有子事务的正向SQL和逆向SQL，作为生成事务调用链的元数据使用
执行物理SQL
物理SQL执行前，ShardingSphere根据SQL的类型生成逆向SQL，这里是通过Hook的方式拦截Parser的解析结果进行实现
Commit/rollback 提交Saga事务
提交阶段会生成Saga执行引擎所需的调用链路图，commit操作产生ForwardRecovery（正向SQL补偿）任务，rollback操作产生BackwardRecovery（逆向SQL补偿）任务
Seata
说明
分布式事务的实现目前主要分为两阶段的XA强事务和BASE柔性事务
SeataAT事务作为BASE柔性事务的一种实现，可以无缝接入到ShardingSphere生态中
整合SeataAT事务时，需要把TM、RM、TC模型融入到ShardingSphere分布式事务的SPI生态中
在数据库资源上，Seata通过对接DataSource接口，让JDBC操作可以同TC进行RPC通信
ShardingSphere也是面向DataSource的接口对用户配置的物理DataSource进行聚合
因此把物理DataSource二次包装为Seata的DataSource后，就可以把SeataAT事务融入到ShardingSphere分片中
流程
Init Seata引擎初始化
包含Seata柔性事务的应用启动时，用户配置的数据源会按seata.conf配置，适配成Seata事务所需的DataSourceProxy，并且注册到RM中
Begin 开启Seata全局事务
TM控制全局事务的边界，TM通过向TC发送begin指令，获取全局事务ID，所有分支事务通过此ID，参与到全局事务中
全局事务ID的上下文存放在当前线程变量中
执行分片物理SQL
处于Seata全局事务中的分片SQL通过RM生成undo快照，并且发送participate指令到TC，加入到全局事务中
ShardingSphere的分片物理SQL是按多线程方式执行，因此整合Seata_AT事务时，需要在主线程和子线程间进行全局事务ID的上下文传递
Commit/rollback 提交Seata事务
提交Seata事务时，TM会向TC发送全局事务的commit和rollback指令，TC根据全局事务ID协调所有分支事务进行commit和rollback
使用
1. 引入依赖
2. Java编码方式设置事务类型
3. 配置参数
ShardingSphere默认的XA事务管理器为Atomikos
通过在项目classpath中添加jta.properties来定制化Atomikos配置项
Saga可以通过在项目classpath中添加saga.properties来定制化Saga事务的配置
0 条评论
下一页
