java中对事务怎么理解_浅析Java中的事务，从ACID到BASE

本文收录在javaskill.cn中，内有完整的JAVA知识地图，欢迎访问

1. 数据库中的事务

Java中的事务管理，最终都是体现在数据上，因此，了解数据库对事务的处理是非常必要的

1.1 ACID

Atomicity、Consistency、Isolation、Durability

原子性、一致性、隔离性、持久性

原子性

事务中的操作必须全部成功或全部失败

一致性

事务必须使数据库从一个一致性状态转变到另一个一致性状态

栗子：A有100元，B有100元，AB共200元，无论A和B怎么转账(不考虑手续费)，A和B一共有200元

隔离性

事物之间不互相干扰，存在多种隔离级别

持久性

事务一旦提交，对数据的改变就是永久性的，即使遇到故障，也不会丢失提交事务的操作

1.2 脏读、不可重复读和幻读

脏读

指一个事务读取了另一个未提交的事务中的数据

不可重复读

指一个事务中，对一个值多次读取返回的值不一致(读取了其他已提交事务的数据)

幻读

栗子： T1把表A中的某个字段从1改为2，T2对表A进行了插入并提交，并且该字段为1，T1修改提交后，发现还有一条数据没有修改(注意和不可重复读的区别)

1.3 数据库的四种隔离级别

Serializable

避免脏读、不可重复读、幻读

Repeatable Read

避免脏读、不可重复读

Read Committed

避免脏读

Read Uncommitted

毛都避免不了

1.4 如何保证持久性和一致性

持久性和一致性的概念清楚了，那么数据库如何保证这一点呢？如果事务提交后，主机突然断电了呢？

概念很简单，数据库操作事务的时候，会记下这个事务的redo操作日志，在真正操作数据库之前，会把日志写入磁盘，发生异常情况后，会根据当前数据的情况进行undo或者redo，以此保证一致性和持久性，这里不再深究

2. Spring中的事务

上升到Java中，最常使用的应该是Spring中的事务操作。不管是声明式事务还是手动开启事务，在Java中，所关注的不再是数据层面的一致性(数据库已经帮我们保证了)，而是事务之间的关系。

通常，事务边界都是设定在Service层，如果一个Service层中的事务方法，调用另一个事务方法，事务是怎样传播的呢？

事务传播

Spring中共有7种不同的传播行为，以被调用方法的视角，可以把它们分为两类

被调用方支持事务

1.1 PROPAGATION_REQUIRED 必须要有事务，有就加入，无则创建

1.2 PROPAGATION_SUPPORTS 支持当前事务，有就加入，没有拉倒

1.3 PROPAGATION_MANDATORY 使用当前事务，有就加入，没有报错

1.4 PROPAGATION_REQUIRES_NEW 使用新事务，外层事务挂起，独立提交回滚

1.5 PROPAGATION_NESTED 使用嵌套事务，独立回滚(出错回滚自身)，不独立提交，没有事务则创建

被调用方不支持事务

2.1 PROPAGATION_NOT_SUPPORTED 不使用事务，有就挂起，没有拉倒

2.2 PROPAGATION_NEVER 坚决不使用事务，有就报错

需要注意1.4和1.5的区别，关键在于是否独立提交和回滚

3. 分布式事务

首先要明确的一点，在分布式事务中，ACID已经不适用了。在集群环境下，想要保证ACID几乎是不可能的任务，即使能够达到，效率也是非常低下的。所以，在集群环境下，分布式事务一般追求的是最终一致性。

3.1 BASE理论

Basically Available 基本可用

Soft state 软状态

Eventually consistent 最终一致

分布式系统中，可用性往往比一致性更重要(想象一下，支付宝为了保证强一致性，即A转100给B，A账户马上扣100，B账户马上加100，但是三天两头无服务)，BASE理论就是在可用性和一致性中做出了权衡，核心思想是，我们无法做到强一致性，但是每个应用可以结合自身的特点，用适当的方式来达到最终一致性(A支付100元给B，B可能马上收到，也可能5分钟后收到，但是最终一定会收到)。

3.2 TCC补偿事务

TCC的核心是采用了补偿机制，针对每个操作，都要有一个与之对应的补偿(回滚)操作，分为三个阶段：

Try 预留业务资源

尝试执行业务

完成所有业务检查

预留必须业务资源

Confirm 确认执行业务操作，需幂等

真正执行业务

不做业务检查

只使用try阶段预留的资源

Cancel 取消执行业务操作，需幂等

释放try阶段预留的资源

和数据库中的事务操作进行对比，可以找到类似之处，锁定行->操作行->出错回滚

举个实际的例子来加深理解

假设有A、B、C三个账户，A和B向C支付100元，A支付40元，B支付60元，需要在一个事务中完成

try

检测A、B、C三个账户的状态，是否允许转账

检测A账户是否有40元，有则冻结

检测B账户是否有60元，有则冻结

confirm

扣除A、B的冻结金额，增加C账户的金额，不做任何业务检查

cancel

恢复A或B的冻结金额

如果在try阶段发现，A的账户冻结40元成功，B冻结失败，则调用A的cancel方法，恢复A的冻结金额

3.3 本地消息表

这种思路来源于ebay

在本地新建消息表

消息和业务在同一个事务里提交

通过MQ通知消费方

消费方处理消息后通知修改消息状态

消息发送失败，重试

定时扫描未处理的消息进行重发

消费方业务失败，调用生产方补偿方法进行回滚

这种方式遵循BASE理论，保证的是最终一致性，在实际使用中，比TCC更好处理，少写很多代码。需要注意的是，消息处理需要幂等

3.4 MQ事务消息

阿里巴巴的Rocket MQ支持事务消息，Rabbit MQ和Kafka都不支持

3.3中之所以要使用本地消息表，因为更新数据库和发送MQ消息不是一个原子操作，无论谁先谁后，都会有问题

先更新DB，发送消息失败了，怎么办？

先发送消息，DB更新失败了，消息已经发了，怎么办？

3.3中采用了本地消息表，通过消息表中的消息状态来控制重发，以达到最终一致的目的

事务消息模拟了这种操作，只不过把维护消息状态的过程，从数据库转移到了MQ中间件

具体来说，就是把消息发送，分解成两个阶段，准备和确认

具体到业务中，分解成了三步操作

发送Prepared消息

更新数据库

根据2的结果，发送Confirm或Cancel，确认或取消消息

取消的消息会被丢弃，确认后的消息才会真正的发送给消费者

如果第三步失败了，RocketMQ会主动(默认1分钟)询问发送方，喂？这条消息还要吗？此时发送方可以查询本地业务状态，确定消息是否需要发送，以此确保最终一致性

总结

从ACID到BASE，对于事务，不同视角，对它的理解也不同

在数据库层面，通过日志文件确保了事务的一致性，以及确定了不同的事务隔离级别

在Java代码层面，更多的是关注事务之间的关系

而在分布式事务中，为了高可用，在事务一致性上进行了妥协，一般只保证最终一致性