事务理论/分布式事务一致性【小总结】

1、事务相关理论

目前关于事务的几大理论包括：ACID特性（数据库的特性），CAP分布式理论，以及BASE等。

• 事务的ACID特性：数据库
• 事务的CAP分布式理论、BASE：分布式事务

事务的ACID特性

一、A（原子性）：一个事务包含多个操做，这些操做要么所有执行，要么全都不执行；实现事务的原子性，要支持回滚操做，在某个操做失败后，回滚到事务执行以前的状态。

二、C（一致性）：一致性是指事务使得系统从一个一致的状态转换到另外一个一致状态，保证数据的完整性。事务的一致性决定了一个系统设计和实现的复杂度，也致使了事务的不一样隔离级别。

三、I（隔离性）：保证事务不受外部并发操做，在独立环境执行。多个并发的事务同时访问一个数据库时，一个事务不该该被另外一个事务所干扰，每一个并发的事务间要相互进行隔离。

四、D（持久性）：指一个事务一旦被提交了，那么对数据库中的数据的改变是永久的，即使是在数据库系统遇到故障的状况下也不会丢失提交事务的操做。

事务的CAP理论

一、C（一致性）：在分布式环境下，一致性是指多个节点数据是否一致；

二、A（可用性）：服务一直保持可用的状态，当用户发出一个请求，服务能在必定的时间内返回结果；不少中间件或者开源框架都支持高可用方案（Redis、Zookeeper等）；

三、P（分区容忍性）：特指对网络分区的容忍性；分布式系统在遇到任何的 网络分区（分布式系统中不一样节点部署在不同的网络环境） 故障的时候，仍然须要保证对外提供知足一致性和可用性的服务

BASE

BA: Basic Availability 基本业务可用性；

S: Soft state 柔性状态；

E: Eventual consistency 最终一致性；

2、事务的隔离性

一、在事务并发操做时，可能出现的问题有以下三种：

• 脏读：事务A修改了一个数据，但未提交，事务B读到了事务A未提交的更新结果，若是事务A提交失败，事务B读到的就是脏数据
• 不可重复读：在同一个事务中，对于同一份数据读取到的结果不一致。好比，事务B在事务A提交前读到的结果，和提交后读到的结果可能不一样。不可重复读出现的缘由就是事务并发修改记录，要避免这种状况，最简单的方法就是对要修改的记录加锁，这回致使锁竞争加重，影响性能。另外一种方法是经过MVCC能够在无锁的状况下，避免不可重复读。

补充 MVCC：多版本并发控制。是一种并发控制的方法，你们应该知道，锁机制能够控制并发操做，可是系统开销比较大（悲观锁），而MVCC（乐观锁）能够在大多数状况下代替行级锁，能够下降系统开销。 在MYSQL中，MyISAM使用的是表锁，InnoDB使用的是行锁。而InnoDB的事务分为四个隔离级别，其中默认的隔离级别REPEATABLE READ须要两个不一样的事务相互之间不能影响，并且还能支持并发，这点悲观锁是达不到的，因此REPEATABLE READ采用的就是乐观锁，而乐观锁的实现采用的就是MVCC。正是由于有了MVCC，才造就了InnoDB强大的事务处理能力

乐观锁读写事务，在真正的提交以前，不加读/写锁，而是先看一下数据的版本/时间戳，等到真正提交的时候再看一下版本/时间戳，若是两次相同，说明别人期间没有对数据进行过修改，那么就能够放心提交

• 幻读：在同一个事务中，同一个查询屡次返回的结果不一致。事务A新增了一条记录，事务B在事务A提交先后各执行了一次查询操做，发现后一次比前一次多了一条记录。幻读是因为并发事务增长记录致使的，这个不能像不可重复读经过记录加锁解决，由于对于新增的记录根本没法加锁。须要将事务串行化，才能避免幻读

二、针对事务并发致使的问题，经过事务隔离来解决，事务隔离级别从低到高以下：

• 读未提交：顾名思义，就是能够读到未提交的内容。一个事务能够读到另外一个事务未提交的结果。上述全部的并发事务问题都会发生。如无特殊状况，基本是不会使用这种隔离级别的。
• 读提交：只有在事务提交后，其更新结果才会被其余事务看见。能够解决脏读问题。
• 可重复读：在一个事务中，对于同一份数据的读取结果老是相同的，不管是否有其余事务对这份数据进行操做，以及这个事务是否提交。能够解决脏读、不可重复读。
• 串行化：事务串行化执行，隔离级别最高，牺牲了系统的并发性。能够解决并发事务的全部问题。

