SlideShare uma empresa Scribd logo
1 de 35
Baixar para ler offline
大规模SOA系统中的分布事务处理
           程立
    支付宝产品技术与用户体验部
        2008年12月
提要
        应用                 数据库
                                       • 从单应用系统的事务
                                       • 到大规模SOA系统中
                                         的事务
                    客户的系统
                                       • 内容提要
                                  遗
    开                             留        – 山穷水尽(背景与历史)
    放                             系
    服                             统        – 柳暗花明(原则与模式)
    务                             集        – 又一山寨(框架与设施)
         流           业      领     成
         程           务      域
         服           服      服     合
   门     务           务      务     作
   户                              伙
   服                              伴
   务                              集
             数 数     数 数    数 数   成
             据 据     据 据    据 据

                   合作伙伴的系统

10:33                                                 2
山穷水尽
         Googling
         •    “transaction processing”
             约有1,940,000项符合的查询结果
         •    “distributed transaction”
             约有260,000项符合的查询结果
         •    “distributed transaction”+
              practice
             约有24,700项符合的查询结果
         •    “distributed transaction”+
              “success story”
             约有265项符合的查询结果
         •    “distributed transaction”
              + sucks
          约有1,370项符合的结果
         • “distributed transaction” +
           hope
          约有17,500项符合的结果 ☺

10:33                                    3
事务
                                     事务:
                    事务3
                                         由一组操作构成的可靠、
                   事务2                   独立的工作单元
              事务1                    ACID:
                                     •   Atomicity(原子性)
                                     •   Consistency(一致性)
  C           C1          C4             Isolation(隔离性)
资                                    •
源                                    •   Durability(持久性)
位
置 B                 B3
                                     难点:
                                     •   高度并发
 A       A1                    A5
                                     •   资源分布
                                     •   大时间跨度
         1    2     3  4       5
                  操作时间

 10:33                                                      4
本地事务
                                  本地事务
                                    事务由资源管理器(如
             开始会话
                                    DBMS)本地管理
         应                        优点
         用   开始事务
         应                        • 支持严格的ACID属性
        /




         用    操作1                 • 可靠
                            资
         服                  源
         务                        • 高效
                            管
               …
    AP




         器
                       RM   理     • 状态可以只在资源管理器
         应                  器       中维护
        /




         用    操作n
         框                        • 应用编程模型简单(在框
         架             日志           架或平台的支持)
             提交/回滚事务
                                  局限
                        锁
             完成会话                 • 不具备分布事务处理能力
                                  • 隔离的最小单位由资源管
                                    理器决定,如数据库中的
                                    一条记录
10:33                                         5
全局事务(DTP模型)
                                           全局事务
             应用/应用框架/应用服务器
                   AP
                                             事务由全局事务管理
                                             器全局管理
1.
        2.

             4.

        注    注




                            3.



                                    5.
 开                           操       操     事务管理器
                  6.
        册    册    提          作       作
 始      资    资    交
 全      源    源    事                          管理全局事务状态与

                            1..n



                                    1..n
 局
 事
                  务                          参与的资源,协同资
        1

             2




 务                                           源的一致提交/回滚
         事务                 资源      资源     TX协议
        管理器                管理器     管理器
         TM                                  应用或应用服务器与
                           RM1     RM2
                  7. 准备
                                             事务管理器的接口
                  8. 准备                    XA协议
                  9. 提交                      全局事务管理器与资
                  10. 提交                     源管理器的接口

10:33                                                6
两阶段提交(Two Phase Commit)
                                                 准备操作与ACID
                          事务管理器
                            TM                   • A: 准备后,仍可提交与回滚
                                                 • C: 准备时,一致性检查必须
1.



             3.




                             2.



                                       4.
准                提            准        提
                                                   OK
     OK




                                  OK



                                            OK
                     OK

备                交            备        交
                                                 • I: 准备后,事务结果仍然只
                                                   在事务内可见
       资源管理器                       资源管理器
        RM1                         RM2          • D: 准备后,事务结果已经持
                                                   久
                                                 局限
                          事务管理器
                            TM                   • 协议成本 (准备操作是一定
                                                   必须的吗)
                                       4.
1.




                             2.




准                             准        回
             3.




             回
                                  NO
                     OK




                                            OK
     OK




