支付宝分布式事务设计草案.docxVIP

支付宝分布式事务架构设计草案 1 背景介绍 为了应对快速变化的市场需求、持续增长的业务量，支付宝系统需要基于 SOA 进行构建与 改造，以应对系统规模和复杂性的挑战，更好地进行企业内与企业间的协作。 基于 SOA 图景，整个支付宝系统会拆分成一系列独立开发、自包含、自主运行的业务服务， 并将这些服务通过各种机制灵活地组装成最终用户所需要的产品与解决方案。支付宝系统 将会有类似下图所示的 SOA 模型： 流程平台内部单点 流程平台 内部单点登录与统一 权限管理平台 确保任务与通知 分布式 时间调度服务 搜索 服务质量监控 核心服务 交易核心 会员核心 账务核心 组合、增值服务 交易类服务 标准担保... 标准即时到账... 行业：彩票、机票... 资金类 充、提、转 冻结、解冻 代充/代付 会员类 注册、激活 认证 个性化定制 交易工具类 红包 会员访问服务 标准前台 商户前台 社区 帮助中心 操作员访问服务 结算后台 服务后台 销售后台 管理分析服务 会计核算中心 风控中心 对账中心 计费中心 会员Profile 服务 计息中心 外部互联服务 银行B2C/B网关 卡通网关 银企直连网关 统一商户接口 短信SP网关 沟通服务 ESB 分布式事务  产品元数据组件  语义映射与验证组件  事件引擎组件  轻量流程组件  SOFA SOFA组件框架 开发 工具 在 SOA 的系统架构下，一次业务请求将会跨越多个服务。我们举一个使用红包+余额进行 交易付款的例子来说明。 前台web交 前台web 交易服务 红包服务 账务服务 1.交易付款 5.余额支付  红包清算 保证金解冻 4.保证金转账 在多个服务协同完成一次业务时，由于业务约束（如红包不符合使用条件、账户余额不足 等）、系统故障（如网络或系统超时或中断、数据库约束不满足等），都可能造成服务处理 过程在任何一步无法继续，使数据处于不一致的状态，产生严重的业务后果。 传统的基于数据库本地事务的解决方案只能保障单个服务的一次处理具备原子性、隔离性、 一致性与持久性，但无法保障多个分布服务间处理的一致性。因此，我们必须建立一套分 布式服务处理之间的协调机制，保障分布式服务处理的原子性、隔离性、一致性与持久性。 2 基本原理 2.1 两阶段提交协议(2PC) 传统的分布式事务处理是基于两阶段提交协议的。两阶段提交协议的原理如下图所示： 分布式事务协调者 分布式事务协调者 分布式事务参与者 分布式事务参与者 分布式事务协调者 分布式事务参与者 分布式事务参与者 1.准备 2.已准备 5.提交 6.完成  3.准备 4.已准备 7.提交 8.完成 成功的两阶段提交(2PC)示例 1.准备 2.已准备 5.放弃 6.完成  3.准备 4.已放弃 7.放弃 8.完成 失败的两阶段提交(2PC)示例 从上图可见，两阶段提交协议的关键在于“准备”操作。分布式事务协调者在第一阶段通 过对所有的分布式事务参与者请求“准备”操作，达成关于分布式事务一致性的共识。分 布式事务参与者在准备阶段必须完成所有的约束检查、并且确保后续提交或放弃时所需要 的数据已持久化。在第二队段，分布式事务协调者根据之前达到的提交或放弃的共识，请 求所有的分布式事务参与者完成相应的操作。 2.2 最末参与者优化(LPO) 两阶段提交协议要求分布式事务参与者实现一个特别的“准备”操作，无论在资源管理器 （如数据库）还是在业务服务中实现该操作都存在效率与复杂性的挑战。因此，两阶段提 交协议有一个重要的优化，称为“最末参与者优化”（Last Participant Optimization），允许 两阶段提交协议中有一个参与者不实现“准备”操作（称为单阶段参与者）。最末参与者优 化的原理如下图所示： 分布式事务协调者 分布式事务协调者 两阶段参与者 单阶段参与者 分布式事务协调者 两阶段参与者 单阶段参与者 1.准备 2.已准 备 5.提交 6.完成  3.提交 4.完成 最末参与者优化(LPO)示例 成功场景 1.准备 2.已准 备 5.放弃 6.完成  3.提交 4.放弃 最末参与者优化(LPO)示例 失败场景 从上图可见， LPO 中，单阶段参与者不需要实现准备操作，只需要提供标准的提交操作即 可。分布式事务协调者必须等其余两阶段参与者都准备好之后，再请求单阶段参与者提交， 单阶段参与者的提交结果将决定整个分布式事务的结果。本质上，LPO 是将最后一个参与 者的准备操作与提交/放弃操作合并成一个提交操作。 最末参与者优化方案使得我们能够利用支付宝业务的特点，尽量简化分布式事务的实现。 2.3X/Open 模型 X/Open 组织为基于两阶段协议的分布式事务处理系统提出了标准的系统参考模型（X/Open 事务