一般，在项目为了性能的考虑会对隔离性进行折中

3、事务的一致性

• 强一致性：读操做能够当即读到提交的更新操做
• 弱一致性：提交的更新操做，不必定当即会被读操做读到，此种状况会存在一个不一致窗口，指的是读操做能够读到最新值的一段时间
• 最终一致性：是弱一致性的特例。事务更新一份数据，最终一致性保证在没有其余事务更新一样的值的话，最终全部的事务都会读到以前事务更新的最新值。若是没有错误发生，不一致窗口的大小依赖于：通讯延迟，系统负载等

4、分布式事务的实现：两阶段提交（2PC）和三阶段提交（3PC）【XA协议】

一、两阶段提交：

在两阶段提交中，系统分为两类节点：协调者和参与者

（1）请求阶段（决策阶段）：协调者将通知事务参与者准备提交或取消事务，而后进入表决过程；在表决过程当中，参与者将告知协调者本身的决策：赞成（事务参与者本地做业执行成功）或取消（本地做业执行故障）

（2）提交阶段：在该阶段，协调者将基于第一个阶段的投票结果进行决策：提交或取消。 当且仅当全部的参与者赞成提交事务协调者才通知全部的参与者提交事务，不然协调者将通知全部的参与者取消事务。 参与者在接收到协调者发来的消息后将执行响应的操做

缺点：

• 同步阻塞问题：执行过程当中，全部的节点都是事务阻塞的；
• 数据不一致：在两阶段提交的第二阶段中，当协调者向参与者发送commit请求后，因为网络缘由或者在发送commit请求过程当中协调者发生了故障，只有一部分参与者收到了commit请求，而且执行提交操做，其余参与者没法执行事务提交，最后致使整个分布式系统的数据不一致

全部两阶段提交没法解决的问题就是：没法保证事务执行的完整性（数据的一致性）

二、三阶段提交：

与两阶段提交协议的区别：三阶段提交协议在协调者和参与者之间引入了超时机制； 在2PC的准备阶段和提交阶段之间，插入预提交阶段，使3PC拥有CanCommit、PreCommit、DoCommit三个阶段。 PreCommit是一个缓冲，保证了在最后提交阶段以前各参与节点的状态是一致的

（1）CanCommit阶段：3PC的CanCommit阶段其实和2PC的准备阶段很像。 协调者向参与者发送commit请求，参与者响应是否能够提交。

（2）PreCommit阶段：协调者根据参与者的响应状况来决定是否能够继续事务的PreCommit操做

• 若是全部参与者的（canCommit）响应都是能够提交，那么就会执行事务的预执行；1)发送预提交请求：协调者向参与者发送preCommit请求，并进入prepared阶段；2)事务预提交：参与者接收PreCommit请求后，会执行事务操做，并将undo和redo信息记录到事务日志中；3)响应反馈：若是参与者成功地执行了事务操做，则返回ACK响应，同时开始等待最终指令。
• 若是有任何一个参与者响应是不能够提交，或者等待超时以后，协调者都没有收到参与者的响应，那么就会中断事务；1)发送中断请求：协调者向全部参与者发送中断请求；2)中断事务：参与者收到协调者发送过来的中断请求以后，或者超时以后，尚未收到参与者的响应，那么会执行事务的中断

（3）DoCommit阶段：该阶段进行真正的事务提交

• 执行提交：1)发送提交请求：协调者收到参与者发送的ACK响应（PreCommit），那么他将从预提交状态进入提交状态，并向全部参与者发送DoCommit请求；2)事务提交：参与者接收到doCommit请求以后执行正式的事务提交。并在完成事务提交以后释放全部事务资源；3)响应反馈：事务提交完以后，向协调者发送ACK响应；4)完成事务：协调者接收到全部参与者的ACK响应以后，完成事务
• 中断事务：协调者没有接收到参与者发送的ACK响应（多是接受者发送的不是ACK响应，也可能响应超时），那么就会执行中断事务

缺点：若是进入PreCommit后，协调者发出的是abort请求，假设只有一个参与者收到并进行了abort操做， 而其余对于系统状态未知的参与者会根据3PC选择继续Commit，此时系统状态发生不一致性

小总结：

分布式系统的一个难点就是：“网络通讯的不可靠”，只能经过“确认机制”、“重试机制”、“补偿机制”等各方面来解决一些问题。在综合考虑可用性、性能、实现复杂度等各方面的状况上，比较好的选择是“异步确保最终一致性”（确认机制），只是具体实现方式上有一些差别