备            滚                备        滚         • 准备阶段的持久成本
                                                 • 全局事务状态的持久成本
       资源管理器                       资源管理器         • 潜在故障点多带来的脆弱性
        RM1                         RM2          • 准备后,提交前的故障引发
                                                   一系列隔离与恢复难题
     10:33                                                     7
跨域的全局事务(DTP模型)
                                    问题
        应用/应用框架/应用服务器
              AP                    • 事务上下文如何跨域传递?
                TX         TxRPC等   • 多事务管理器如何协同?
                                    • 异构事务域间的标准是什么?
 资源
  资源     XA    事务     XA+ 通信资源
                          通信资源
管理器           管理器        管理器
                                    通信资源管理器
 管理器                     管理器
RM1
  RM           TM        CRM
                          CRM         管理事务域间或事务域内的
                                      通信,允许全局事务信息跨
              主事务域                    域传递
              分支事务域                 XA+协议
        应用/应用框架/应用服务器                 是XA的超集,增加指令使事
              AP                      务管理器间可以相互协同
                TX         TxRPC等   局限
 资源            事务                   • 更高协议成本
  资源     XA           XA+ 通信资源
                          通信资源
管理器
 管理器          管理器        管理器
                         管理器        • 脆弱,故障点多
RM1
  RM           TM        CRM
                          CRM       • 故障影响大,恢复困难
                                    • 复杂,更多架构与平台约束
10:33                                            8
Java企业平台中的分布事务实现
                JTA
                   面向应用、应用服务器与资源
                   管理器的高层事务接口
                JTS
                   JTA事务管理器的实现标准,向
                   上支持JTA,向下通过CORBA
                   OTS实现跨事务域的互操作性
                EJB
                   基于组件的应用编程模型,通
                   过声明式事务管理进一步简化
                   事务应用的编程
                优点
                • 简单一致的编程模型
                • 跨域分布处理的ACID保证
                局限
                • DTP模型本身的局限
                • 缺少充分公开的大规模、高可
                   用、密集事务应用的成功案例
10:33                           9
其它资源
          WS-Transaction标准
             OASIS组织通过的Web Service
             事务标准,包含WS-
             Cordination、WS-
             AtomicTransaction、WS-
             BusinessActivity
          JbossTransactions系统
             开源的JTA、JTS、WS-
             Transaction标准的实现
          Paxos算法
             分布式系统中就某个提议达成
             一致决议的算法族




10:33                         10
柳暗花明
           原则
           •   真正重要的是满足业务需求,
               而不是追求抽象、绝对的系统
               特性
           •   帽子戏法:两只手最多能拿几
               顶帽子?
           •   酸碱平衡(ACID-BASE
               Balance)
           模式
           •   服务模式
                1. 可查询操作
                2. 幂等操作
                3. TCC操作
                4. 可补偿操作
           •   复合模式
                1. 定期校对
                2. 可靠消息
                3. TCC
                4. 补偿
10:33                      11
帽子戏法
          CAP定理
          对于共享数据系统,只能同时拥有
          以下三项中的两个:
          •   Consistency(一致性): 所有
              用户看到一致的数据
          •   Availability(可用性): 总能找
              到一个可用的数据复本
          •   Tolerance to Network
              Partition(分区容忍性): 即使
              在系统被分区的情况下,仍
              然满足上述两点




10:33                           12
酸碱平衡
          BASE
          •   BA(Basic Availability)
              基本可用性
          •   S(Soft state)
              柔性状态
          •   E(Eventuall consistency)
              最终一致性




10:33                              13
eBay的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 
  Randy Shoup,eBay的杰出架构师     according to the consistency 
                             demands of the particular 
                             use case.
10:33                                                  14
服务模式1: 可查询操作
                                服务操作的可标识性
                                • 服务操作具有全局唯一标识
                                    – 可以使用业务单据号
                                    – 或者使用系统分配的操作流水号
                                    – 或者使用操作资源的唯一标识+
   doX   queryX   batchQueryX         操作类型的组合
                                •   操作有唯一的、确定的时间(约定
                                    以谁的时间为准)

                                单笔查询
                                • 使用全局唯一的服务操作标识,
                                  查询操作执行结果
         业务服务
                                • 小心“处理中”状态

                                批量查询
                                  使用时间区段与(或)一组服务操
                                  作的标识,查询一批操作执行结
                                  果
