分布式事务解决方案(一)


一、什么是Java事务

通俗的理解,事务是一组原子操作单元,从数据库角度说,就是一组SQL指令,要么全部执行成功,若因为某个原因其中一条指令执行有错误,则撤销先前执行过的所有指令。更简答的说就是:要么全部执行成功,要么撤销不执行。

事务必须服从ISO/IEC所制定的ACID原则。

· 原子性(atomicity)

· 一致性(consistency)

· 隔离性(isolation)

· 持久性(durability)

原子性表示事务执行过程中的任何失败都将导致事务所做的任何修改失效。

一致性表示当事务执行失败时,所有被该事务影响的数据都应该恢复到事务执行前的状态。

隔离性表示在事务执行过程中对数据的修改,在事务提交之前对其他事务不可见。

持久性表示已提交的数据在事务执行失败时,数据的状态都应该正确。

既然事务的概念从数据库而来,那Java事务是什么?它们之间有什么联系?

实际上,一个Java应用系统,如果要操作数据库,则通过JDBC来实现的。增加、修改、删除都是通过相应方法间接来实现的,事务的控制也相应转移到Java程序代码中。因此,数据库操作的事务习惯上就称为Java事务。

二、为什么需要Java事务

事务是为解决数据安全操作提出的,事务控制实际上就是控制数据的安全访问。

举一个简单例子:比如银行转帐业务,账户A要将自己账户上的500元转到B账户下面,A账户余额首先要减去500元,然后B账户要增加500元。假如在中间网络出现了问题,A账户减去500元已经结束,B因为网络中断而操作失败,那么整个业务失败,必须做出控制,要求A账户转帐业务撤销。这才能保证业务的正确性,完成这个操作就需要事务,将A账户资金减少和B账户资金增加放到一个事务里面,要么全部执行成功,要么操作全部撤销,这样就保持了数据的安全性。

三、Java事务的类型

Java事务的类型有三种:JDBC事务、JTA(JavaTransaction API)事务、容器事务。

3.1 JDBC事务

JDBC 事务是用 Connection 对象控制的。JDBC Connection 接口( java.sql.Connection )提供了两种事务模式:自动提交和手工提交。 java.sql.Connection 提供了以下控制事务的方法:

JDBC处理事务示例:

public void transferAccount() {
		 Connection conn = null;
		 Statement stmt = null;
		 try{
			 conn = getDataSource().getConnection();
			 // 将自动提交设置为 false,
			 //若设置为 true 则数据库将会把每一次数据更新认定为一个事务并自动提交
			 conn.setAutoCommit(false);
			 stmt = conn.createStatement();
			 // 将 A 账户中的金额减少 500
			 stmt.execute("             update t_account set amount = amount - 500 where account_id = 'A'");
			 // 将 B 账户中的金额增加 500
			 stmt.execute("             update t_account set amount = amount + 500 where account_id = 'B'");
			 // 提交事务
		     conn.commit();
			 // 事务提交:转账的两步操作同时成功
		 } catch(SQLException sqle){
			 try{
				 // 发生异常,回滚在本事务中的操做
                conn.rollback();
				 // 事务回滚:转账的两步操作完全撤销
                 stmt.close();
                 conn.close();
			 }catch(Exception ignore){ 

			 }
			 sqle.printStackTrace();
		 }
	 }

使用 JDBC 事务界定时,您可以将多个 SQL 语句结合到一个事务中。JDBC 事务的一个缺点是事务的范围局限于一个数据库连接。一个 JDBC 事务不能跨越多个数据库。

3.2、JTA(JavaTransaction API)事务

JTA是一种高层的,与实现无关的,与协议无关的API,应用程序和应用服务器可以使用JTA来访问事务。

JTA允许应用程序执行分布式事务处理——在两个或多个网络计算机资源上访问并且更新数据,这些数据可以分布在多个数据库上。JDBC驱动程序的JTA支持极大地增强了数据访问能力。

