大规模SOA系统中的分布事务处事_程立（PDF35页）

大规模SOA系统中的分布事务处理程立支付宝产品技术与用户体验部2008年12月提要•从单应用系统的事务•到大规模SOA系统中的事务•内容提要–山穷水尽(背景与历史)–柳暗花明(原则与模式)–又一山寨(框架与设施)应用数据库数据遗留系统集成开放服务流程服务客户的系统业务服务领域服务合作伙伴的系统合作伙伴集成门户服务数据数据数据数据数据10:332山穷水尽Googling•“transactionprocessing”约有1,940,000项符合的查询结果•“distributedtransaction”约有260,000项符合的查询结果•“distributedtransaction”+practice约有24,700项符合的查询结果•“distributedtransaction”+“successstory”约有265项符合的查询结果•“distributedtransaction”+sucks约有1,370项符合的结果•“distributedtransaction”+hope约有17,500项符合的结果☺10:333事务事务:由一组操作构成的可靠、独立的工作单元ACID:•Atomicity(原子性)•Consistency(一致性)•Isolation(隔离性)•Durability(持久性)难点:•高度并发•资源分布•大时间跨度操作时间资源位置A112345ABCC1B3C4A5事务1事务2事务310:334本地事务本地事务事务由资源管理器（如DBMS）本地管理优点•支持严格的ACID属性•可靠•高效•状态可以只在资源管理器中维护•应用编程模型简单(在框架或平台的支持)局限•不具备分布事务处理能力•隔离的最小单位由资源管理器决定，如数据库中的一条记录应用/应用服务器/应用框架AP资源管理器RM开始会话开始事务操作1…操作n提交/回滚事务完成会话锁日志10:335资源管理器RM2全局事务(DTP模型)应用/应用框架/应用服务器AP资源管理器RM13.操作1..n6.提交事务事务管理器TM1.开始全局事务2.注册资源14.注册资源25.操作1..n7.准备8.准备9.提交10.提交全局事务事务由全局事务管理器全局管理事务管理器管理全局事务状态与参与的资源，协同资源的一致提交/回滚TX协议应用或应用服务器与事务管理器的接口XA协议全局事务管理器与资源管理器的接口10:336两阶段提交(TwoPhaseCommit)准备操作与ACID•A:准备后，仍可提交与回滚•C:准备时，一致性检查必须OK•I:准备后，事务结果仍然只在事务内可见•D:准备后，事务结果已经持久局限•协议成本(准备操作是一定必须的吗）•准备阶段的持久成本•全局事务状态的持久成本•潜在故障点多带来的脆弱性•准备后，提交前的故障引发一系列隔离与恢复难题事务管理器TM资源管理器RM11.准备OK3.提交OK资源管理器RM22.准备OK4.提交OK事务管理器TM资源管理器RM11.准备OK3.回滚OK资源管理器RM22.准备NO4.回滚OK10:337通信资源管理器CRM通信资源管理器CRM跨域的全局事务(DTP模型)问题•事务上下文如何跨域传递?•多事务管理器如何协同?•异构事务域间的标准是什么?通信资源管理器管理事务域间或事务域内的通信，允许全局事务信息跨域传递XA+协议是XA的超集，增加指令使事务管理器间可以相互协同局限•更高协议成本•脆弱，故障点多•故障影响大，恢复困难•复杂，更多架构与平台约束应用/应用框架/应用服务器AP资源管理器RM1事务管理器TM资源管理器RM通信资源管理器CRM应用/应用框架/应用服务器AP资源管理器RM1事务管理器TM资源管理器RM通信资源管理器CRM主事务域分支事务域XATXXATXXA+XA+TxRPC等TxRPC等10:338Java企业平台中的分布事务实现JTA面向应用、应用服务器与资源管理器的高层事务接口JTSJTA事务管理器的实现标准，向上支持JTA，向下通过CORBAOTS实现跨事务域的互操作性EJB基于组件的应用编程模型，通过声明式事务管理进一步简化事务应用的编程优点•简单一致的编程模型•跨域分布处理的ACID保证局限•DTP模型本身的局限•缺少充分公开的大规模、高可用、密集事务应用的成功案例10:339其它资源WS-Transaction标准OASIS组织通过的WebService事务标准，包含WS-Cordination、WS-AtomicTransaction、WS-BusinessActivityJbossTransactions系统开源的JTA、JTS、WS-Transaction标准的实现Paxos算法分布式系统中就某个提议达成一致决议的算法族10:3310柳暗花明原则•真正重要的是满足业务需求，而不是追求抽象、绝对的系统特性•帽子戏法：两只手最多能拿几顶帽子？•酸碱平衡(ACID-BASEBalance)模式•服务模式1.可查询操作2.幂等操作3.TCC操作4.可补偿操作•复合模式1.定期校对2.可靠消息3.TCC4.补偿10:3311帽子戏法CAP定理对于共享数据系统，只能同时拥有以下三项中的两个：•Consistency(一致性):所有用户看到一致的数据•Availability(可用性):总能找到一个可用的数据复本•TolerancetoNetworkPartition(分区容忍性):即使在系统被分区的情况下，仍然满足上述两点10:3312酸碱平衡BASE•BA(BasicAvailability)基本可用性•S(Softstate)柔性状态•E(Eventuallconsistency)最终一致性10:3313eBay的BASE最佳实践•At eBay, we allow absolutely no client‐side 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, and reconciliation or settlement batches. •We choose the technique according to the consistency demands of the particular use case.RandyShoup，eBay的杰出架构师10:3314服务模式1:可查询操作服务操作的可标识性•服务操作具有全局唯一标识–可以使用业务单据号–或者使用系统分配的操作流水号–或者使用操作资源的唯一标识+操作类型的组合•操作有唯一的、确定的时间(约定以谁的时间为准)单笔查询•使用全局唯一的服务操作标识，查询操作执行结果•小心“处理中”状态批量查询使用时间区段与(或)一组服务操作的标识，查询一批操作执行结果业务服务doXqueryXbatchQueryX10:3315复合模式1:定期校对实现•业务活动的主动方，在完成业务处理之后，向业务活动的被动方发送消息。允许消息丢失。•业务活动的被动方根据定时策略，向业务活动主动方查询，恢复丢失的业务消息。约束•被动方的处理结果不影响主动方的处理结果成本•业务查询与校对系统的建设成本适用范围•对业务最终一致性的时间敏感度低•跨企业的业务活动业务处理服务实时消息服务数据库实时处理网关数据库定期校对系统事务域事务域业务处理服务业务查询/下载服务主动方被动方10:3316保证消息在事务提交后才发送要求消息发送必须严格在事务提交后方可进行一种实现方案•使用拦截器拦截发送消息请求•拦截器检测到当前存在活动事务，就创建一个事务同步器•并向事务管理器注册事务同步器•业务处理事务完成后，事务管理器会调用事务同步器•事务同步器判断当前事务状态为已提交，才真正发送消息业务处理服务消息服务事务同步器事务管理器拦截器1.开始事务4.提交事务数据库2.操作3.发消息3.1创建事务同步器3.2注册事务同步器4.1调用事务同步器4.1.1发消息10:3317服务模式2:幂等操作幂等性(Idempotenty)f(f(x))=f(x)幂等操作重复调用多次产生的业务结果与调用一次产生的业务结果相同实现方式一通过业务操作本身实现幂等性实现方式二•系统缓存所有请求与处理结果•检测到重复请求之后，自动返回之前的处理结果业务服务doX10:3318复合模式2:可靠消息实现•业务活动的主动方，在完成业务处理的同一个本地事务中，记录消息数据•业务处理事务提交后、通过实时消息服务通知业务被动方，实时通知成功后删除消息数据•消息恢复系统定期找到未成功发送的消息，交给实时消息服务补发送约束•被动方的处理结果不影响主动方的处理结果•被动方的消息处理操作是幂等操作成本•可靠消息系统建设成本•消息数据CRUD成本适用范围•对最终一致性时间敏感度较高•降低业务被动方实现成本业务处理服务实时消息服务实时处理网关数据库事务域事务域业务处理服务主动方被动方业务数据消息数据消息恢复系统10:3319可靠消息的另一种实现实现•业务处理服务在业务事务提交前，向实时消息服务请求发送消息，实时消息服务只记录消息数据，而不真正发送•业务处理服务在业务事务提交后，向实时消息服务确认发送。只有在得到确认发送指令后，实时消息服务才真正发送消息•业务处理服务在业务事务回滚后，向实时消息服务取消发送•消息状态确认系统定期找到未确认发送或回滚发送的消息，向业务处理服务询问消息状态，业务处理服务根据消息ID或消息内容确定该消息是否有效成本•一次消息发送需要两次请求•业务处理服务需实现消息状态回查接口优点•消息数据独立存储、独立伸缩•降低业务系统与消息系统间的耦合业务处理服务实时消息服务事务域业务数据消息恢复系统消息数据消息状态确认系统事务域发送消息请求发送确认发送取消发送询问消息状态10:3320服务模式3:TCC操作Try:尝试执行业务•完成所有业务检查(一致性)•预留必须业务资源(准隔离性)Confirm:确认执行业务•真正执行业务•不作任何业务检查•只使用Try阶段预留的业务资源•Confirm操作满足幂等性Cancel:取消执行业务•释放Try阶段预留的业务资源•Cancel操作满足幂等性与2PC协议比较•位于业务服务层而非资源层•没有单独的准备(Prepare)阶段，Try操作兼备资源操作与准备能力•Try操作可以灵活选择业务资源的锁定粒度•较高开发成本业务服务tryXconfirmXcancelX10:3321复合模式3:TCC模式实现•一个完整的业务活动由一个主业务服务与若干从业务服务组成•主业务服务负责发起并完成整个业务活动•从业务服务提供TCC型业务操作•业务活动管理器控制业务活动的一致性，它登记业务活动中的操作，并在业务活动提交时确认所有的TCC型操作的confirm操作，在业务活动取消时调用所有TCC型操作的cancel操作成本•实现TCC操作的成本•业务活动结束时confirm或cancel操作的执行成本•业务活动日志成本适用范围•强隔离性、严格一致性要求的业务活动•适用于执行时间较短的业务主业务服务从业务服务A从业务服务B数据库数据库数据库tryX1.tryX成功业务活动管理器活动日志启动业务活动登记业务操作提交/回滚业务活动confirmXcancelXtryYconfirmYcancelY2.tryY成功3.confirmX成功4.confirmY成功10:3322服务模式4:可补偿操作业务服务doXcompensateXdo:真正执行业务•完成业务处理•业务执行结果外部可见compensate:业务补偿•抵销(或部分抵销)正向业务操作的业务结果•补偿操作满足幂等性约束•补偿在业务上可行•由于业务执行结果未隔离、或者补偿不完整带来的风险与