10:33                                            15
复合模式1: 定期校对
                                  实现
                  事务域             •   业务活动的主动方,在完成业务处理
                                      之后,向业务活动的被动方发送消息
             业务处理服务                   。允许消息丢失。
                        数据库
主                                 •   业务活动的被动方根据定时策略,向
动                                     业务活动主动方查询,恢复丢失的业
方                                     务消息。
                                  约束
             实时消息服务   业务查询/下载服务
                                  •   被动方的处理结果不影响主动方的处
                                      理结果
                                  成本
                                  •   业务查询与校对系统的建设成本
             实时处理网关     定期校对系统
 被                                适用范围
 动                                •   对业务最终一致性的时间敏感度低
 方                                •   跨企业的业务活动
                 业务处理服务
                          事
                          务
                          域
                  数据库

     10:33                                         16
保证消息在事务提交后才发送
                                                      要求
                    事务管理器                                 消息发送必须严格在事务提交后
                                                          方可进行
                        4.1 调用事务同步器
                                                      一种实现方案
1.

            4.




开               提
始               交                     4.1.1 发消息
事               事      事务同步器                          •   使用拦截器拦截发送消息请求
务               务                                 消
                                      3.1                 拦截器检测到当前存在活动事务
                                            3.2
                                                  息   •
                                       创     注    服       ,就创建一个事务同步器
                                       建     册
                                       事     事    务   •   并向事务管理器注册事务同步器
                     2. 操作    数        务     务        •   业务处理事务完成后,事务管理
                              据        同     同
            业                          步     步            器会调用事务同步器
                              库
            务                          器     器        •   事务同步器判断当前事务状态为
            处
            理                                             已提交,才真正发送消息
            服                     拦
                     3. 发消息       截
            务                     器



    10:33                                                             17
服务模式2: 幂等操作
                    幂等性(Idempotenty)
                      f(f(x)) = f(x)

                    幂等操作
         doX          重复调用多次产生的业务结果与
                      调用一次产生的业务结果相同

                    实现方式一
                      通过业务操作本身实现幂等性

                    实现方式二
        业务服务        • 系统缓存所有请求与处理结果
                    • 检测到重复请求之后,自动返回
                      之前的处理结果




10:33                                  18
复合模式2: 可靠消息
                                     实现
                      事务域            •   业务活动的主动方,在完成业务处理的
                             业务数据        同一个本地事务中,记录消息数据
             业务处理服务                  •   业务处理事务提交后、通过实时消息服
主                            消息数据        务通知业务被动方,实时通知成功后删
动                                        除消息数据
方
                                     •   消息恢复系统定期找到未成功发送的消
                                         息,交给实时消息服务补发送
             实时消息服务         消息恢复系统
                                     约束
                                     •   被动方的处理结果不影响主动方的处理
                                         结果
                                     •   被动方的消息处理操作是幂等操作
                  实时处理网关
 被                                   成本
 动                                   •   可靠消息系统建设成本
 方                                   •   消息数据CRUD成本
                  业务处理服务
                                事    适用范围
                                务    •   对最终一致性时间敏感度较高
                                域    •   降低业务被动方实现成本
                      数据库

     10:33                                               19
可靠消息的另一种实现
                                实现
                 事务域            •   业务处理服务在业务事务提交前,向实
                                    时消息服务请求发送消息,实时消息服
        业务处理服务          业务数据        务只记录消息数据,而不真正发送
                                •   业务处理服务在业务事务提交后,向实
                                    时消息服务确认发送。只有在得到确认
                                    发送指令后,实时消息服务才真正发送
    请    确   取
    求    认   消    询问消息状态            消息
    发    发   发                  •   业务处理服务在业务事务回滚后,向实
    送    送   送     消息状态确认系统         时消息服务取消发送
                                •   消息状态确认系统定期找到未确认发送
                                    或回滚发送的消息,向业务处理服务询
                 事务域
                                    问消息状态,业务处理服务根据消息ID
                                    或消息内容确定该消息是否有效
        实时消息服务          消息数据
                                成本
                                •   一次消息发送需要两次请求
                                •   业务处理服务需实现消息状态回查接口
发送消息                            优点
                       消息恢复系统
                                •   消息数据独立存储、独立伸缩
                                •   降低业务系统与消息系统间的耦合