如果计划用 JTA 界定事务,那么就需要有一个实现 javax.sql.XADataSource 、javax.sql.XAConnection 和 javax.sql.XAResource 接口的 JDBC 驱动程序。一个实现了这些接口的驱动程序将可以参与 JTA 事务。一个 XADataSource 对象就是一个 XAConnection 对象的工厂。 XAConnections 是参与 JTA 事务的 JDBC 连接。

您将需要用应用服务器的管理工具设置 XADataSource。(从应用服务器和 JDBC 驱动程序的文档中可以了解到相关的指导)

J2EE应用程序用 JNDI 查询数据源。一旦应用程序找到了数据源对象,它就调用 javax.sql.DataSource.getConnection() 以获得到数据库的连接。

XA 连接与非 XA 连接不同。一定要记住 XA连接参与了 JTA 事务。这意味着 XA 连接不支持 JDBC 的自动提交功能。同时,应用程序一定不要对 XA 连接调用 java.sql.Connection.commit() 或者java.sql.Connection.rollback() .

相反,应用程序应该使用UserTransaction.begin()、 UserTransaction.commit() 和UserTransaction.rollback() .

JTA事务处理程序示例:

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();
		 }
	 }

3.3、容器事务

容器事务主要是J2EE应用服务器提供的,容器事务大多是基于JTA完成,这是一个基于JNDI的,相当复杂的API实现。相对编码实现JTA事务管理,我们可以通过EJB容器提供的容器事务管理机制(CMT)完成同一个功能,这项功能由J2EE应用服务器提供。这使得我们可以简单的指定将哪个方法加入事务,一旦指定,容器将负责事务管理任务。这是我们土建的解决方式,因为通过这种方式我们可以将事务代码排除在逻辑编码之外,同时将所有困难交给J2EE容器去解决。使用EJB CMT的另外一个好处就是程序员无需关心JTA
API的编码,不过,理论上我们必须使用EJB.

目前EJB框架事务管理结构

EJB有两种使用事务的方式。

第一种方式通过容器管理的事务,叫CMT,另一种通过bean管理的事务叫BMT。

在CMT中,容器自动提供事务的开始、提交和回滚。总是在业务方法的开始和结束处标记事务的边界。下面以ejb3 in action上的例子说明:

@Stateless
	@TransactionManagement(TransactionManagementType.CONTAINER)
	public class OrderManagerBean {
	    @Resource
	    private SessionContext context;
	…
	@TransactionAttribute(TransactionAttributeType.REQUIRED)
	    public void placeSnagItOrder(Item item, Customer customer){
	        try {
	            if (!bidsExisting(item)){
	                validateCredit(customer);
	                chargeCustomer(customer, item);
	                removeItemFromBidding(item);
	            }
	        } catch (CreditValidationException cve) {
	            context.setRollbackOnly();
	        } catch (CreditProcessingException cpe){
	            context.setRollbackOnly();
	        } catch (DatabaseException de) {
	            context.setRollbackOnly();
	        }
	    }
	}

其中,@TransactionAttribute(TransactionAttributeType.REQUIRED)表示指定事务的类型。

如果省略,默认为CMT方式。

@TransactionAttribute(TransactionAttributeType.REQUIRED)通知容器如何管理事务,

事务的属性控制了事务的使用范围,因为事务之间的关系非常的复杂,这个属性主要是用来处理事务与事务之间怎样来处理的的问题。

如果产生一个系统异常,容器将自动回滚该事务。 EJBException是RuntimeException的子类,即也是一个系统运行时异常。

如果Bean抛出一个普通的非继承自RutimeException应用异常,事务将不会自动回滚,但可以通过调用EJBContext的SetRollbackOnly回滚。

当然EJB上下文还有一个getRollbackOnly方法,通过返回一个boolean值来确定CMT事务是否已被标记为回滚。如果开始非常耗资源的操作前判断此bean的事务已被标记为回滚,则可以节约很多系统资源。

2.bean管理事务

