分布式事务

一.事务：
   事务可以看做是一次大的活动，它由不同的小活动组成，这些活动要么全部成功，要么全部失败
二 分布式事务：
   1.定义：
分布式事务是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上。
2 CAP理论：
CAP定理是由加州大学伯克利分校Eric Brewer教授提出来的，他指出WEB服务无法同时满足一下3个属性：

a.Consistency（一致性）
        在分布式环境中，一致性是指数据在多个副本之间是否能够保持数据一致的特性。在一致性的需求 下，当一个系统在数据一致的状态下执行更新操作后，应该保证系统的数据仍然处于一致的状态。 例如一个将数据副本分布在不同分布式节点上的系统来说，如果对第一个节点的数据进行了更新操作并且更新成功后，其他节点上的数据也应该得到更新，并且所有用户都可以读取到其最新的值， 那么这样的系统就被认为具有强一致性（或严格的一致性，最终一致性）。
b.Availability（可用性）
在集群中一部分节点故障后，集群整体是否还能响应客户端的读写请求（对数据更新具备高可用性）
c.Partition tolerance（分区容错性）
         分区容错性约束了一个分布式系统需要具有如下特性：分布式系统在遇到任何网络分区故障的时候，仍然需要能够保证对外提供满足一致性和可用性的服务，除非是整个网络环境都发生了故障。

这三个基本需求，最多只能同时满足其中的两项
3 Base 理论
由 eBay 架构师提出，是对 CAP 中一致性和可用性权衡的结果，其来源与对大规模互联网系统分布式实践的结论，是基于 CAP 定理逐步演化而来的。
    BASE 是 Basically Available（基本可用）、Soft state（软状态）和 Eventually consistent（最终一致性）三个词语的简写。
     即使无法做到强一致性（Strong Consistency），但每个应用都可以根据自身的业务特点，采用适当的方式来使系统达到最终一致性（Eventual consistency）。
a.Basically Available（基本可用）:分布式系统在出现不可预知的故障时，允许损失部分可用性。
b    Soft state（软状态）：允许部分节点的数据存在一定的延时，这个延时不影响系统整体的可用性。即不需要完全符合 ACID 的原子性
c  Eventually consistent（最终一致性）:最终一致性强调的是系统中所有的数据副本，在经过一段时间的同步后，最终能够达到一个一致的状态。因此，最终一致性的本质是需要系统保证最终数据能够达到一致，而不需要实时保证系统数据的强一致性。

三.单个DB节点事务的隔离级别

1.read uncommitted（读未提交）
      一个事务还没提交时，它修改的数据都可以被别的事务看到。
       可能存在：脏读、不可重复读、幻读

2.read committed（读已提交）
      一个事务提交之后，它修改的数据才会被别的事务看到
       可能存在：不可重复读、幻读

3.repeatable read（可重复读）
       说明事务保证能够再次读取相同的数据而不会失败，即使其他的事务把这个数据改了，你也不会看到前后两次查询的数据的不同
       可能存在：幻读

4.serializable（串行化）
     数据的读和写都会加锁，读会加读锁，写会加写锁。当遇到读写锁冲突时，后访问的事务必须等前一个事务执行完成后，再继续执行。
   脏读：事务A修改数据，事务B读取了数据后事务A报错回滚，修改的数据没有提交到数据库中，此时事务B读取修改的数据就是一个脏读，也就是一个事务读取到另一个事务未提交的数据就是脏读。
 不可重复读：事务A在同一个事务上多次读取同一个数据，在事务A还没有结束时，事务B修改了该数据，由于事务B的修改，导致事务A两次读取的数据不一致，就出现了不可以重复读的现象。
 幻读：事务A根据条件查询得到N条数据，但此时事务B更改或者增加了M条符合事务A查询的条件的数据。这样当事务A再次查询的时候发现会有N + M条数据，产生了幻读。

四. 分布式事务隔离级别

  分布式数据库的存储节点层，还是遵守单机DB的事务隔离级别的，但是在计算节点层新增了分布式事务的隔离级别，如下：
1.脏读（UR）
     查询时，读取的数据中允许包含脏数据，不检验来自各存储节点的数据是否活跃，即不检验来自个存储节点的数据是否来自同一版本的副本数据。
2.强一致读（CR）
     查询时，读取的数据中不允许包含脏数据，检验来自各存储节点的数据不能为活跃状态，即检验来自各存储节点的数据必须为同一版本或同一时刻的副本数据。
3.单节点写（SW）
不考虑分布式事务下的对部分已提交事务的数据的修改，即不检验修改的数据是否活跃。
4.强一致写（CW）
需要考虑分布式事务下的对部分已提交事务的数据的修改，需要检验修改的数据是否处于活跃状态，活跃状态的数据不能修改，只能修改已经全局提交成功的数据。
5.读已提交（MVCC_RC）
查询时，未全局提交的数据和在本查询语句后发起的已提交数据不可见，返回全局一致数据快照。同一个事务中，不同的select查询根据select查询发起时间取一致性快照。