10:33                                              20
服务模式3: TCC操作
                              Try: 尝试执行业务
                              • 完成所有业务检查(一致性)
                              • 预留必须业务资源(准隔离性)
                              Confirm:确认执行业务
                              • 真正执行业务
                              • 不作任何业务检查
  tryX   confirmX   cancelX
                              • 只使用Try阶段预留的业务资源
                              • Confirm操作满足幂等性
                              Cancel: 取消执行业务
                              • 释放Try阶段预留的业务资源
                              • Cancel操作满足幂等性
         业务服务                 与2PC协议比较
                              • 位于业务服务层而非资源层
                              • 没有单独的准备(Prepare)阶段,Try操作
                                 兼备资源操作与准备能力
                              • Try操作可以灵活选择业务资源的锁定粒度
                              • 较高开发成本
10:33                                                21
复合模式3: TCC模式
           1. tryX成功               从
                                           实现
                         tryX                  一个完整的业务活动由一个主业务服务与若
                                   业       •
                                   务           干从业务服务组成
                       confirmX    服
                                   务       •   主业务服务负责发起并完成整个业务活动
                       cancelX
                                           •   从业务服务提供TCC型业务操作




                                   A
  主业务服务                                    •   业务活动管理器控制业务活动的一致性,它
                                               登记业务活动中的操作,并在业务活动提交
                            数据库                时确认所有的TCC型操作的confirm操作,在
   数据库     2. tryY成功
                                               业务活动取消时调用所有TCC型操作的
 启动业务活动                                        cancel操作
          3. confirmX成功
 登记业务操作                                    成本
提交/回滚业务活动
                                           •   实现TCC操作的成本
  业务活动                                 从   •   业务活动结束时confirm或cancel操作的执
                          tryY
   管理器                                 业       行成本
                                       务
                        confirmY       服   •   业务活动日志成本
  活动日志 4. confirmY成功                   务   适用范围
                         cancelY           •   强隔离性、严格一致性要求的业务活动
                                   B




                                           •   适用于执行时间较短的业务
                                数据库

   10:33                                                              22
服务模式4: 可补偿操作
                        do: 真正执行业务
                        •   完成业务处理
                        •   业务执行结果外部可见
                        compensate:业务补偿
                        •   抵销(或部分抵销)正向业务操作的业务
doX       compensateX
                            结果
                        •   补偿操作满足幂等性

                        约束
                        • 补偿在业务上可行
                        • 由于业务执行结果未隔离、或者补偿不
        业务服务              完整带来的风险与成本可控




10:33                                       23
复合模式4: 补偿模式
                                   实现
                      业务           •   一个完整的业务活动由一个主业务服务与若
                      操作               干从业务服务组成,一般由主业务服务发起
          1. 业务操作成功
                           从业务服务       并结束整个业务活动
                             A     •   从业务服务提供的业务操作提供补偿操作,
                      补偿
 主业务服务                操作               补偿操作可以抵销(或部分抵销)正向业务操
                                       作的业务结果
                            数据库    •   业务活动管理器控制业务活动的一致性,它
  数据库        2. 业务操作失败
                                       登记业务活动中的操作,并在业务活动取消
                                       时调用补偿操作
 启动业务活动
 登记业务操作           3. 执行业务补偿        成本
提交/回滚业务活动
                                   •   从业务服务实现补偿操作的成本
 业务活动                              •   由于无法完全补偿带来的业务成本
  管理器                              •   业务活动回滚时,需要额外调用补偿操作
                      业务
                      操作           适用范围
  活动日志                     从业务服务
                             B     •   弱隔离性、弱一致性要求的业务活动
                                   •   特别适用于执行时间较长的业务,如工作流

                            数据库

  10:33                                                  24
商业流程也是事务
                               • 事务管理有时是
                                 商业流程与用户
                                 体验的一部分
  发货         收款      收货   付款   • 并非所有问题都
                                 可以或应该由系
                  交易中介
                                 统来解决


        物流                银行




10:33                                  25
又一山寨
           框架与设施建设目标
           •   一致的架构风格
           •   简单的编程模型
           •   万无一失
           •   没商量: 高可用与可伸缩
           •   轻量,可扩展
           •   尽力优化性能
           •   利用现有基础设施




