支付宝分布式事务设计草案讲述.doc

支付宝分布式事务架构设计草案 背景介绍 为了应对快速变化的市场需求、持续增长的业务量，支付宝系统需要基于SOA进行构建与改造，以应对系统规模和复杂性的挑战，更好地进行企业内与企业间的协作。 基于SOA图景，整个支付宝系统会拆分成一系列独立开发、自包含、自主运行的业务服务，并将这些服务通过各种机制灵活地组装成最终用户所需要的产品与解决方案。支付宝系统将会有类似下图所示的SOA模型： 在SOA的系统架构下，一次业务请求将会跨越多个服务。我们举一个使用红包+余额进行交易付款的例子来说明。 在多个服务协同完成一次业务时，由于业务约束（如红包不符合使用条件、账户余额不足等）、系统故障（如网络或系统超时或中断、数据库约束不满足等），都可能造成服务处理过程在任何一步无法继续，使数据处于不一致的状态，产生严重的业务后果。 传统的基于数据库本地事务的解决方案只能保障单个服务的一次处理具备原子性、隔离性、一致性与持久性，但无法保障多个分布服务间处理的一致性。因此，我们必须建立一套分布式服务处理之间的协调机制，保障分布式服务处理的原子性、隔离性、一致性与持久性。 基本原理 两阶段提交协议(2PC) 传统的分布式事务处理是基于两阶段提交协议的。两阶段提交协议的原理如下图所示： 从上图可见，两阶段提交协议的关键在于“准备”操作。分布式事务协调者在第一阶段通过对所有的分布式事务参与者请求“准备”操作，达成关于分布式事务一致性的共识。分布式事务参与者在准备阶段必须完成所有的约束检查、并且确保后续提交或放弃时所需要的数据已持久化。在第二队段，分布式事务协调者根据之前达到的提交或放弃的共识，请求所有的分布式事务参与者完成相应的操作。 最末参与者优化(LPO) 两阶段提交协议要求分布式事务参与者实现一个特别的“准备”操作，无论在资源管理器（如数据库）还是在业务服务中实现该操作都存在效率与复杂性的挑战。因此，两阶段提交协议有一个重要的优化，称为“最末参与者优化”（Last Participant Optimization），允许两阶段提交协议中有一个参与者不实现“准备”操作（称为单阶段参与者）。最末参与者优化的原理如下图所示： 从上图可见， LPO中，单阶段参与者不需要实现准备操作，只需要提供标准的提交操作即可。分布式事务协调者必须等其余两阶段参与者都准备好之后，再请求单阶段参与者提交，单阶段参与者的提交结果将决定整个分布式事务的结果。本质上，LPO是将最后一个参与者的准备操作与提交/放弃操作合并成一个提交操作。 最末参与者优化方案使得我们能够利用支付宝业务的特点，尽量简化分布式事务的实现。 X/Open模型 X/Open组织为基于两阶段协议的分布式事务处理系统提出了标准的系统参考模型（X/Open事务模型）、以及不同组件间与事务协调相关的接口，使不同厂商的产品能够互操作。X/Open事务模型如下图所示： 从上图可以看出，X/Open模型定义了两个标准接口：TX接口用于应用程序向事务管理器发起事务、提交事务和回滚事务（即确定事务的边界和结果）；XA接口用于事务管理器将资源管理器（如数据库、消息队列等）加入事务、并控制两阶段提交。 事务管理器一般由专门的中间件提供、或者在应用服务器中作为一个重要的组件提供。资源管理器如数据库、消息队列一般也会提供XA支持。通过使用符合X/Open标准的分布式事务处理，能够简化分布式事务类应用的开发。 但在现实中，事务管理器与资源管理器对TX/XA协议的实现上存在效率、可靠性与伸缩性上的风险；在两阶段提交协议执行过程中的异常恢复起来也很困难；而且在SOA体系下当事务需要跨越多个服务（而不是多个资源管理器）时，事务的协调与恢复会变得非常复杂。 在标准分布式事务管理框架不能满足需要的情况下，我们需要根据支付宝业务与系统的特点，设计并实现自己的分布式事务处理机制。下一节介绍支付宝分布式事务处理的基础模型。 基础模型 典型业务处理模式 支付宝的主体业务基本都会在一次业务处理中进行一次或多次账务处理。典型的业务处理模式如下图所示： 这种模式可以概括如下： 支付宝的主体业务服务在执行过程中一般都会涉及到一次或者多次的账务处理。 业务服务与账务服务对业务处理的最终结果有同等的决定权，两者都能够使业务处理失败。 当一次业务处理中涉及到超过两个参与者时，附加的参与者一般对业务处理的最终结果没有决定权，但它们会根据业务处理的最终结果完成自己的处理。例如，很多业务在完成之后都涉及到收费的处理，但一般收费不成功不会影响业务处理本身的结果。 根据两参与者的特点，以及账务服务的中心地位，我们可以根据“两阶段提交协议”以及“最末参与者优化”原理，设计支付宝分布式事务处