没有合适的资源?快使用搜索试试~ 我知道了~
首页分布式事务应用:支付宝分布式事务设计
分布式事务应用:支付宝分布式事务设计

分布式事务应用:支付宝分布式事务设计 分布式事务应用:支付宝分布式事务设计
资源详情
资源评论
资源推荐

支付宝分布式事务架构设计
1 背景介绍
为了应对快速变化的市场需求、持续增长的业务量,支付宝系统需要基于 SOA 进行构建与
改造,以应对系统规模和复杂性的挑战,更好地进行企业内与企业间的协作。
基于 SOA 图景,整个支付宝系统会拆分成一系列独立开发、自包含、自主运行的业务服务 ,
并将这些服务通过各种机制灵活地组装成最终用户所需要的产品与解决方案。支付宝系统
将会有类似下图所示的 SOA 模型:

ESB
交易核心
账务核心
会员核心
核心服务
组合、增值服务
交易类服务
资金类
会员类
标准担保. . .
红包
标准即时到账. . .
行业:彩票、机票. . .
交易工具类
充、提、转
冻结、解冻
注册、激活
会员访问服务 操作员访问服务
标准前台
商户前台
结算后台
社区
帮助中心
服务后台
销售后台
管理分析服务
风控中心
会计核算中心
对账中心
计费中心
外部互联服务
认证
银行B2C/ B网关
卡通网关
统一商户接口
短信SP网关
沟通服务
会员Pro l e
服务
计息中心
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)示例
从上图可见,两阶段提交协议的关键在于“准备”操作。分布式事务协调者在第一阶段通过
对所有的分布式事务参与者请求“准备”操作,达成关于分布式事务一致性的共识。分布式
事务参与者在准备阶段必须完成所有的约束检查、并且确保后续提交或放弃时所需要的数
据已持久化。在第二队段,分布式事务协调者根据之前达到的提交或放弃的共识,请求所
有的分布式事务参与者完成相应的操作。
2.2 最末参与者优化(LPO)
两阶段提交协议要求分布式事务参与者实现一个特别的“准备”操作,无论在资源管理器
(如数据库)还是在业务服务中实现该操作都存在效率与复杂性的挑战。因此,两阶段提
交协议有一个重要的优化,称为“最末参与者优化”(Last Parcipant Opmizaon),允许两
阶段提交协议中有一个参与者不实现“准备”操作(称为单阶段参与者)。最末参与者优化
的原理如下图所示:
剩余16页未读,继续阅读















安全验证
文档复制为VIP权益,开通VIP直接复制

评论1