10:33                     26
概念架构
                                          业   业务活动
             主                            务       一个完整的业务处理过程,处
             控        流程服务                活       理中包含多个服务操作,这些
             动                DB          动       服务操作构成了一棵调用树
             作                                原子动作
                                              •   对应于一次服务操作调用。每
原                                                 个原子动作作为业务活动的基
子           业务服务              业务服务                本单元,通过本地事务满足
动                      DB            DB           ACID。
作                                             •   原子动作有不同的调用类型,
                                                  如请求-应答、异步消息、异
                                                  步可靠消息等。
    领域服务                领域服务                  •   原子动作对应的服务操作也有
                 DB           DB                  各种类型,如TCC型、可补偿
                                                  型、幂等型等
                                              主控动作
                      集成服务         集成服务       •   主控动作是整个业务活动的发
                         DB           DB          起者,也是服务操作调用树的
                                                  根
                                              •   可以合理地让主控动作本身的
                                                  提交与回滚决定整个业务活动
    10:33                                         的提交与回滚      27
业务活动模型
                                                     BusinessActivity
                                BusinessActivityId
                                                       业务活动,其中包括的任意多
                                   业务活动Id
   BusinessActivity                                    个原子动作需要满足事务要求
      (业务活动)                 +业务领域: String             (ACID/BASE)
                             +业务操作: String
+状态: Enum                                            AtomicAction
                             +实体Id: String
+时间: Date                                               原子动作,是一个业务活动中
                                                        不可分的业务处理单元。一个
                                                        原子动作的执行满足ACID。
                                                        其背后,是通过对某个服务操
                                                        作的一次调用实现的
                                                     ServiceOperation
                 AtomicAction(原子动作))
                                                        服务操作,是某个业务领域功
                                                        能的原子实现。服务操作有类
+调用类型: Enum(请求-应答/异步消息/可靠异步消息)                          型标识,表明它是幂等型、
                                                        TCC型还是补偿型操作
                                                     BusinessActivityId
                           ServiceOperation(服务操作)       业务活动Id,是业务活动的唯
                                                        一标识。业务活动Id由三个部
                         +类型: Enum(TCC/补偿/幂等)           分组成,分别代表业务活动所
                         +其它属性                          属的业务领域、对应的业务操
                                                        作与被操作的实体对象的Id
  10:33                                                                 28
关键组件
                                      业务活动管理器
                     服务容器              管理业务活动上下文,操作业
             管                         务活动日志,协同各个参与者
                 业      服务端拦截器
             理
                 务                     完成业务活动的提交与回滚操
             器   活                     作
                 动               服务   客户端拦截器
                            服务   本地    拦截服务调用,在消息中附加
                 业               数据    业务活动上下文,以实现业务
            恢
业           复    务                     活动上下文跨服务传递。在业
                 活      客户端拦截器
务           器    动                     务活动中添加原子动作
活                                     服务端拦截器
动
日                                      拦截服务请求,从消息中析取
                     服务容器              业务活动上下文,并启动本地
志            管
             理   业      服务端拦截器         业务活动
             器   务
                 活                    业务活动日志
                 动               服务    记录业务活动的状态,记录参
                            服务   本地    与业务活动的原子动作
                 业               数据   业务活动恢复器
            恢
                 务
            复
                 活                     记录业务活动的状态,记录参
            器           客户端拦截器
                 动                     与业务活动的原子动作
    10:33                                         29
业务活动管理器(BAM)
                                                           UserBusinessActivity接口
                                                             面向应用的接口,允许开发者通过
                                   UserBusinessActivity      本接口启动业务活动,指定业务活
                                  (业务活动用户控制接口)
                                                             动Id。启动业务活动的业务服务成
                              +start(BusinessActivityId)     为本次业务活动的主控业务服务
BusinessActivityManagerImpl




                                                           BusinessActivityManager接口
     业
                                                              面向框架的接口,由框架实现者提
    (




     务
     活                                                        交或回滚业务活动,以及将原子活
     动                                                        动作为参与者添加到业务活动的上
     管                                                        下文。业务活动的提交或回滚由主
     理                                                        控业务服务本地事务的提交或回滚
     器
     实                                                        决定
                                BusinessActivityManager
     现                           (业务活动框架控制接口)              BusinessActivityManagerImpl类
                                                              上述接口的实现
                      )




                              +commit()
                              +rollback()
                              +enlistAction()
                              +delistAction()




