事务的隔离与传播

事务的隔离级别

  事务的隔离级别，当多个事务操作同一数据的时候，如果不加一些有序的管理的话，会发生使用混乱的现象，比如A事务操作了该数据，但是没提交，当B事务读取了A未提交的数据并进行操作的时候，A回滚了自己的事务，这时B操作的数据就是无效的，为了避免类似情况的发生，需要对事务进行隔离。

按照效率和安全级别，可将事务分为4种隔离级别，

 1，脏读 Read_uncommit,

2，不可重复读read_commit，

3，幻影读 repeatable_read，

4，顺序读取 serializable，

 隔离级别如果设为脏读的话，安全级别最低，效率最高，也就是说容易出现脏读、不可重复读、和幻影读等等，如果设置为2的话，可以避免脏读，但是会出现不可重复读和幻影读，3的话可以避免不可重复读，但是会出现幻影读，比如说数据的总量发生变化。4的话是最安全的读法，所有事务顺序进行，但是效率也是最低的。

与传播特性

 事务的隔离级别是从并列的的角度来分析事务也可以说是横向或者说地位相等的事务之间的关系与处理，而传播特性是从包含的角度来分析事务，也就是说一个事务包含在了另外一个事务里面，应该如何处理。

在spring中有一下几种处理方式，

1，required，默认的传播特性，业务方法需要在事务中进行，如果已经开启了事务，就在事务中进行，如果没有开启事务，就开启新的事务。

2,，required_new，不管该方法是否已包含在事务中，执行该方法的时候都会开启新的事务。

3，supports，如果该方法已处在事务中，就使用事务，如果不在事务中，也就不开启事务执行。

4，not_support，如果该方法处在事务中，当执行该方法的时候，挂起事务，确保该方法在非事务中进行，当该方法执行完事之后，恢复事务。

5，never，该方法绝不能在事务中执行。

6，nested，执行该方法时，新创建一个事务嵌套在外层事务，该事务有独立的回滚点，不会影响外部事务。

7，Mandatory，该方法只能在已存在的事务中进行，如果不在事务中，也不会新创建事务，但是会抛出异常。

多数据源的事务

如果需要同时操作多个数据源，我们需要确保最终多个数据源中的数据的一致性，有哪些做法呢？

1，分布式事务，两阶段提交

2，best-effort 1pc，一阶段提交

3，事务补偿机制， 

分布式事务-两阶段提交，就是尽可能保证的各个数据的事务同时提交，也就是等待所有事务结束之后一起提交，这样各个数据库提交结果出现差错的概率就小了很多，但问题是，导致了能尽早提交的事务需要等到所有事务结束之后才能提交，降低了效率。

best-effort 1pc,一阶段提交，就是完成一个数据库的事务就提交一个，将结果返回给应用程序，这样的效率比较高，但是牺牲了安全性，最终的结果不一致的概率增大。

事务补偿机制，比如在一个方法里面调用了多个系统的webservice方法，对其他系统进行操作，牺牲了数据的实时一致性，采取一定的机制比如说对账检查，日志，定期同步标准数据来源，等等，实现最终结果的一致性，