分布式事务实现概论

一、引言

      分布式事务是伴随着分布式系统架构的诞生而提出来的,传统的单体应用逐渐被拆分成不同的服务独立部署(SOA架构),这样一来,跨库、跨服务的分布式事务就成为必须解决的首要问题。   

                161017_m8oV_2896894.png

二、事务和分布式事务

           161642_O9tN_2896894.png

        相对于传统的单机事务,分布式事务具有高度并发、资源分布和时间跨度大的特点。       

三、本地事务

          161844_Gjpg_2896894.png

      本地事务就好比我们在本地使用的mysql事务,他提供严格的ACID特性支持。比如:

Connection conn = getConnection();
conn.setAutoCommit(false);
// do something
boolean success = doSomething();
if (success) {
  conn.commit();
} else {
  conn.rollback();
}

 

四、全局事务(DTP模型)

           162242_zkrF_2896894.png     

      其中,X/Open DTP(Distributed Transaction Process)是一个分布式事务模型。这个模型主要使用了两段提交(2PC   Two-Phase-Commit)来保证分布式事务的完整性。在这个模型里面,有三个角色:

  • AP: Application,应用程序。也就是业务层。哪些操作属于一个事务,就是AP定义的。
  • TM: Transaction Manager,事务管理器。接收AP的事务请求,对全局事务进行管理,管理事务分支状态,协调RM的处理,通知RM哪些操作属于哪些全局事务以及事务分支等等。这个也是整个事务调度模型的核心部分,一般是作为交易中间件
  • RM:Resource Manager,资源管理器。一般是数据库,也可以是其他的资源管理器,如消息队列(如JMS数据源),文件系统等。

     其中,AP 可以和TM 以及 RM 通信,TM 和 RM 互相之间可以通信,DTP模型里面定义了XA接口,TM 和 RM 通过XA接口进行双向通信,例如:TM通知RM提交事务或者回滚事务,RM把提交结果通知给TM。AP和RM之间则通过RM提供的Native API 进行资源控制,这个没有进行约API和规范,各个厂商自己实现自己的资源控制,比如Oracle自己的数据库驱动程序。

      这三者的关系为:

                                163617_8J69_2896894.png

  • 全局事务:对于一次性操作多个资源管理器的事务,就是全局事务
  • 分支事务:在全局事务中,某一个资源管理器有自己独立的任务,这些任务的集合作为这个资源管理器的分支任务
  • 控制线程:用来表示一个工作线程,主要是关联AP,TM,RM三者的一个线程,也就是事务上下文环境。简单的说,就是需要标识一个全局事务以及分支事务的关系。

五、两阶段提交(Two Phase Commit)

            164044_QXM0_2896894.png

      阶段提交是DTP事务模型的一种实现方式。一个TM控制多个RM,协调资源。两阶段主要指的是:
      第一阶段(准备阶段):事务管理器通知资源管理器准备分支事务,资源管理器告之事务管理器准备结果。
      第二阶段(提交阶段):事务管理器通知资源管理器提交分支事务,资源管理器告之事务管理器结果。

六、跨域的全局事务(DTP模型)

          164337_1mkL_2896894.png

        多个事务域之间通过通信资源管理器CRM进行协调各沟通。

七、Java企业平台中的分布事务实现

                164654_e7Sj_2896894.png

    Java 事务编程接口(JTA:Java Transaction API)和 Java 事务服务 (JTS;Java Transaction Service) 为 J2EE 平台提供了分布式事务服务。分布式事务(Distributed Transaction)包括事务管理器(Transaction Manager)和一个或多个支持 XA 协议的资源管理器 ( Resource Manager )。我们可以将资源管理器看做任意类型的持久化数据存储;事务管理器承担着所有事务参与单元的协调与控制。JTA 事务有效的屏蔽了底层事务资源,使应用可以以透明的方式参入到事务处理中;但是与本地事务相比,XA 协议的系统开销大,在系统开发过程中应慎重考虑是否确实需要分布式事务。若确实需要分布式事务以协调多个事务资源,则应实现和配置所支持 XA 协议的事务资源,如 JMS、JDBC 数据库连接池等。使用 JTA 处理事务的示例如下(注意:connA 和 connB 是来自不同数据库的连接)

