1、大规模SOA系统中的分布事务处理程立支付宝产品技术与用户体验部2008年12月提要 从单应用系统的事务 到大规模SOA系统中的事务 内容提要 山穷水尽(背景与历史) 柳暗花明(原则与模式) 又一山寨(框架与设施)应用数据库数据遗留系统集成开放服务流程服务客户的系统业务服务 领域服务合作伙伴的系统合作伙伴集成门户服务数据数据数据数据数据10:33 2山穷水尽Googling “transaction processing”约有1,940,000 项符合的查询结果 “distributed transaction”约有260,000 项符合的查询结果 “distributed transactio
2、n”+ practice约有24,700 项符合的查询结果 “distributed transaction”+ “success story”约有265 项符合的查询结果 null “distributed transaction” + sucks约有1,370 项符合的结果 “distributed transaction” + hope约有17,500 项符合的结果 10:33 3事务事务:由一组操作构成的可靠、独立的工作单元ACID: Atomicity(原子性) Consistency(一致性) Isolation(隔离性) Durability(持久性)难点: 高度并发 资源分布
3、大时间跨度操作时间资源位置A11 2 3 4 5ABC C1B3C4A5事务1事务2事务310:33 4本地事务本地事务事务由资源管理器（如DBMS）本地管理优点 支持严格的ACID属性 可靠 高效 状态可以只在资源管理器中维护 应用编程模型简单(在框架或平台的支持)局限 不具备分布事务处理能力 隔离的最小单位由资源管理器决定，如数据库中的一条记录应用/应用服务器/应用框架AP资源管理器RM开始会话开始事务操作1操作n提交/回滚事务完成会话锁日志10:33 5资源管理器RM2全局事务(DTP模型)应用/应用框架/应用服务器AP资源管理器RM13. 操作1n6. 提交事务事务管理器TM1. 开始
4、全局事务2. 注册资源14. 注册资源25. 操作1n7. 准备8. 准备9. 提交10. 提交全局事务事务由全局事务管理器全局管理事务管理器管理全局事务状态与参与的资源，协同资源的一致提交/回滚TX协议应用或应用服务器与事务管理器的接口XA协议全局事务管理器与资源管理器的接口10:33 6两阶段提交(Two Phase Commit)准备操作与ACID A: 准备后，仍可提交与回滚 C: 准备时，一致性检查必须OK I: 准备后，事务结果仍然只在事务内可见 D: 准备后，事务结果已经持久局限 协议成本 (准备操作是一定必须的吗） 准备阶段的持久成本 全局事务状态的持久成本 潜在故障点多带来的
5、脆弱性 准备后，提交前的故障引发一系列隔离与恢复难题事务管理器TM资源管理器RM11. 准备OK3. 提交OK资源管理器RM22. 准备OK4. 提交OK事务管理器TM资源管理器RM11. 准备OK3. 回滚OK资源管理器RM22. 准备NO4. 回滚OK10:33 7通信资源管理器CRM通信资源管理器CRM跨域的全局事务(DTP模型)问题 事务上下文如何跨域传递? 多事务管理器如何协同? 异构事务域间的标准是什么?通信资源管理器管理事务域间或事务域内的通信，允许全局事务信息跨域传递XA+协议是XA的超集，增加指令使事务管理器间可以相互协同局限 更高协议成本 脆弱，故障点多 故障影响大，恢复困
6、难 复杂，更多架构与平台约束应用/应用框架/应用服务器AP资源管理器RM1事务管理器TM资源管理器RM通信资源管理器CRM应用/应用框架/应用服务器AP资源管理器RM1事务管理器TM资源管理器RM通信资源管理器CRM主事务域分支事务域XATXXATXXA+XA+TxRPC等TxRPC等10:33 8Java企业平台中的分布事务实现JTA面向应用、应用服务器与资源管理器的高层事务接口JTSJTA事务管理器的实现标准，向上支持JTA，向下通过CORBA OTS实现跨事务域的互操作性EJB基于组件的应用编程模型，通过声明式事务管理进一步简化事务应用的编程优点 简单一致的编程模型 跨域分布处理的ACI
7、D保证局限 DTP模型本身的局限 缺少充分公开的大规模、高可用、密集事务应用的成功案例10:33 9其它资源WS-Transaction标准OASIS组织通过的Web Service事务标准，包含WS-Cordination、WS-AtomicTransaction、WS-BusinessActivityJbossTransactions系统开源的JTA、JTS、WS-Transaction标准的实现Paxos算法分布式系统中就某个提议达成一致决议的算法族10:33 10柳暗花明原则 真正重要的是满足业务需求，而不是追求抽象、绝对的系统特性 帽子戏法：两只手最多能拿几顶帽子？ 酸碱平衡(ACI
8、D-BASE Balance)模式 服务模式1. 可查询操作2. 幂等操作3. TCC操作4. 可补偿操作 复合模式1. 定期校对2. 可靠消息3. TCC4. 补偿10:33 11帽子戏法CAP定理对于共享数据系统，只能同时拥有以下三项中的两个： Consistency(一致性): 所有用户看到一致的数据 Availability(可用性): 总能找到一个可用的数据复本 Tolerance to Network Partition(分区容忍性): 即使在系统被分区的情况下，仍然满足上述两点10:33 12酸碱平衡BASE BA(Basic Availability)基本可用性 S(Soft
9、state)柔性状态 E(Eventuall consistency)最终一致性10:33 13eBay的BASE最佳实践 At eBay, we allow absolutely no clientside or distributed transactions of any. Of course, we do employ various techniques to help the system reach eventual consistency: careful ordering of database operations, asynchronous recovery events
10、, and reconciliation or settlement batches. We choose the technique according to the consistency demands of the particular use case.Randy Shoup，eBay的杰出架构师10:33 14服务模式1: 可查询操作服务操作的可标识性 服务操作具有全局唯一标识 可以使用业务单据号 或者使用系统分配的操作流水号 或者使用操作资源的唯一标识+操作类型的组合 操作有唯一的、确定的时间(约定以谁的时间为准)单笔查询 使用全局唯一的服务操作标识，查询操作执行结果 小心“处理
11、中”状态批量查询使用时间区段与(或)一组服务操作的标识，查询一批操作执行结果业务服务doX queryX batchQueryX10:33 15复合模式1: 定期校对实现 业务活动的主动方，在完成业务处理之后，向业务活动的被动方发送消息。允许消息丢失。 业务活动的被动方根据定时策略，向业务活动主动方查询，恢复丢失的业务消息 。约束 被动方的处理结果不影响主动方的处理结果成本 业务查询与校对系统的建设成本适用范围 对业务最终一致性的时间敏感度低 跨企业的业务活动业务处理服务实时消息服务数据库实时处理网关数据库定期校对系统事务域事务域业务处理服务业务查询/下载服务主动方被动方10:33 16保证消
12、息在事务提交后才发送要求消息发送必须严格在事务提交后方可进行一种实现方案 使用拦截器拦截发送消息请求 拦截器检测到当前存在活动事务，就创建一个事务同步器 并向事务管理器注册事务同步器 业务处理事务完成后，事务管理器会调用事务同步器 事务同步器判断当前事务状态为已提交，才真正发送消息业务处理服务消息服务事务同步器事务管理器拦截器1. 开始事务4. 提交事务数据库2. 操作3. 发消息3.1 创建事务同步器3.2 注册事务同步器4.1 调用事务同步器4.1.1 发消息10:33 17服务模式2: 幂等操作幂等性(Idempotenty)f(f(x) = f(x)幂等操作重复调用多次产生的业务结果与
13、调用一次产生的业务结果相同实现方式一通过业务操作本身实现幂等性实现方式二 系统缓存所有请求与处理结果 检测到重复请求之后，自动返回之前的处理结果业务服务doX10:33 18复合模式2: 可靠消息实现 业务活动的主动方，在完成业务处理的同一个本地事务中，记录消息数据 业务处理事务提交后、通过实时消息服务通知业务被动方，实时通知成功后删除消息数据 消息恢复系统定期找到未成功发送的消息，交给实时消息服务补发送约束 被动方的处理结果不影响主动方的处理结果 被动方的消息处理操作是幂等操作成本 可靠消息系统建设成本 消息数据CRUD成本适用范围 对最终一致性时间敏感度较高 降低业务被动方实现成本业务处理
14、服务实时消息服务实时处理网关数据库事务域事务域业务处理服务主动方被动方业务数据消息数据消息恢复系统10:33 19可靠消息的另一种实现实现 业务处理服务在业务事务提交前，向实时消息服务请求发送消息，实时消息服务只记录消息数据，而不真正发送 业务处理服务在业务事务提交后，向实时消息服务确认发送。只有在得到确认发送指令后，实时消息服务才真正发送消息 业务处理服务在业务事务回滚后，向实时消息服务取消发送 消息状态确认系统定期找到未确认发送或回滚发送的消息，向业务处理服务询问消息状态，业务处理服务根据消息ID或消息内容确定该消息是否有效成本 一次消息发送需要两次请求 业务处理服务需实现消息状态回查接口
15、优点 消息数据独立存储、独立伸缩 降低业务系统与消息系统间的耦合业务处理服务实时消息服务事务域业务数据消息恢复系统消息数据消息状态确认系统事务域发送消息请求发送 确认发送 取消发送询问消息状态10:33 20服务模式3: TCC操作Try: 尝试执行业务 完成所有业务检查(一致性) 预留必须业务资源(准隔离性)Confirm:确认执行业务 真正执行业务 不作任何业务检查 只使用Try阶段预留的业务资源 Confirm操作满足幂等性Cancel: 取消执行业务 释放Try阶段预留的业务资源 Cancel操作满足幂等性与2PC协议比较 位于业务服务层而非资源层 没有单独的准备(Prepare)阶段
16、，Try操作兼备资源操作与准备能力 Try操作可以灵活选择业务资源的锁定粒度 较高开发成本业务服务tryX confirmX cancelX10:33 21复合模式3: TCC模式实现 一个完整的业务活动由一个主业务服务与若干从业务服务组成 主业务服务负责发起并完成整个业务活动 从业务服务提供TCC型业务操作 业务活动管理器控制业务活动的一致性，它登记业务活动中的操作，并在业务活动提交时确认所有的TCC型操作的confirm操作，在业务活动取消时调用所有TCC型操作的cancel操作成本 实现TCC操作的成本 业务活动结束时confirm或cancel操作的执行成本 业务活动日志成本适用范围
17、强隔离性、严格一致性要求的业务活动 适用于执行时间较短的业务主业务服务从业务服务A从业务服务B数据库数据库数据库tryX1. tryX成功业务活动管理器活动日志启动业务活动登记业务操作提交/回滚业务活动confirmXcancelXtryYconfirmYcancelY2. tryY成功3. confirmX成功4. confirmY成功10:33 22服务模式4: 可补偿操作业务服务doX compensateXdo: 真正执行业务 完成业务处理 业务执行结果外部可见compensate:业务补偿 抵销(或部分抵销)正向业务操作的业务结果 补偿操作满足幂等性约束 补偿在业务上可行 由于业务执
18、行结果未隔离、或者补偿不完整带来的风险与成本可控10:33 23复合模式4: 补偿模式实现 一个完整的业务活动由一个主业务服务与若干从业务服务组成，一般由主业务服务发起并结束整个业务活动 从业务服务提供的业务操作提供补偿操作，补偿操作可以抵销(或部分抵销)正向业务操作的业务结果 业务活动管理器控制业务活动的一致性，它登记业务活动中的操作，并在业务活动取消时调用补偿操作成本 从业务服务实现补偿操作的成本 由于无法完全补偿带来的业务成本 业务活动回滚时，需要额外调用补偿操作适用范围 弱隔离性、弱一致性要求的业务活动 特别适用于执行时间较长的业务，如工作流主业务服务从业务服务A从业务服务B数据库数据
19、库数据库业务操作补偿操作业务操作1. 业务操作成功2. 业务操作失败3. 执行业务补偿业务活动管理器活动日志启动业务活动登记业务操作提交/回滚业务活动10:33 24商业流程也是事务 事务管理有时是商业流程与用户体验的一部分 并非所有问题都可以或应该由系统来解决物流 银行交易中介10:33 25付款发货 收货收款又一山寨10:33 26框架与设施建设目标 一致的架构风格 简单的编程模型 万无一失 没商量: 高可用与可伸缩 轻量，可扩展 尽力优化性能 利用现有基础设施概念架构业务活动一个完整的业务处理过程，处理中包含多个服务操作，这些服务操作构成了一棵调用树原子动作 对应于一次服务操作调用。每个
20、原子动作作为业务活动的基本单元，通过本地事务满足ACID。 原子动作有不同的调用类型，如请求-应答、异步消息、异步可靠消息等。 原子动作对应的服务操作也有各种类型，如TCC型、可补偿型、幂等型等主控动作 主控动作是整个业务活动的发起者，也是服务操作调用树的根 可以合理地让主控动作本身的提交与回滚决定整个业务活动的提交与回滚流程服务业务服务领域服务集成服务领域服务业务服务集成服务DBDBDBDB DBDBDB业务活动主控动作原子动作10:33 27业务活动模型BusinessActivity业务活动，其中包括的任意多个原子动作需要满足事务要求（ACID/BASE）AtomicAction原子动作
21、，是一个业务活动中不可分的业务处理单元。一个原子动作的执行满足ACID。其背后，是通过对某个服务操作的一次调用实现的ServiceOperation服务操作，是某个业务领域功能的原子实现。服务操作有类型标识，表明它是幂等型、TCC型还是补偿型操作BusinessActivityId业务活动Id，是业务活动的唯一标识。业务活动Id由三个部分组成，分别代表业务活动所属的业务领域、对应的业务操作与被操作的实体对象的Id+状态: Enum+时间: DateBusinessActivity(业务活动)BusinessActivityId业务活动Id+业务领域: String+业务操作: String+实
22、体Id: StringAtomicAction(原子动作)+调用类型: Enum(请求-应答/异步消息/可靠异步消息)ServiceOperation(服务操作)+类型: Enum(TCC/补偿/幂等)+其它属性10:33 28关键组件业务活动管理器管理业务活动上下文，操作业务活动日志，协同各个参与者完成业务活动的提交与回滚操作客户端拦截器拦截服务调用，在消息中附加业务活动上下文，以实现业务活动上下文跨服务传递。在业务活动中添加原子动作服务端拦截器拦截服务请求，从消息中析取业务活动上下文，并启动本地业务活动业务活动日志记录业务活动的状态，记录参与业务活动的原子动作业务活动恢复器记录业务活动的状
23、态，记录参与业务活动的原子动作服务端拦截器服务容器服务客户端拦截器业务活动管理器服务端拦截器服务容器服务客户端拦截器业务活动日志服务本地数据服务本地数据10:33 29业务活动恢复器业务活动管理器业务活动恢复器业务活动管理器(BAM)UserBusinessActivity接口面向应用的接口，允许开发者通过本接口启动业务活动，指定业务活动Id。启动业务活动的业务服务成为本次业务活动的主控业务服务BusinessActivityManager接口面向框架的接口，由框架实现者提交或回滚业务活动，以及将原子活动作为参与者添加到业务活动的上下文。业务活动的提交或回滚由主控业务服务本地事务的提交或回滚决定BusinessActivityManagerImpl类上述接口的实现BusinessActivityManagerImpl(业务活动管理器实现)UserBusinessActivity(业务活动用户控制接口)+start(BusinessActivityId)BusinessActivityManager(业务活动框架控制接口)+commit()+rollback()+enlistAction()+delistAction()10:33 30
