数据库事务深入学习

为什么要有隔离级别

对于同时运行的多个事务, 当这些事务访问数据库中相同的数据时, 如果没有采取必要的隔离机制, 就会导致各种并发问题:  

脏读： 对于两个事物 T1 , T2,  T1 读取了已经被 T2  更新但还没有被提交的字段 ，若T2回滚，T1读取的内容就是临时且无效的。

不可重复读：对于两个事物 T1, T2, T1读取了一个字段，然后T2 更新了该字段。之后，T1再次读取同一个字段，值就不同了。

幻读： 对于两个事物 T1, T2 ,T1 从一个表中读取了一个字段，然后T2 在该标中插入了一些新的行。之后， T1再次对表进行读取，就会多出几行

事务的隔离级别（4种）

为了避免上诉的问题

ANSI 99定义了4种事务隔离级别，SQL Server 2005能够完全支持这些级别：

• 未提交读 在读数据时不会检查或使用任何锁。因此，在这种隔离级别中可能读取到没有提交的数据。
• 已提交读 只读取提交的数据并等待其他事务释放排他锁。读数据的共享锁在读操作完成后立即释放。已提交读是SQL Server的默认隔离级别。
• 可重复读 像已提交读级别那样读数据，但会保持共享锁直到事务结束。

• 可序列化 工作方式类似于可重复读。但它不仅会锁定受影响的数据，还会锁定这个范围。这就阻止了新数据插入查询所涉及的范围，这种情况可以导致幻像读。

事务的ACID

• 原子性：一个事务要么同时成功，要么同时失败。（记录undo日志回滚到之前的版本）

• 一致性：保证能看到系统内的所有更改。Can(happen before)(加了锁) 

  
  

• 隔离性：以性能为理由，对一致性的破坏。（如果都用排它锁，就可以保证一致性，但性能差。因此提出隔离级别，提高性能，无法避免地破坏了一致性）

  序列化读写（排它锁）

  读写锁

  1. 可重复读，读锁不能被写锁升级，只能做到读读可并行

  2. 读已提交，读读并行，读写并行

  3. 读未提交，只加写锁，读不加锁。读读并行，读写并行，写读并行。有可能读到写过程中的数据

• 持久性：事务完成以后，该事务对数据库所作的更改便持久地保存在数据库之中

  RAID的持久性

  1.将一个数据写到多个磁盘上（防止磁盘损坏导致数据丢失）

  2.每一次请求都要刷磁盘性能过低怎么办？

  2.1直接写入内存  优点是IOPS高 缺点是可能会丢失数据

  2.2Group commit（打包成块后一起发送到块存储） 优点是保证系统的持久性和吞吐量 缺点是会使请求延迟提升

隔离性扩展:快照隔离级别（MVCC/SNAPSHOT ISOLATION）

快照隔离级别(MVCC/SNAPSHOT ISOLATION)：针对读多写少场景优化，并行度能达到或超过读未提交，而隔离级别很高

核心思路： Copy on write，无锁编程。

单机事务的典型异常应对策略

• 如何回滚
• 系统down机恢复（已提交事务继续提交，未提交事务回滚）

事务的调优原则

1. 在不影响业务应用的前提下，减少锁的覆盖范围

   Myisam表锁－>Innodb行锁

   原位锁－> MVCC多版本

   
   

2. 在不影响业务应用的前提下，增加锁上可并行的线程数

   读锁写锁分离、允许并行读取数据

   
   

   
   

3. 在不影响业务应用的前提下，选择正确锁类型

   悲观锁 使线程到blocking状态，通知信息ok的状态切换回等待状态（频繁地换入换出，可能会增加系统的开销）。适合并发争抢比较严重的场景

   乐观锁 适合并发争抢不严重的场景

分布式事务

• 目标：像传统单机事务一样的操作方式，可按需无限扩展

    if 分布式事务＝单机事务＋无限扩展

    then 单机事务＝不存在

• 网络带来的（去中心化）

理论上无限的扩展能力

  理论上无限的数据安全性

  理论上无限的服务可用性

• 网络失去的

      确定性丧失

             超时到底是成功还是失败

             共享数据困难

             共享数据会导致系统有瓶颈

             更多的延迟

            光速并不是无限的
            并发编程难度上升