事务的深入研究

事务

1.事务的ACID

指的是事务的四个特征：原子性（Atomicity）、一致性（Consistency）、隔离性（isolation）、持续性（Durability）

2.详细理解

1.原子性（Atomicity）

食物是数据库的逻辑工作单位，事务中包含的个操作要么都做，要么都不做。在某个操作失败后，回滚到事务执行之前的状态。
例如：

一个简单的订单逻辑

当加了事务的时候：

五个步骤哪一个挂了，都应该直接回滚操作，要么都成功，要么都失败。

2.一致性

一致性是指事务使得系统从一个一致的状态转换到另一个一致状态。事务的一致性决定了一个系统设计和实现的复杂度。事务可以不同程度的一致性：

一致性例子：

​ 还是上面的操作：如果冰箱的库存是200台，当加了事务，事务成功了：一共还是二百台，不过一台状态是等待物流处理，199台是待销售状态。事务失败了：挂在预定库位上，一共还是200台没变化，挂在释放库存商品，还是200台，只不过是有一台是预留状态，199台待销售状态。事务前后库存中的冰箱总部不变。

事务可以有不同程度的一致性：

• 强一致性： 读操作可以立即读到提交的更新操作。

• 弱一致性： 提交的跟新操作，不一定立即会被读操作读到，此种情况存在一个不一致窗口，指的是读操作可以读到最新值的一致性。

• 最终一致性： 是弱一致性的特例。食物更新一份数据，最终一致性保证在没有其他事务跟新同样值的话，最终所有事务都会读到之前是无更新的最新值，如果没有错误发生，不一致窗口的大小依赖于：通信延迟，系统负载等等。

  其他一致性变体还有：

• 单调一致性： 如果一个进程已经读到一个值，那么后续不会读到更早的值。

• 会话一致性： 保证客户端和服务器交互的会话过程中，读操作可以读到更新操作后的最新值。

3.隔离性

​ 一个事务的执行不能其它事务干扰。即一个事务内部的操作及使用的数据对其它并发事务是隔离的，并发执行的各个事务之间不能互相干扰。

举例：

对于任意两个并发的事务T1和T2，在事务T1看来，要么T2还没开始，要么T2已经结束了，每个事务都不应该感受到其他事务的存在。

当你的T1感受到了T2会发生什么勒

• 脏读：T1修改一个数据，但是未提交，事务T2读到了事务A未提交的更新结果，当T1提交失败了，事务T2读到这个就是脏数据。 举个上面的例子就是：只有一台冰箱，T1下单：T1下单占了库位但是我在支付的时候挂了，T2物流准备发货，所以将冰箱库存-1，这时候T2读到了没库存啦，然后T1挂了，这个冰箱还在库里，T2会告诉你没有库存啦，其实库存里还有一台冰箱，这就是脏读

  ----解决的基础隔离级别：读已提交

• 不可重复读：**不可重复读出现的原因就是事务并发修改记录。**在同一个事务中，对于同一份数据读取到的结果不一致。比如，事务B在事务A提交前读到的结果，和提交后读到的结果可能不同。

  ----解决的基础隔离级别：可重复读

• 幻读：是由于并发事务增加记录导致的，而且这个结果不能通过MVCC解决，因为对新增的记录根本无法加锁，对于幻读的解决办法：将事务串行化

  —解决的基础隔离级别：串行化（针对一张表的操作，每一个session依次完成自己的操作：行锁 + 间隙锁）MySQL事务隔离级别和实现原理

事务的隔离级别

• 数据库默认的隔离级别：mysql --repeatable,oracle,sql server --read commited

  详解

  事务的隔离级别从低到高有：

  • Read Uncommitted：最低隔离级别，什么都不做，一个事务可以读到另一个事务未提交的结果，所有的并发问题都会发生
  • Read Committed：在事务提交后，其更新结果才会被其他事务看到。可以结果脏读
  • Repeated Read：在一个事务中，对同一份数据的读取结果总是相同的，无论是否有其他事务对这份数据进行操作，以及这个事务是否提交。可以解决脏读、不可重复读问题。
  • Serialization：事务串行化执行，事务隔离级别最高，牺牲了系统的并发性。可以解决并发事务的所有问题。通常在工程实践中，为了性能考虑会对隔离性进行折中。

  Mysql默认的事务隔离级别是可重复读（Repeatable Read），但是我们在项目种一般用的是读已提交（Read committed）

  why??这个级别不是存在不可重复读和幻读的问题吗

  首先要知道主从复制是基于binlog复制的，可以理解为binlog是一个记录数据库更改的文件。

  binlog一共三种格式

  • statement: 记录的是修改SQL语句
  • row： 记录的是每行实际数据的变更
  • mixed： statement和row模式的混合

  mysql在5.0之前binlog只支持statement，这种格式在读已提交（read committed）这个主从隔离级别是有bug的，所有Mysql将可重复读（Repeatable Read）作为默认的隔离级别

  那么为什么项目中是读已提交（Read committed）勒

  • 采用读未提交（Read Uncommitted）：脏读太常见了，逻辑上就走不通。

  • 采用串行化（Serializable）：每次读操作都会加锁，快照读失效，一般是使用mysql自带分布式事务功能时，才使用该隔离级别！

    对比可重复读（Repeatable Read）简称为RR和读已提交（Read Commited）RC

    1.在RR隔离级别下，存在间隙锁，导致出现死锁的几率比RC大的多。（RC也会出现死锁，但是出现的概率比RR低）

    2.在RR隔离级别下，条件列未命中索引会锁表！而在RC隔离级别下，只锁行

    3.在RC隔离级别下，半一致性读（semi-consistent）特性增加了update操作的并发性

    所以项目中会默认使用读已提交（Read Committed) 这个隔离级别，那么这个不可重复读问题怎么办勒，可以接受，毕竟都是真实的数据，此时binlog是row格式，基于行的复制

4.持久性

事务提交成功，就持久化到磁盘了。

引用自：

http://blog.itpub.net/26736162/viewspace-2141490/
https://www.cnblogs.com/shoshana-kong/p/10516404.html