支付宝TCC示例

支付宝TCC示例前台web1交易付款交易服务2红包清算红包服务5余额支付3保证金解冻4.保证仝转账账务服务在多个服务协同完成一次业务时,由于业务约束(如红包不符合使用条件、账户余额不足等)、系统故障(如网络或系统超时或中断、数据库约束不满足等),都可能造成服务处珅过稈在任何一步无法继续,使数据处于不一致的状态,产生严重的业务后果。传统的基于数握库本地事务的解决方案只能保障单个服务的一次处理具备原子性、隔离性、一致性与持久性,但无法保障多个分布服务闫处理的一致性。因此,我们必须建立一套分布式服务处理之间的办调机制,保障分布式服务处理的原子性、隔离性、一致性与持久性。2k械n.docin.com21两阶段提交协议(2PC传统的分布式事务处理是基于两阶段提交协议的。两阶段提交协议的原理如下图所小:分布式事务协调者准备2.已准备5提交6完成3准备4L准备7提交8完成分布式事务参与者分布式事务参与者成功的两阶段提交(2PC)示例分布式事务协调者1准备2已准备5放弃6完成3.准备4放弃7放弃8完成分布式事务参与者分布式事务参与者丁失败的两阶段提父(PC)示例从上图可见,两阶段提交协议的关键在于“准各”操作。分布式事务协调者在第一阶段通过对所有的分布式事务参与者请求“准备”操作,达成关于分布式事务致性的共识。分布式事务参与者在准备阶段必须完成所有的约束检查、并且确保后续提交或放弃时所需要的数据匚持久化。在第二队段,分布式事务协调者根据之前达到的提交或放弃的共识,请求所有的分布式事务参与者完成相应的操作。22最末参与者优化LPo)两阶段提交协议要求分布式事务参与老实现一个特别的“准备”操作,无论在资源管理器(如数据库)还是在业务服务中实现该操作都存在效率与复杂性的挑战。因此,两阶段提交协议有个重耍的优化,称为“最末参与者优化”( Last Participant Optimization),允许两阶段提交协议中有一个参与者不实现“准备”操作(称为单阶段参与者)。最末参与者优化的原理如下图所示:分布式事务协调者1准备2已裡各5提交6完成3.提交4完成两阶段参与者单阶段参与考最末参与者优化(LPO示例成功场景分布式事务协调者d1准名2.已准备5放弃6完成3.提交4放弃两阶段参与者单阶段参与者丁最末参与者优化LPO小例失败场景从上图可见,LPO中,单阶段参与者不需要实现准各操作,只需要提供标准的提交操作即可。分布式事务协调者必须等其余两阶段参与者都准备好之后,再谞求单阶段参与者提交,单阶段参与者的提交结果将决定整个分布式事务的结果。本质上,LPO是将最后一个参与者的准备操作与提交/放弃操作合并成一个提交操作最末参与者优化方案使得我们能够利用支付宝业务的特点,尽量简化分布式事务的实现。23 x/Open模型Ⅹ/open组织为基丁两阶段协议的分布式事务处理系統提山了标准的系统参考模型(X/open事务模型)、以及不同组件间与事务协调相关的接口,使不同厂商的产品能够互操作。 X/Open事务模型如下图所示:应用程序资源操作接口TX接口资源管理器开始事务提交事务回滚事务加入xA接口准备提交放弃事务管理器从上图可以看出, X/Open模型定义了两个标准接口:TX接口用于应用程序向事务管理器发起事务、提交事务和回滚事务(即确定事务的边界和结果);ⅩA接口用于事务管理器将资源管理器(如数据库、消息队列等)加入事务、并掉制两阶段提交。事务管理器般由专门的中间件提供、或者在应用服务器中作为一个重要的组件提供。资源管理器如数据库、消息队列一般也会提供XA支持。通过使用符合X/Open标准的分布式事务处理,能够简化分布式亨务类应用的开发。但在现实屮,事务管理器与资源管理器对ⅸXA协议的实现上存在效率、可靠性与伸缩性上的风险;在两阶段提交协议执行过程中的异常恢复起来也很園难;而且在SOA体系下当事务需要跨越多个服务(而不是多个资源管理器)时,事务的协调与恢复会变得非常复杂。在标准分布式事务管理框架不能满足需要的情况下,我们需要根据支付宝业务与系统的特点,设计并实现自己的分布式事务处理机制。下一节介绍支付宝分布式事务处理的基础模型3基础模型31典型业务处理模式支付宝的主体业务基本都会在一次业务处理中进行一次或多次账务处理。典型的业务处理模式如下图所示业务服务账务服务1:业务约束检查2业务数据处理loop,3:账务处理4约束检查5记账6根据账务处理结果进一处理业务数据L完成业务处理在一次业务处理中,可能多次调用账务处理,并根据眯务处理的结果决定是否业务处理是否成功。这种模式可以概括如下(1)支付宝的主体业务服务在执行过程中一般郁会涉及到一次或者多次的账务处理。(2)业务服务与账务服务对业务处理的最终结果有同等的决定权,两者都能够使业务处理失败(3)当一次业务处理中涉及到超过两个参与者时,附加的参与者一般对业务处理的最终结果没有决定权,但它们会根据业务处理的最终结界完成自己的处理。例如,很多业务在完成之后都涉及到攻费的处理,但一般牧费不成功不会影响业务处理本身的结果。根据两参与者的特点,以及账务服务的中心地位,我们可以根据“两阶段提交协议”以及“最术參与者优化”原理,设计支付宝分布式事务处理的基模型。32基础模型这一蓐础模型如下图所示事务管理域业务处理域本地事务域开始主事务业务服务直询)管理器提父(4)勾对事务恢复daemon确认取消账务操作(账务确认查询、分支事务(准备账务前置管理器长务取消(2)dol账务核心本地事务域在上图中,各个主要组件的职责如下:(1)业务服务业务服务负责具体业务处理,如交易服务、红包服务等等com(2)账务前置账务前置负责接收、检查并缓冲从业务服务发起的账务请求。(3)账务核心负责记账并更新分户余额。(4)主事务管理器与业务服务位丁同个本地事务域,负责主事务的启动、提交与回滚。(5)分支事务管理器与账务服务位于同一个本上事务域,负责分支事务的准备,确认与取消。(G)事务恢复 daemon定时运行,负责恢复处于已准备状态,但在指定时间阙值内尚未确认或者取消的事务。下面我们介绍上述组件如何通过协作完成一次包含账务的业务处理。33准备阶段下图显示在“准备”阶段各个组件间的交互过稈。业务服务主事务管理器账务前置账务核心分支事务管理器1:开始主事务loop2请求务处理:前置约检查账务约束检预冻结资7返回账务理结果6.记表分支事务三:继续业务处理1.业务服务(])首先向主事务管理器请求开始主事务,此时,主事务管理器启动本地享务,按照一定规则生成一个对本次处理唯一的txd,记录主事务日志,并在事务上下文中记录txd,这个txd在整个分布式事务的生命周期中用于建立主事务与分支事务之间的对应关系,并用于业务重复性检查2.业务服务向账务前置发送账务处理请求。主事务管理器能够拦截次请求,并将主事务D(txd}附加到账务处理请求的上下文中,一起发送给账务前置。3.账务前置进行前置约束检昋。前置约束检杳至少要保证:a.事务ld有效;b.业务不重复。前置约東检査前,相关账户必须锁定〔除特定账户外、如屮间账户等)。4.账务前置调用账务核心进行账务约束检查。账务约束检查至少要保证:a.账户状态正确b.账户资金足够;c.其它账务约束满足。账务约束检杳时必须考虑刭在本事务中尚未到达的资金,因此这是检查中比较特姝的地方,需要恰当处理。5.账务前置调用账务核心进行资金冻结。对于完成本次账务处需要的资金,需要一种特殊的方式冻结起来,但这种冻结没有业务含义,因此,不应该记录资金冻结日忐,只是在 freeze amount中增加这笔冻结资金,确保账务确认阶段能够使用这笔资金。如果本次账务处理所需要的资金尚未到达,则不需要冻结。6.账务前置调用分支事务管理器记录分支事务日志。分支事务日志中记录了本次账务处理的内容以及冻结的金额,在确认阶段,分支事务管理器会根据分支事务日志中记录的内容驱动账务系统完成预冻结金额的解冻与实际的账务处哩7.账务前向业务服务返叵账务处理的结果8.业务服务根据账务处理的结果继续进行业务处理在一次业务处理过程上,上述交互过程允许进行发生多次。但为了控制远程调用的成本,也可以将账务请求打成包合并发送给账务前置。34确认阶段下图显示在“确认”阶段各个组件的交互过程。业务服务主事务管理器分支事务管器账务前置账务核心(31提交事务2完成本地事务提3返回提交结果4:确认分支事务6解冻冻结资7请求账务处理8约束检查Lp做啡并更新余额p:回账务处理结返回账务确认结12:勾对主事务1.业务服务请求主事务管理器提交事务。2.主事务管理器首先完成本地事务的提交。3.主事务管理器向业务系统返回事务提交的结果。4.主事务管理器甸分支事务管理器确认分支事务结果。分支事务管理器顺序处理对应于本次分布式事务的每一条分支事务日志,对每一条分支事囗志,调用账筹前置确认该次处理。6.账务前資首先请求账务核心解冻预冻结的资金。7.账务前置请求账务核心进行账务处理8.账务核心对本次账务处理进行约東检查。对于特定的检查(比如账户状态是否有效等)是否需要做,视业务而定。9.账务核心进行账务处理,包含记录账务口志并更新账户余额等。其它正常账务处理中需要执行的工作也同样需要做。