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