分布式事务的概念及特征

基本概念
事务
由多个计算任务组成的具有确定边界的工作集。交易可能包括接口访问、网络通信、数据采集和处理。严格的事务实现应该具有四个特征:原子性、一致性、隔离性和持久性。

原子性:事务中的所有任务要么完成，要么失败。没有中间状态。

隔离:不同事务之间的操作互不影响，并发事务的中间状态对其他事务是不可见的。

持久性:一旦交易完成，状态将永久有效。

一致性:事务涉及的资源或数据在事务前后都遵循一定的约束，事务的完成或失败都不会影响这种状态。

分布式事务
在分布式系统中，事务访问涉及的资源和计算涉及的节点部署在不同的节点上，这种情况下涉及的事务称为分布式事务。
从系统的整体架构来看，分布式事务涉及的场景可以分为两类。第一类是事务本身只涉及单个应用，但涉及多个数据存储，一个事务需要访问多个数据存储才能最终完成。在第二类中，事务本身涉及多个应用程序，每个应用程序可能与一个或多个数据存储区相连。一个事务只能通过与多个独立的应用程序协作来访问多个数据存储来完成。

一致
严格来说，一致性不是交易本身的特征。可以看出，一致性讨论的所谓“约束”是随着业务场景的变化而变化的。

为了保证一致性，除了数据库级的对应机制外，首先要考虑应用级。例如，对于一个典型的双账户转账例子，应用程序需要确保转出账户和转入账户的减少和增加操作是在同一件事上启动的。如果少了任何一个，即使使用了事务，从业务的角度来看也会违反一致性约束。

在应用程序级确保业务的正确性之后，我们将从数据库级对其进行检查。也是转移的一个例子。假设某个数据库的事务支持有问题。某笔交易发生一定故障后，发现转出账户的钱相应减少了，但转入账户的钱却没有增加，显然存在违反业务一致性约束的情况。但是仔细分析之后，我们会发现，考虑到事务本身，这种场景实际上首先违反了事务的原子性，即只完成了应该同时完成的任务的一半。所以在这种场景下，一致性的体现其实是由原子性来保证的。再比如，同时考虑同一账户上的两笔转账交易，如果交易A扣100元，交易B扣50元，如果两笔交易都提交，发现账户实际上是扣50元而不是150元，明显违反了业务一致性约束。这种情况实际上是通过事务的隔离来保证的。

因此，一般来说，一致性更多的是对数据存储的业务约束保证。它所描述的特性是事务方面的原子性和隔离性，这在不同的场景中得到保证。

强一致性和最终一致性
在讨论事务的一致性，尤其是分布式事务的一致性时，涉及到分布式系统和事务两个问题类别，它们有各自的定义，难以理解。如果仔细研究区分，就会发现事务域讨论的一致性问题和分布式系统域讨论的不一样，他们的问题提出场景和对应的解决模型也不一样。不幸的是，这两个问题经常被放在一起讨论，并且被类比，造成了一些混乱。

由于这两个问题的复杂性，以及现有的共同讨论造成的信息混杂，这里没有对一致性进行深入的讨论。

根据分布式事务中涉及的一致性问题，做出以下假设:

分布式事务和分布式系统中涉及的一致性问题是两个问题。

分布式企业讨论的一致性按照通称叫做强一致性和最终一致性

从系统整体考虑，分布式事务的强一致性和事务的一致性讨论的是同一个问题，即系统在事务执行前后满足一定的业务约束。

最终一致性是指分布式事务提交后，业务一致性约束可能不会马上满足，但会在未来某个时间满足，并且一定会发生。