分布式事务处理.pptx

分布式事务处理.pptx

《分布式事务处理.pptx》由会员分享，可在线阅读，更多相关《分布式事务处理.pptx（29页珍藏版）》请在冰豆网上搜索。

钱滚滚分布式事务方案,1,大纲,基本原理服务端设计应用改造方案典型业务场景接入方式,数据一致性,数据一致性。

关联数据之间的逻辑关系是否正确和完整。

一致性分类。

强一致弱一致性最终一致性,分布式事务,分布式事务就是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上。

产生原因数据库分库分表应用SOA化常见方案基于XA协议的两阶段提交消息事务+最终一致性TCC编程模式,两阶段提交基本模型,事务协调者,参与者,参与者,1.准备,2.已准备,5.提交,6.完成,3.准备,4.已准备,7.提交,8.完成,事务协调者,参与者,参与者,1.准备,2.已准备,5.回滚,6.完成,3.准备,4.已准备,7.回滚,8.完成,分布式事务基本模型,XTS,发起者,参与者,1.开启主事务,2.已准备,5.提交,4.已准备,6.提交,7.完成,3.加入分支事务,XTS,发起者,参与者,1.开启主事务,2.已准备,5.回滚,4.已准备,6.回滚,7.完成,3.加入分支事务,分布式事务基本模型,协调者,参与者,发起者,主事务管理器,分支事务管理器,定时任务,注册主事务,事务提交,事务回查,恢复数据查询,注册分支事务,提交,回滚,同库和异库分布式事务,同库：

主事务和业务流水在一个db中，占用业务系统的db容量，但是减少了主事务注册的远程调用，性能有优势，对应用来说改动相对比较大。

异库：

主事务在xts系统中，所有的分布式事务都需要xts来主控，可能存在单点问题，比如db挂掉，应用挂掉。

未来对于主路径肯定是主推同库模式，异库模式也需要支持。

根据业务实际情况，采用异库的模式。

xts：

extendedtransactionservice,2,大纲,基本原理服务端设计应用改造方案典型业务场景接入方式,分布式事务主要模型,business_activity（主事务）,business_action（分支事务）,主事务状态机,NULL,初始化,确认提交状态,确认回滚状态,未知状态,未知状态：

是由协调者会查时发起者给的结果，理论上不应该出现，出现了可能需要人工介入了。

初始化状态：

发起方注册主事务。

回滚状态：

发起方本地事务回滚了，事务同步器回滚,提交状态：

发起方本地事务提交了，事务同步器提交到服务端,定时恢复,daemon,捞取主事务状态为I的记录,根据主事务id获取分支事务,捞取主事务的时候需要注意时间段，不能跨度太长导致db压力。

查询事务状态的时候只有在提交或者回滚的时候才需要恢复。

查询发起者事务状态,提交/回滚分支事务,loop,分布式定时任务,mutex_task字段说明,抢锁,捞取初始数据进行恢复,结束,Y,N,容量分析,分布式事务实现-正常调用,发起者,参与者,XTS,1.开启本地事务,2.注册一个远程事务（主事务）,7.完成参与者业务,4.调用参与者,5.加入分支事务,8.本地事务提交,8.XTS根据本地事务结果commit/rollback,10.循环第2阶段commit/rollback,3.Business_activity增加一条的I的记录,6.Business_action增加一条记录,9.捞取Business_action记录,11.更新Business_activity状态,12.根据配置结果通知,分布式事务实现-恢复流程,发起者,参与者,XTS,2.查询事务状态,1.Business_activity捞取I，U的记录,3.根据事务id查询Business_action,5.更新Business_activity状态,mit/rollback,6.根据配置结果通知,3,大纲,基本原理服务端设计应用改造方案典型业务场景接入方式,事务改造-发起者,发起者在本地事务内开启。

只要负责开启事务，客户端会自动在本地事务管理器中注册事务同步器。

本地事务提交时，由事务同步器自动通知服务端进行事务回滚或者提交。

发起者在本地事务外开启。

应用可以选择在合适的时候绑定本地事务。

应用需要确保事务一定会提交或者回滚。

需要实现回查接口，数据要确保可重复读。

事务改造-参与者,在业务过程中需要显式的调用客户端把自己加入到分支事务中。

需要实现xts提供的二阶段提交/回滚服务。

事务状态需要保证幂等性（比如xts发起提交的时候，此时数据已经提交，也需要返回提交成功）,参与者状态机改造的几种方案,一、在业务状态中带入分布式事务状态。

适用情况，状态机比较简单，加入后不会对业务流程造成很大影响。

二、业务流水表上新增一个分布式事务状态字段。

比如支付在充值完成后需要完成支付时，业务状态停在“已充值”，如果支付第1阶段成功，状态变成“已充值”-“预处理成功”，第2阶段提交成功后，业务状态和分布式事务状态一起变化。

在一条记录上，变更时天生带有事务性。

三、新增一个表，存放分布式事务相关的信息。

一阶段的时候把数据单独存起来，业务处理时要考虑到这个新增的表中数据。

二阶段提交时直接把数据移到主流水中，回滚则直接删除数据。

注意和主流水在一个事务里。

4,大纲,基本原理服务端设计应用改造方案典型业务场景接入方式,典型业务场景-充值,payment,account,XTS,2.开启本地事务,3.注册一个远程事务（主事务）,6.完成充值，并冻结预处理,4.增加余额并冻结,5.加入分支事务,7.本地事务提交,8.XTS根据本地事务结果commit/rollback,第2阶段commit/rollback,如果发生回滚，支付能发起重试,1.银行支付完成,典型业务场景-提现,transcore,XTS,开启本地事务,payment,account,异步提现,开启分布式事务,转账,转到中间账户,加入分布式事务,XTS根据本地事务结果commit/rollback,银行提现,事务失败，payment能自动恢复,5,大纲,基本原理服务端设计应用改造方案典型业务场景接入方式,发起者配置,参与者接入,几个注意点,1.事务id传递有两种方式，一是在服务接口里直接传递，二是在dubbo上下文里获取。

2.由于同一笔业务可能发起多次调用，发起者应做好记录，防止在查询的时候查询不到流水。

3.context中可以存放业务流水，如果根据事务id无法查询到数据，可以通过业务流水查询状态。

4.参与者要做好状态控制，支持多次提交和回滚。

5.参与者要做好请求流水的幂等控制，xts只能保证单个事务的最终一致性，业务上的控制需要应用自行控制。

优缺点,一定程度降低了系统处理分布式事务一致性带来的复杂度，提供了最终一致性的保障。

整个设计是存储无关的，底层数据库可以采用任何一种数据库。

对性能的影响，因为是在本地事务重开启了分布式事务，单个事务的操作时间会很大程度受rpc响应时间影响，如果rpc时间过长，会影响单机的吞吐量。

Thanks,Q&A,