事务（Transaction）是由一系列对系统中数据进行访问与更新的操作所组成的一个程序执行逻辑单元（Unit），狭义上的事务特指数据库事务，本文讲的主要是数据库事务。

ACID特性

事务具有四个特征，分别是原子性（Atomicity）、一致性（Consistency）、隔离性（lsolation）和持久性（Durability），简称为事务的ACID特性。

• 原子性：指事务是一个整体来执行，要么全部执行成功，要么全部执行失败。一损俱损，一荣俱荣。

• 一致性：一个事物在执行之前和执行之后，数据节点都必须处于一致的状态。

• 隔离性：在并发情况下，并发的事务是相互隔离的，一个事务的执行不能被其他事务所干扰。

• 持久性：把已提交的事物数据状态永久地保存下来，数据节点主要就是干这个的。

几乎所有的成熟的关系型数据库都提供了对本地事务的原生支持。但是现在的互联网公司都在拥抱微服务，在这种环境下，越来越多的应用场景要求多个数据节点能在同一个事务当中，所以就出现了与分布式应用环境对应的分布式事务。

关系型数据库虽然对本地事务提供了ACID原生支持。但在分布式的场景下，它却成为系统性能的桎梏。如何让数据节点在分布式场景下满足事务特性或找寻相应的替代方案，这就是分布式事务的要做到的。

本地事务

在每一个数据节点中，事务仅限于对他们自己的资源控制，与其他数据节点没有协调以及通信的能力，也并不互相知晓其他数据节点事务的是否成功。

两阶段提交

XA协议最早的分布式事务模型是由 X/Open 国际联盟提出的 X/Open Dirtributed Transaction Processing (DTP) 模型，简称 XA 协议。

基于XA协议实现的分布式事务对业务侵入很小。它最大的优势就是对使用方透明，用户可以像使用本地事务一样使用基于XA协议的分布式事务。XA协议能够严格保障事务 ACID 特性。

严格保障事务 ACID 特性是一把双刃剑。事务执行在过程中需要将所需资源全部锁定，它更加适用于执行时间确定的短事务。

对于长事务来说，整个事务进行期间对数据的独占，将导致对热点数据依赖的业务系统并发性能衰退明显。因此，在高并发的性能至上的场景中，基于XA协议的分布式事务并不是最佳选择。

软事务

如果把实现了 ACID 的特性的事务称为硬事务，那么基于 BASE 事务要素的事务则称为软事务。 BASE是Basically Available（基本可用）、Soft state（软状态）和Eventually consistent（最终一致性）三个短语的简写。

• 基本可用：是指分布式系统在出现不可预知的故障时，允许损失部分可用性-注意，这绝不等价于系统不可用。

• 软状态：是指允许系统中的数据存在中间状态，并认为该中间状态的存在不会影响系统的整体可用性，即允许系统在不同节点的数据副本之间进行数据同步的过程存在延时。

• 最终一致性：强调的是系统中所有的数据副本，在经过一段时间的同步后，最终能够达到一个一致的状态。

在 ACID 事务中对隔离性的要求很高，在事务执行过程中，必须将所有的资源锁定。软事务的则是通过业务逻辑将互斥锁操作从资源层面上移至业务层面。通过放宽对强一致性要求，来换取系统吞吐量的提升。

基于 ACID 的强一致性事务和基于 BASE 的最终一致性事务都不是银弹，只有在最适合的场景中才能发挥它们的最大长处。可通过下表详细对比它们之间的区别，以帮助我们进行技术选型。

要思考

由于系统的场景不同，需要我们能够合理的在性能与功能之间权衡各种分布式事务。

基于 ACID 的事务与基于 Base 的事务并不相同，所以在开发的设计阶段，我们就需要考虑该用哪种事务来处理。

基于ACID的事物使用相对来说简单些，但是无法应对高并发或复杂业务的长事务场景；

基于Base的事务则需要我们对业务代码进行改造，需要考虑资源的锁定和补偿机制等等。业界比较流行的就是Seata。

写在最后

好兄弟可以点赞并关注我的公众号“javaAnswer”，全部都是干货。