10:33                                                                                30
提交过程
                                      提交过程在主控动作的本地事务
             读取所有原子动作记录
                                      提交后,由业务活动管理器执行

             处理下一条原子动作记录
                                      实现策略
                                      •   可以通过注册事务同步器监
                   判断原子动
                    作类型                   听主控动作的本地事务提交
TCC型         补偿型       非可靠消息   可靠消息       事件
 执行                             确认    •   提交过程可能时间较长,具
             空操作      发送消息
确认操作                           发送消息       体实现时,尽量让这个过程
                                          异步化、并行化
                                      •   提交过程中可能发生故障造
               delist原子动作
                                          成处理中断,别担心,由恢
         是                                复过程进行自动恢复
               还有未处理的原
                 子动作?
                       否

              清除业务活动记录
 10:33                                               31
回滚过程
                                  回滚过程在主控动作的本地事务
         读取所有原子动作记录
                                  回滚后,由业务活动管理器执行

         处理下一条原子动作记录
                                  实现策略
                                  •   可以通过注册事务同步器监
               判断原子动
                作类型                   听主控动作的本地事务回滚
TCC型     补偿型       非可靠消息   可靠消息       事件
 执行       执行                取消    •   回滚过程可能时间较长,具
                  空操作
取消操作     补偿操作              发送消息       体实现时,尽量让这个过程
                                      异步化、并行化
                                  •   回滚过程中可能发生故障造
           delist原子动作
                                      成处理中断,别担心,由恢
     是                                复过程进行自动恢复
           还有未处理的原
             子动作?
                   否

          清除业务活动记录
 10:33                                           32
恢复过程
                                     恢复过程定期执行,恢复创建时
             读取待恢复业务活动记录
                                     间早于一定时间内的业务活动记
                                     录(如每分钟恢复创建时间在一
                                     分钟之前的业务活动记录)
             处理下一条业务活动记录

        是
                进行中的
                                     实现策略
               业务活动?                 •   必须万无一失地判断业务活
                   否                     动是否在进行中
        提交                 回滚        •   必须万无一失地判断业务活
               提交或回滚?
                                         动应该提交或回滚
                                         – 例: 当业务活动日志与主控业务
                                           服务处于同一数据库时: 可以采
   执行提交过程               执行回滚过程             用记录锁判断
                                         – 例: 当业务活动日志与主控业务
                                           服务处于不同数据库时: 向业务
    是                           否          服务查询活动状态
               还有待恢复的业
                务活动记录                •   监控

10:33                                                   33
对基础设施的要求
           服务框架
            将业务活动管理切面与业务服务功
            能透明粘合起来,具备事务上下文传
            输能力
           消息系统
            支持各种消息质量等级,具备海量
            吞吐能力,具备灵活优先调度能力
           数据存储
            消息数据存储: 成本灵活、高性能、
            可伸缩的消息数据存储
            业务活动日志管理: 高可靠、高性能
            、可伸缩
           分布任务调度
            可靠地调度系统中的各种任务,如
            业务活动恢复任务、消息恢复任务、
            定期校对任务等
           服务注册中心
            提供服务元数据集中注册、查询与
            管理能力,支持事务相关属性的描述
10:33                      34
本文档可以在http://www.dbanotes.net上下载




10:33                                 35

Mais conteúdo relacionado

Mais procurados (20)

Fotorealismo
FotorealismoFotorealismo
Fotorealismo
 
O CONSTRUTIVISMO RUSSO E O ABSTRACIONISMO
O CONSTRUTIVISMO RUSSO E O ABSTRACIONISMOO CONSTRUTIVISMO RUSSO E O ABSTRACIONISMO
O CONSTRUTIVISMO RUSSO E O ABSTRACIONISMO
 
Pablo Picasso- Vida e Obra
Pablo Picasso- Vida e ObraPablo Picasso- Vida e Obra
Pablo Picasso- Vida e Obra
 
Pontilhismo
PontilhismoPontilhismo
Pontilhismo
 
Abstracionismo
AbstracionismoAbstracionismo
Abstracionismo
 
Expressionismo jackson pollock
Expressionismo jackson pollockExpressionismo jackson pollock
Expressionismo jackson pollock
 