由于CMT依靠容器开始、提交和回滚事务,所以会限制事务的边界位置。而BMT则允许通过编程的方式来指定事务的开始、提交和回滚的位置。主要使用的是javax.transaction.UserTransaction接口。

如下面代码:

@Stateless)
@TransactionManagement(TransactionManagementType.BEAN)
public class OrderManagerBean {
    @Resource
    private UserTransaction userTransaction;
       public void placeSnagItOrder(Item item, Customer customer){
        try {
            userTransaction.begin();
            if (!bidsExisting(item)){
                validateCredit(customer);
                chargeCustomer(customer, item);
                removeItemFromBidding(item);
            }
            userTransaction.commit();
        } catch (CreditValidationException cve) {
            userTransaction.rollback();
        } catch (CreditProcessingException cpe){
            userTransaction.rollback();
        } catch (DatabaseException de) {
            userTransaction.rollback();
        } catch (Exception e) {
            e.printStackTrace();
        }
    }
}

@TransactionManagement(TransactionManagementType.BEAN) 指定了事务的类型为BMT,上面没有用到@TransactionAttribute,因为它只适用于CMT,在上面代码中,可以显示的指定事务的开始与提交,因此更加的灵活。上面最关键的地方是注入了UserTransaction资源。

时间: 2024-11-14 18:09:19

分布式事务解决方案(一)的相关文章

分布式事务 解决方案

事务的概念来源于业务过程.在许多情况下我们都希望能够确保在一个过程中执行的所有操作是完全成功的.在集中式系统中,事务被广泛用于服务器端和数据库系统,控制数据的操作.随着分布式计算的发展,事务在分布式计算领域中也得到了广泛的应用,但是分布式系统架构中,分布式事务问题是一个绕不过去的挑战.而微服务架构的流行,让分布式事问题日益突出! 下面我们以电商购物支付流程中,在各大参与者系统中可能会遇到分布式事务问题的场景进行详细的分析! 如上图所示,假设三大参与平台(电商平台.支付平台.银行)的系统都做了分布

基于金融系统的分布式事务解决方案

分布式系统架构中,分布式事务问题是一个绕不过去的挑战.而微服务架构的流行,让分布式事问题日益突出! 下面我们以电商购物支付流程中,在各大参与者系统中可能会遇到分布式事务问题的场景进行详细的分析! 如上图所示,假设三大参与平台(电商平台.支付平台.银行)的系统都做了分布式系统架构拆分,按上数中的流程步骤进行分析: 1.电商平台中创建订单:预留库存.预扣减积分.锁定优惠券,此时电商平台内各服务间会有分布式事务问题,因为此时已经要跨多个内部服务修改数据: 2.支付平台中创建支付订单(选银行卡支付):查

微服务架构的分布式事务解决方案

微服务架构的分布式事务解决方案 标签:分布式事务,微服务,消息最终一致性,分布式事务解决方案发布于 2016-07-16 18:39:05 分布式系统架构中,分布式事务问题是一个绕不过去的挑战.而微服务架构的流行,让分布式事问题日益突出! 下面我们以电商购物支付流程中,在各大参与者系统中可能会遇到分布式事务问题的场景进行详细的分析! 如上图所示,假设三大参与平台(电商平台.支付平台.银行)的系统都做了分布式系统架构拆分,按上数中的流程步骤进行分析: 1.电商平台中创建订单:预留库存.预扣减积分.

java微服务架构的分布式事务解决方案

java微服务架构的分布式事务解决方案 课程目录如下: 1.课程介绍20分钟2.解决方案的效果演示(结合支付系统真实应用场景)45分钟3.常用的分布式事务解决方案介绍47分钟4.消息发送一致性(可靠消息的前提保障)20分钟5.消息发送一致性的异常流程处理16分钟6.常规MQ队列消息的处理流程和特点12分钟7.消息重复发送问题及业务接口的幂等性设计18分钟8.可靠消息最终一致性方案1(本地消息服务)的设计19分钟9.可靠消息最终一致性方案2(独立消息服务)的设计24分钟10.可靠消息服务的设计与实

