事务会出现哪些并发性问题？解决，事务的隔离级别（面试题）

事务概述

首先，提出两个问题，然后带着问题讨论事务相关的知识点，最后来解决这两个问题并回答前文的问题。

第一个问题，事务是否可以并发?

第二个问题，数据库是怎么隔离事务的？

事务的表现特性

数据库中执行事务涉及到很多方面，包括如何处理临界资源，如何加锁解锁等等。但是无论事务如何执行，都需要保证以下几个特性：
原子性（Atomic）：事务包含的所有操作，要么全做，要么全不做回滚；
一致性（Consistency）：从一个一致状态到另一个一致状态；eg：A、B之间转账，两者的金额总和转账前后必须相同。
隔离性（Isolation）：多个事务并发执行时，不会相互影响。
持久性（Durability）：一个事务一旦修改，它对数据库的修改应该永久存在数据库中。

数据库的各种锁

1. 共享锁

共享锁用于非独占的业务，允许多个事务同时读取锁定的资源，但是不允许资源被更新。

加锁时机：执行select语句时默认会被加上
解锁时机：执行完读取后默认解除
与其他锁兼容性：数据上被设置了共享锁，则不会允许再增加共享锁和独占锁
并发性能：具有良好的并发性能

2. 排他锁

排他锁，也叫独占锁。顾名思义，被排他锁锁定的资源不会允许其他事务进行任何操作。

加锁时机：执行insert,update,delete时默认会被加上
解锁时机：事务结束才能解除
兼容性：如果数据上有其他锁，不能增加独占锁；同样独占锁存在时也不会允许增加其他锁
并发性能：其他事务必须等待前一个事务结束后才能执行，不能并发，只能串行

3. 更新锁

在更新的初始阶段用于锁定所需要的资源，防止在读取阶段使用共享锁造成死锁。

加锁时机：执行update时，使用更新锁锁定相关资源
解锁时机：读取完毕，执行更新操作时，更新锁升级为独占锁
兼容性：更新锁与共享锁兼容，即可以同时存在更新锁和共享锁，但只能有一个更新锁
并发性能：更新初期的读取阶段可以允许其他事务读取资源，允许有限的并发；后期对资源进行独占时不允许并发。

事务隔离级别

通用的事务隔离级别有四种，SQL Server还有另外扩展出来的级别，在此不多介绍。

1.Serializable(串行化)

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

2.Repeatable Read(可重复读)

像已提交读级别那样读数据，但会保持共享锁直到事务结束。

3.Read Commit

只读取提交的数据并等待其他事务释放排他锁。读数据的共享锁在读操作完成后立即释放。已提交读是SQL Server的默认隔离级别。

4.Read Uncommited

在读数据时不会检查或使用任何锁。因此，在这种隔离级别中可能读取到没有提交的数据。

回答前文的问题
第一个问题，事务是否可以并发?

答案是肯定的，数据库中为了提高性能，允许同时进行多个事务操作，这个事务跟发起方式无关，使用存储过程发起，或者使用代码发起，又或者使用普通的SQL语句发起并没有什么区别。


并发访问问题----由隔离性引起
如果不考虑隔离性，事务存在3中并发访问问题。

1）脏读：B事务读取到了A事务尚未提交的数据 ------ 要求B事务要读取A事 务提交的数据

2）不可重复读：一个事务中 两次读取的数据的内容不一致 ----- 要求的是一个事 务中多次读取时数据是一致的 — unpdate

3）幻读/虚读：一个事务中 两次读取的数据的数量不一致 ----- 要求在一个事务多 次读取的数据的数量是一致的 --insert delete

第二个问题，数据库是怎么隔离事务的？

要回答这个问题，先要理解数据库中的锁机制和数据库事务隔离级别。数据库中的锁可以分为三种类型：共享锁、独占锁和更新锁。使用不同级别的锁并配合不同的锁定范围已达到不同的事务隔离级别并在此基础上并发或串行执行事务。


事务的隔离级别
1）read uncommitted : 读取尚未提交的数据 ：哪个问题都不能解决
2）read committed：读取已经提交的数据 ：可以解决脏读 ---- oracle默认的
3）repeatable read：重读读取：可以解决脏读 和 不可重复读 —mysql默认的
4）serializable：串行化：可以解决 脏读 不可重复读 和 虚读—相当于锁表

第三个问题，**为什么本文开头的事务会存在并发问题？**

因为事务的开始执行的是select，select使用的是共享锁，有可能并发的事务在同一时间执行select导致同时认为自己都是合法操作，而排队执行后续的事务。结果导致了实际上就有可能插入重复的数据，比如只剩下一个商品，却创建了两个销售订单。

如何防止并发问题

在事务中

根据前文所讲，使用insert,update或delete可以在默认事务级别人为造成事务串行化，因此可以在事务内部一开始都使用update更新一条公共的数据，这样的话同类型的事务都会串行化，然后再增加一个判断语句，用于判断后续的事务内容是否应该执行。这样足以确保所有的操作都按照合理合法，唯一的缺点是可能造成性能问题。

在事务外

现在分布式的系统越来越多，但是再分布的系统也会有些共享资源，比如redis或zookeeper，可以利用redis或者zookeeper造一些分布式的锁（此类属于其他博文内容，在此不再展开）。利用事务外部的锁将同类型的事务做一些串行化处理，再配合事务内部的检查机制，足以确保解决事务的并发问题。

数据库并发事务存在的问题（脏读、不可重复读、幻读等）

一个数据库可能拥有多个访问客户端，这些客户端并发访问数据库时，若没有采取必要的隔离措施，存在以下问题，这些问题分为5类，包括3类数据读问题：脏读、不可重复读和幻读。两类数据更新问题：第一类丢失更新、第二类丢失更新
连接：https://blog.csdn.net/starlh35/article/details/76445267
https://blog.csdn.net/a911711054/article/details/77916526