Op arte
Op arteOp arte
Op arte
 
Teoria das cores (Segunda Série)
Teoria das cores (Segunda Série)Teoria das cores (Segunda Série)
Teoria das cores (Segunda Série)
 
Arte no Séc. XX
 Arte no Séc. XX Arte no Séc. XX
Arte no Séc. XX
 
|ALMADA|
|ALMADA||ALMADA|
|ALMADA|
 
Sudha Devi IAS
Sudha Devi IASSudha Devi IAS
Sudha Devi IAS
 
Dadaísmo pesquisa
Dadaísmo   pesquisaDadaísmo   pesquisa
Dadaísmo pesquisa
 
EXPRESSIONISMO
EXPRESSIONISMOEXPRESSIONISMO
EXPRESSIONISMO
 
Sebastião salgado
Sebastião salgadoSebastião salgado
Sebastião salgado
 
Apresentação Interdisciplinar - Dadaísmo
Apresentação Interdisciplinar - DadaísmoApresentação Interdisciplinar - Dadaísmo
Apresentação Interdisciplinar - Dadaísmo
 
O cubismo
O cubismoO cubismo
O cubismo
 
Arte conceitual
Arte conceitualArte conceitual
Arte conceitual
 
Vanguardas Europeias - Dadaísmo
Vanguardas Europeias - Dadaísmo  Vanguardas Europeias - Dadaísmo
Vanguardas Europeias - Dadaísmo
 
Dadaismo
DadaismoDadaismo
Dadaismo
 
Arte no brasil nos anos 60
Arte no brasil nos anos 60Arte no brasil nos anos 60
Arte no brasil nos anos 60
 

Mais de Dahui Feng

垂直互联网站点的技术改造
垂直互联网站点的技术改造垂直互联网站点的技术改造
垂直互联网站点的技术改造Dahui Feng
 
The Rules of Scalable database
The Rules of Scalable databaseThe Rules of Scalable database
The Rules of Scalable databaseDahui Feng
 
垂直社区的产品改造
垂直社区的产品改造垂直社区的产品改造
垂直社区的产品改造Dahui Feng
 
Oracle Security 101
Oracle Security 101Oracle Security 101
Oracle Security 101Dahui Feng
 
产品设计与用户体验(据说是马化腾用来做培训的PPT)
产品设计与用户体验(据说是马化腾用来做培训的PPT)产品设计与用户体验(据说是马化腾用来做培训的PPT)
产品设计与用户体验(据说是马化腾用来做培训的PPT)Dahui Feng
 
丁香园用药助手产品经验 「极客公园创新大会」版
丁香园用药助手产品经验 「极客公园创新大会」版丁香园用药助手产品经验 「极客公园创新大会」版
丁香园用药助手产品经验 「极客公园创新大会」版Dahui Feng
 
Yupoo! (花瓣网/又拍云) 架构中的消息与任务系统
Yupoo! (花瓣网/又拍云) 架构中的消息与任务系统Yupoo! (花瓣网/又拍云) 架构中的消息与任务系统
Yupoo! (花瓣网/又拍云) 架构中的消息与任务系统Dahui Feng
 
据说是新浪内部对腾讯公司的深度解析
据说是新浪内部对腾讯公司的深度解析据说是新浪内部对腾讯公司的深度解析
据说是新浪内部对腾讯公司的深度解析Dahui Feng
 
深入浅出复合事件处理(CEP)
深入浅出复合事件处理(CEP)深入浅出复合事件处理(CEP)
深入浅出复合事件处理(CEP)Dahui Feng
 
Linux必备知识与Unix基础文化
Linux必备知识与Unix基础文化Linux必备知识与Unix基础文化
Linux必备知识与Unix基础文化Dahui Feng
 
Database And User Experience for Web Apps
Database And User Experience for Web AppsDatabase And User Experience for Web Apps
Database And User Experience for Web AppsDahui Feng
 
Wind Computing
Wind ComputingWind Computing
Wind ComputingDahui Feng
 
尼古丁加咖啡因,不瞌睡的简报設計模式 (Caffeine+Nicotine)
尼古丁加咖啡因,不瞌睡的简报設計模式 (Caffeine+Nicotine)尼古丁加咖啡因,不瞌睡的简报設計模式 (Caffeine+Nicotine)
尼古丁加咖啡因,不瞌睡的简报設計模式 (Caffeine+Nicotine)Dahui Feng
 
