分布式事务

分布式事务

   事务在逻辑上是的一组操作，要么都执行，要么都不执行，事务有四个特点也就是常说的ACID，A代表原子性，是最小事务的执行单位，不允许分割。原子性确保动作 要么全部完成，要么完全不起作用；C代表一致性，执行事务前后，数据保持一致，多个事务对同一个数据读取的 结果是相同的，I代表隔离性，并发访问数据库时，一个用户的事务不被其他事务所干扰，各个并发事务之间数据库是独立的，D的话就是代表持久性，也就是说一个事务在被提交了之后。它对数据库中数据的改变是持久的，即使数据库发生故障也不应该对其有任何影响。

   事务的隔离性也带来了问题，他会造成一个事物读取到另外一个事务的修改之后尚未提交的数据，也叫做脏读，一个事务多次读取数据，多次读取的数据不一致，可能中间有人操作数据，这也叫做不可重复读，还有一个事务在读取数据时两次读取的数据条数不一致，可能是中间有事务添加数据导致，这也是所说的幻读。

   因此数据库定义了四种隔离级别用来解决这些问题，

READ-UNCOMMITTED(读取未提交)：最低的隔离级别，允许读取尚未提交 的数据变更，可能会导致脏读、幻读或不可重复读。

 • READ-COMMITTED(读取已提交)： 允许读取并发事务已经提交的数据，可 以阻止脏读，但是幻读或不可重复读仍有可能发生。

 • REPEATABLE-READ(可重复读)： 对同一字段的多次读取结果都是一致的， 除非数据是被本身事务自己所修改，可以阻止脏读和不可重复读，但幻读 仍有可能发生。

• SERIALIZABLE(可串行化)： 最高的隔离级别，完全服从 ACID 的隔离级 别。所有的事务依次逐个执行，这样事务之间就完全不可能产生干扰，也 就是说，该级别可以防止脏读、不可重复读以及幻读。

分布式事务指的是在跨服务之间的多数据库多服务，以及多服务单数据库的操作，准确的说，分布式事务是指事务的参与者、支持事务的服务器、资源服务器及事务管理器分别位于分布式系统的不同节点上。

分布式事务问题也叫分布式数据一致性问题，简单来说就是如何在分布式场景中保证多个节点数据的一致性。分布式事务产生的核心原因在于存储资源的分布性。

分布式事务保证数据的一致性分为了三类，

强一致性：如果项目对缓存的要求是强一致性的，那么就不要使用缓存。这种一致性级别是最符合用户直觉的，它的话就是系统写入什么，读出来的也会是什么，用户体验好，但实现起来对系统的性能影响大（强一致性读写的请求会串行化，串到一个内存队列，这样会大大增加系统的处理效率，吞吐量也会大大降低。），也就是刚性事务（对数据的要求是立刻马上同步）。

弱一致性：它约束了系统在写入成功后，不会立即可以读到写入的值，也不确定多久之后数据能够达到一致，但会尽可能地保证到某个时间级别（比如秒级别）后，数据能够达到一致状态。也是柔性事务（对数据的要求是要时间弹性的同步，数据最终一致就行）。

最终一致性：最终一致性其实是弱一致性的一个特例，系统会保证在一定时间内，能够达到一个数据一致的状态。之所以最终一致性是一个特例，是因为它是弱一致性中非常推崇的一种一致性模型，在一般情况下，高可用只确保最终一致性，不确保强一致性。

既然是分布式事务那么久离不开CAP：

CAP是分布式系统设计中的三个核心概念，是一种理论，他们表示在一个分布式系统中很难同时满足一致性，可用性和分区容错性这三种特性。

C:一致性：就表示系统中所有的服务都要保证一致性的状态，所有读的操作都要返回最新写入的数据，所以在分布式中实现强一致性需要付出较高的代价，对系统的可用性会产生影响。

A:可用性就表示任何时刻都能够满足用户的请求，是分布式中特别重要的特性，因为用户普遍对系统的可用性要求比较高。

P:分区容错性表示在系统面对各个节点之间通信故障或者网络分区的情况下仍然能继续运行并保证数据的一致性（由于网络通信的不稳定性和不可靠性，分布式系统必须具备分区容忍性来应对这些情况。）

但是在分布式中不能完全满足这三个特性，最多只能存在两个，可以在一致性，可用性和分区容错性之间取舍。

分布式事务中对CAP进行了补充，提出了BASE理论，BASE理论包含三个思想：

Basically Available（基本可用）就是在系统出现故障时，允许损失部分可用性，保证核心可用即可。（譬如电商大促，为了应对大流量，暂时停止注册服务，这时注册服务就不可用，但是整个系统是可用的，所以叫基本可用）

Soft State（软状态）在一定时间内允许出现中间状态，也是就临时的数据不一致。

Eventually Consistent（最终一致性）：无法保证强一致性，但是软状态结束后，最终达到数据的一致性。

分布式事务把多个服务看做子事务，整个项目看做全局事务也就是事务协调者，用来监控和通知各个分支事务。

分为两种模式：

AP模式保证数据的最终一致性，各子事务分别执行和提交，允许出现结果不一致，然后采用弥补措施恢复数据即可，实现最终一致。（譬如：增加了一条数据，后面有操作失败了，那么，补偿措施只需要把增加的那条数据删除即可）因为子事务提交了，那么提交后的状态是一个中间状态，也就是软状态

CP模式保证强一致性，各个子事务执行后互相等待，同时提交，同时回滚，达成强一致。但事务等待过程中，处于弱可用状态。事务执行过程中，会锁定操作的资源，那么这个资源暂时是不可用的。所以整个系统是基本可用。