public void transferAccount() { 
		
		 UserTransaction userTx = null; 
		 Connection connA = null; 
		 Statement stmtA = null; 
				
		 Connection connB = null; 
		 Statement stmtB = null; 
    
		 try{ 
		       // 获得 Transaction 管理对象
			 userTx = (UserTransaction)getContext().lookup("\
			       java:comp/UserTransaction"); 
			 // 从数据库 A 中取得数据库连接
			 connA = getDataSourceA().getConnection(); 
			
			 // 从数据库 B 中取得数据库连接
			 connB = getDataSourceB().getConnection(); 
      
                        // 启动事务
			 userTx.begin();
			
			 // 将 A 账户中的金额减少 500 
			 stmtA = connA.createStatement(); 
			 stmtA.execute("
            update t_account set amount = amount - 500 where account_id = 'A'");
			
			 // 将 B 账户中的金额增加 500 
			 stmtB = connB.createStatement(); 
			 stmtB.execute("\
             update t_account set amount = amount + 500 where account_id = 'B'");
			
			 // 提交事务
			 userTx.commit();
			 // 事务提交:转账的两步操作同时成功(数据库 A 和数据库 B 中的数据被同时更新)
		 } catch(SQLException sqle){ 
			
			 try{ 
		  	       // 发生异常,回滚在本事务中的操纵
                  userTx.rollback();
				 // 事务回滚:转账的两步操作完全撤销 
				 //( 数据库 A 和数据库 B 中的数据更新被同时撤销)
				
				 stmt.close(); 
                 conn.close(); 
				 ... 
			 }catch(Exception ignore){ 
				
			 } 
			 sqle.printStackTrace(); 
			
		 } catch(Exception ne){ 
			 e.printStackTrace(); 
		 } 
	 }

      对jta更深入研究的可以看这篇文章: https://www.ibm.com/developerworks/cn/java/j-lo-jta/

八、CAP定理

            165402_wZ8T_2896894.png

九、BASE理论、酸碱平衡

                165500_gRqZ_2896894.png

         172615_8wMy_2896894.png

            172654_AFiK_2896894.png

十、服务模式1: 可查询操作

            165617_IxLV_2896894.png

     这里的服务模式是指:针对单个服务,该服务应该具有的特性或者实现的接口。

     这里是指,该服务应该实现查询接口,包括单笔查询和批量查询。 

十一、复合模式1: 定期校对(最大努力通知型)

            165709_Ui1M_2896894.png

     复合模式是指:同时针对多个服务的协同工作。

     方案特点

  •  业务活动的主动方在完成业务处理后,向业务活动被动方发送通知消息(允许消息丢失)
  • 主动方可以设置时间阶梯型通知规则,在通知失败后按规则重复通知,直到通知N次后不再通知 • 主动方提供校对查询接口给被动方按需校对查询,用于恢复丢失的业务消息

     行业应用案例

  • 银行通知、商户通知等(各大交易业务平台间的商户通知:多次通知、查询校对、对账文件)

十二、保证消息在事务提交后才发送

            170500_P4Cr_2896894.png

十三、服务模式2: 幂等操作

                170612_yw1f_2896894.png

      由于服务可能会被重试多次,因此一定要保证服务具有幂等特性。

十四、复合模式2: 可靠消息(异步确保型)

                170657_SZXe_2896894.png

     用到的服务模式

  • 可查询操作、幂等操作

    方案特点

  • 兼容所有实现JMS标准的MQ中间件
  • 确保业务数据可靠的前提下,实现业务数据的最终一致(理想状态下基本是准实时一致)

    行业应用案例

  • 支付宝、eBay(BASE)、去哪儿......

十五、可靠消息的另一种实现

            170844_kDnB_2896894.png

    这种实现方式就类似RocketMQ中的事务消息模型。

十六、服务模式3: TCC操作

                171016_qfEN_2896894.png

       要求服务必须实现TCC操作的三个接口。

十七、复合模式3: TCC模式

                171101_Dy3Q_2896894.png

      注:TCC本身也属于补偿模式的一种。

      用到的服务模式

  • TCC操作、幂等操作、可补偿操作、可查询操作

      方案特点

  • 不与具体的服务框架耦合(在RPC架构中通用)
  • 位于业务服务层,而非资源层

  • 可以灵活选择业务资源的锁定粒度

  • TCC里对每个服务资源操作的是本地事务,数据被lock的时间短,可扩展性好(可以说是为独立部署的 SOA服务而设计的)

     行业应用案例

  • 支付宝XTS(蚂蚁金融云的分布式事务服务DTS)

十八、服务模式4: 可补偿操作   

                171154_DsYx_2896894.png

十九、复合模式4: 补偿模式

                    171222_djxT_2896894.png

二十、商业流程也是事务

                    171336_dAWU_2896894.png

二十一、又一山寨

                171535_zCoO_2896894.png

二十二、概念架构

            171624_iqoN_2896894.png

二十三、业务活动模型

            171730_g8ET_2896894.png

二十四、关键组件

            171814_rI8R_2896894.png

二十五、业务活动管理器(BAM)

            171855_D8uM_2896894.png

二十六、提交过程

            171937_auCq_2896894.png

二十七、回滚过程

            172038_4Sat_2896894.png

二十八、恢复过程

            172105_MMCg_2896894.png

二十九、对基础设施的要求

            172146_eJ4Q_2896894.png

 

 

转载于:https://my.oschina.net/fileoptions/blog/886967

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值