面向生产环境的SOA系统设计 by 程立
面向生产环境的SOA系统设计 by 程立面向生产环境的SOA系统设计 by 程立
面向生产环境的SOA系统设计 by 程立Dahui Feng
 
手机之家新系统介绍及架构分享
手机之家新系统介绍及架构分享手机之家新系统介绍及架构分享
手机之家新系统介绍及架构分享Dahui Feng
 
可扩展的 MySQL 数据库设计
可扩展的 MySQL 数据库设计可扩展的 MySQL 数据库设计
可扩展的 MySQL 数据库设计Dahui Feng
 
可扩展网站架构(for 网志年会)
可扩展网站架构(for 网志年会)可扩展网站架构(for 网志年会)
可扩展网站架构(for 网志年会)Dahui Feng
 

Mais de Dahui Feng (17)

垂直互联网站点的技术改造
垂直互联网站点的技术改造垂直互联网站点的技术改造
垂直互联网站点的技术改造
 
The Rules of Scalable database
The Rules of Scalable databaseThe Rules of Scalable database
The Rules of Scalable database
 
垂直社区的产品改造
垂直社区的产品改造垂直社区的产品改造
垂直社区的产品改造
 
Oracle Security 101
Oracle Security 101Oracle Security 101
Oracle Security 101
 
产品设计与用户体验(据说是马化腾用来做培训的PPT)
产品设计与用户体验(据说是马化腾用来做培训的PPT)产品设计与用户体验(据说是马化腾用来做培训的PPT)
产品设计与用户体验(据说是马化腾用来做培训的PPT)
 
丁香园用药助手产品经验 「极客公园创新大会」版
丁香园用药助手产品经验 「极客公园创新大会」版丁香园用药助手产品经验 「极客公园创新大会」版
丁香园用药助手产品经验 「极客公园创新大会」版
 
Yupoo! (花瓣网/又拍云) 架构中的消息与任务系统
Yupoo! (花瓣网/又拍云) 架构中的消息与任务系统Yupoo! (花瓣网/又拍云) 架构中的消息与任务系统
Yupoo! (花瓣网/又拍云) 架构中的消息与任务系统
 
据说是新浪内部对腾讯公司的深度解析
据说是新浪内部对腾讯公司的深度解析据说是新浪内部对腾讯公司的深度解析
据说是新浪内部对腾讯公司的深度解析
 
深入浅出复合事件处理(CEP)
深入浅出复合事件处理(CEP)深入浅出复合事件处理(CEP)
深入浅出复合事件处理(CEP)
 
Linux必备知识与Unix基础文化
Linux必备知识与Unix基础文化Linux必备知识与Unix基础文化
Linux必备知识与Unix基础文化
 
Database And User Experience for Web Apps
Database And User Experience for Web AppsDatabase And User Experience for Web Apps
Database And User Experience for Web Apps
 
Wind Computing
Wind ComputingWind Computing
Wind Computing
 
尼古丁加咖啡因,不瞌睡的简报設計模式 (Caffeine+Nicotine)
尼古丁加咖啡因,不瞌睡的简报設計模式 (Caffeine+Nicotine)尼古丁加咖啡因,不瞌睡的简报設計模式 (Caffeine+Nicotine)
尼古丁加咖啡因,不瞌睡的简报設計模式 (Caffeine+Nicotine)
 
面向生产环境的SOA系统设计 by 程立
面向生产环境的SOA系统设计 by 程立面向生产环境的SOA系统设计 by 程立
面向生产环境的SOA系统设计 by 程立
 
手机之家新系统介绍及架构分享
手机之家新系统介绍及架构分享手机之家新系统介绍及架构分享
手机之家新系统介绍及架构分享
 
可扩展的 MySQL 数据库设计
可扩展的 MySQL 数据库设计可扩展的 MySQL 数据库设计
可扩展的 MySQL 数据库设计
 
可扩展网站架构(for 网志年会)
可扩展网站架构(for 网志年会)可扩展网站架构(for 网志年会)
可扩展网站架构(for 网志年会)
 

大规模SOA系统中的分布事务处理 (DTP By Alipay Cheng Li)

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