分布式事务解决方案---阅读--篇1--关于分布式系统的数据一致性问题

self: 这篇文章逻辑不算很清晰,但讲到的点还算是比较好的.自己总结一下可以做不错的参考: 1. 这边文章主要讲了两个方面,一方面是MQ的消息可靠性问题,另一方面是MQ可以被利用来做补偿机制的最终一致性分布式事务解决方案. 2. 关于MQ消息的问题大致有下面三个 2.1 如何保证A->M的消息,M一定接收到了,同样,如何保证M->A的消息,M一定接收到了 2.2 如果数据需要一致性更新,比如A发送了三条消息给M,M要么全部保存,要么全部不保存,不能够只保存其中的几条记录.我们假设更新的数据是

微服务架构下分布式事务解决方案——阿里云GTS

https://blog.csdn.net/jiangyu_gts/article/details/79470240 1 微服务的发展 微服务倡导将复杂的单体应用拆分为若干个功能简单.松耦合的服务,这样可以降低开发难度.增强扩展性.便于敏捷开发.当前被越来越多的开发者推崇,很多互联网行业巨头.开源社区等都开始了微服务的讨论和实践.Hailo有160个不同服务构成,NetFlix有大约600个服务.国内方面,阿里巴巴.腾讯.360.京东.58同城等很多互联网公司都进行了微服务化实践.当前微服务的开

分布式事务解决方案

分布式理论 当我们的单个数据库的性能产生瓶颈的时候,我们可能会对数据库进行分区,这里所说的分区指的是物理分区,分区之后可能不同的库就处于不同的服务器上了,这个时候单个数据库的ACID已经不能适应这种情况了,而在这种ACID的集群环境下,再想保证集群的ACID几乎是很难达到,或者即使能达到那么效率和性能会大幅下降,最为关键的是再很难扩展新的分区了,这个时候如果再追求集群的ACID会导致我们的系统变得很差,这时我们就需要引入一个新的理论原则来适应这种集群的情况,就是 CAP 原则或者叫CAP定理,那

分布式事务解决方案——柔性事务与服务模式

在分布式系统中,是无法使用本地事务保证数据的一致性的.一种标准的分布式事务就是全局事务(DTP模型).他是基于2PC来控制的.但是由于2PC自身就存在同步阻塞的问题,这也就导致全局事务效率很低.所以,这种全局事务并不适合解决大型网站的分布式事务问题. 柔性事务在业内,主要用来解决分布式事务的方案是使用柔性事务.所谓柔性事务,相比较与数据库事务中的ACID这种刚性事务来说,柔性事务保证的事"基本可用,最终一致."这其实就是基于BASE理论,保证数据的最终一致性. 虽然柔性事务并不像刚性事

阿里微服务架构下分布式事务解决方案-GTS

虽然微服务现在如火如荼,但对其实践其实仍处于初级阶段.即使互联网巨头的实践也大多是试验层面,鲜有核心业务系统微服务化的案例.GTS是目前业界第一款,也是唯一的一款通用的解决微服务分布式事务问题的中间件,而且可以保证数据的强一致性.本文将对GTS做出深入解读. 微服务倡导将复杂的单体应用拆分为若干个功能简单的.松耦合的服务,这样可以降低开发难度.增强扩展性.便于敏捷开发.概念2012年提出迅速火遍全球,被越来越多的开发者推崇,很多互联网行业巨头.开源社区等都开始了微服务的讨论和实践.根据Netfl

阿里开源分布式事务解决方案 Fescar 全解析

广为人知的阿里分布式事务解决方案:GTS(Global Transaction Service),已正式推出开源版本,取名为"Fescar",希望帮助业界解决微服务架构下的分布式事务问题,今天我们一起来深入了解. FESCAR on GitHub https://github.com/alibaba/fescar 微服务倡导将复杂的单体应用拆分为若干个功能简单.松耦合的服务,这样可以降低开发难度.增强扩展性.便于敏捷开发.当前被越来越多的开发者推崇,系统微服务化后,一个看似简单的功能,