MySql——锁 (3)

悲观锁总是假设最坏的情况，每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁，这样别人想拿这个数据就会阻塞直到它拿到锁（共享资源每次只给一个线程使用，其它线程阻塞，用完后再把资源转让给其它线程）。比如行锁，表锁等，读锁，写锁等，都是在做操作之前先上锁，当其他线程想要访问数据时，都需要阻塞挂起。Java中 synchronized 和 ReentrantLock 等独占锁就是悲观锁思想的实现。

举例：

秒杀案例1：

商品秒杀过程中，库存数量的减少，避免出现超卖的情况。比如，商品表中有一个字段为quantity表示当前该商品的库存量。假设商品为华为mate40，id为1001，quantity=100个。如果不使用锁的情况下，操作方法如下所示

# 1、查出商品库存
SELECT quantity from items WHERE id =1001;

#2、如果库存大于0，根据商品信息生成订单
insert into orders (item_id) values (1001);



#3、 修改商品库存，num 表示购买数量
update items set quantity=quantity -num where id =1001;

这样写的话，在并发量小的公司没有大的问题，但是如果在高并发环境下可能出现以下问题

其中线程B此时已经下单并且减完库存，这个时候线程A依然去执行step3，就造成了超卖.

我们使用悲观锁可以解决这个问题，商品信息从查询出来到修改，中间有一个生成订单的过程，使用悲观锁的原理就是，当我们在查询items信息后就把当前的数据锁定，直到我们修改完毕后再解锁。那么整个过程中，因为数据被锁定了，就不会出现有第三者来对其进行修改了。而这样做的前提是需要将要执行的SQL语句放在同一个事务中，否则达不到锁定数据行的目的。

# 1、查出商品库存 （获取独占锁）
SELECT quantity from items WHERE id =1001 FOR UPDATE;

#2、如果库存大于0，根据商品信息生成订单
insert into orders (item_id) values (1001);


#3、 修改商品库存，num 表示购买数量
update items set quantity=quantity -num where id =1001;

select .... for update 是MySQL中悲观锁。此时在items表中，id为1001的那条数据就被我们锁定了，其他的要执行select quantity from items where id = 1001 for update;语句的事务必须等本次事务提交之后才能执行。这样我们可以保证当前的数据不会被其它事务修改。

注意，当执行select quantity from items where id = 001 for update;语句之后，如果在其他事务中执行selectquantity from items where id = 1001; 语，并不会受第一个事务的影响，仍然可以正常查询出数据

注意: select ... for update语句执行过程中所有扫描的行都会被锁上，因此在MySQL中用悲观锁必须确定使用了索引，而不是全表扫描，否则将会把整个表锁住。

悲观锁不适用的场景较多，它存在一些不足，因为悲观锁大多数情况下依靠数据库的锁机制来实现，以保证程序的并发访问性，同时这样对数据库性能开销影响也很大，特别是长事务而言，这样的开销往往无法承受，这时就需要乐观锁。

2. 乐观锁（Optimistic Locking）

乐观锁认为对同一数据的并发操作不会总发生，属于小概率事件，不用每次都对数据上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这个数据，也就是不采用数据库自身的锁机制，而是通过程序来实现。在程序上，我们可以采用版本号机制或者 CAS机制实现。乐观锁适用于多读的应用类型，这样可以提高吞吐量。在Java中 java.util.concurrent.atomic 包下的原子变量类就是使用了乐观锁

的一种实现方式：CAS实现的。

1. 乐观锁的版本号机制

在表中设计一个版本字段 version ，第一次读的时候，会获取 version 字段的取值。然后对数据进行更新或删除操作时，会执行 UPDATE ... SET version=version+1 WHERE version=version 。此时如果已经有事务对这条数据进行了更改，修改就不会成功。

2. 乐观锁的时间戳机制

时间戳和版本号机制一样，也是在更新提交的时候，将当前数据的时间戳和更新之前取得的时间戳进行比较，如果两者一致则更新成功，否则就是版本冲突。你能看到乐观锁就是程序员自己控制数据并发操作的权限，基本是通过给数据行增加一个戳（版本号或者时间戳），从而证明当前拿到的数据是否最新。

举例2

秒杀案例 2

#1、查出商品库存
select quantity from items where id = 1001;

#2、如果库存大于0，则根据商品信息生成订单
insert into orders (item_id) values(1001);

#3、修改商品库存，num表示购买数量

update items set quantity = quantity-num,version = version+1 where id = 1001 and version = #{version};

注意，如果数据表是读写分离的表，当matser表中写入的数据没有及时同步到slave表中时，会造成更新一直失效的问题。此时需要强制读取master表中的数据(即将select语句放到事务中即可，这时候查询的就是master主库了。)
如果我们对同一条数据进行频繁的修改的话，那么就会出现这么一种场景，每次修改都只有一个事务能更新成功，在业务感知上面就有大量的失败操作。我们把代码修改如下:

#第1步: 查出商品库存
select quantity from items where id = 1001;

#第2步: 如果库存大于，则根据商品信息生产订单
insert into orders (item_id) values(1001);

#第3步: 修改商品的库存，num表示购买数量
update items set quantity = quantity-num where id = 1001 and quantity-num>0;

这样就会使每次修改都能成功，而且不会出现超卖的现象。

3、两种锁使适用场景

从这两种锁的设计思想中，我们总结一下乐观锁和悲观锁的适用场景：

1. 乐观锁适合读操作多的场景，相对来说写的操作比较少。它的优点在于程序实现，不存在死锁问题，不过适用场景也会相对乐观，因为它阻止不了除了程序以外的数据库操作。

2. 悲观锁适合写操作多的场景，因为写的操作具有排它性。采用悲观锁的方式，可以在数据库层面阻止其他事务对该数据的操作权限，防止 读 - 写 和 写 - 写 的冲突。

3、按照加锁的方式进行划分：显示锁、隐式锁

1、隐式锁

一个事务在执行 INSERT 操作时，如果即将插入的间已经被其他事务加了 gap锁，那么本次 INSERT 操作会阻塞，并且当前事务会在该间隙上加一个向插入意锁，否则一般情况下 INSERT 操作是不加锁的。那如果一个事务首先插入了一条记录(此时并没有在内存生产与该记录关联的锁结构)，然后另一个事务:

立即使用 SELECT ...LOCK IN SHARE MODE 语读取这条记录，也就是要获取这条记录的 S锁，或者使用SELECT ... FOR UPDATE 语读取这条记录，也就是要获取这条记录的 X锁，怎么办?如果允许这种情况的发生，那么可能产生脏读问题。
立即修改这条记录，也就是要获取这条记录的 X锁，怎么办?如果允许这种情况的发生，那么可能产生脏写问题。

这时候我们前边提过的事务id 又要起作用了。我们把聚族索引和二级索引中的记录分开看一下:

情景一：对于聚簇索引记录来说，有一个 trx_id 隐藏列，该隐藏列记录着最后改动该记录的事务 id 。那么如果在当前事务中新插入一条聚簇索引记录后，该记录的 trx_id 隐藏列代表的的就是当前事务的事务id ，如果其他事务此时想对该记录添加 S锁或者 X锁时，首先会看一下该记录的 trx_id 隐藏列代表的事务是否是当前的活跃事务，如果是的话，那么就帮助当前事务创建一个 X 锁（也就是为当前事务创建一个锁结构， is_waiting 属性是 false ），然后自己进入等待状态（也就是为自己也创建一个锁结构， is_waiting 属性是 true ）。

情景二：对于二级索引记录来说，本身并没有 trx_id 隐藏列，但是在二级索引页面的 Page Header 部分有一个 PAGE_MAX_TRX_ID 属性，该属性代表对该页面做改动的最大的事务id ，如果 PAGE_MAX_TRX_ID 属性值小于当前最小的活跃事务id ，那么说明对该页面做修改的事务都已经提交了，否则就需要在页面中定位到对应的二级索引记录，然后回表找到它对应的聚簇索引记录，然后再重复情景一的做法。

即:一个事务对新插入的记录可以不显式的加锁(生成一个锁结构)，但是由于事务id 的存在，相当于加了一个隐式锁。别的事务在对这条记录加 S锁或者X锁时，由于隐式锁的存在，会先帮助当前事务生成一个锁结构，然后自己再生成一个锁结构后进入等待状态。隐式锁是一种延迟加锁的机制，从而来减少加锁的数量。
隐式锁在实际内存对象中并不含有这个锁信息。只有当产生锁等待时,隐式锁转化为显式锁。

lnnoDB 的 inset 操作，对插入的记录不加锁，但是此时如果另一个线程进行当前读，类似以下的用例，session 2会锁等待 session 1，那么这是如何实现的呢?

隐式锁的逻辑过程如下：

A. InnoDB的每条记录中都一个隐含的trx_id字段，这个字段存在于聚簇索引的B+Tree中。

B. 在操作一条记录前，首先根据记录中的trx_id检查该事务是否是活动的事务(未提交或回滚)。如果是活动的事务，首先将隐式锁转换为显式锁 (就是为该事务添加一个锁)。

C. 检查是否有锁冲突，如果有冲突，创建锁，并设置为waiting状态。如果没有冲突不加锁，跳到E。

D. 等待加锁成功，被唤醒，或者超时。

E. 写数据，并将自己的trx_id写入trx_id字段。

2、显示锁

通过特定的语句进行加锁，我们一般称之为显示加锁，

例如：显示加共享锁

select .... lock in share mode

显示加排它锁：

select .... for update

4、其他锁之：全局锁、死锁

1、全局锁

全局锁就是对整个数据库实例加锁。当你需要让整个库处于 只读状态 的时候，可以使用这个命令，之后其他线程的以下语句会被阻塞：数据更新语句（数据的增删改）、数据定义语句（包括建表、修改表结构等）和更新类事务的提交语句。全局锁的典型使用场景是：做全库逻辑备份。

全局锁的命令：

Flush tables with read lock

2、死锁

1、简介

死锁是指两个或多个事务在同一资源上相互占用，并请求锁定对方占用的资源，从而导致恶性循环。死锁示例：

这时候，事务1在等待事务2释放id=2的行锁，而事务2在等待事务1释放id=1的行锁。事务1和事务2在互相等待对方的资源释放，就是进入了死锁状态。当出现死锁以后，有两种策略：

一种策略是，直接进入等待，直到超时。这个超时时间可以通过参数 innodb_lock_wait_timeout 来设置。

另一种策略是，发起死锁检测，发现死锁后，主动回滚死锁链条中的某一个事务（将持有最少行级排他锁的事务进行回滚），让其他事务得以继续执行。将参数 innodb_deadlock_detect 设置为 on，表示开启这个逻辑。

2、产生死锁的四个必要条件

1、两个或两个以上的事务

2、每个事务都已经持有锁，并申请新的锁 (请求并保持)

3、锁的资同时只能被一个事务持有或者不兼容（互斥）

4、事务之间因为持有锁和申请锁导致彼此等待（循环等待）（非抢占）

死锁关键问题就在于两个或两个以上的Seesion 加锁顺序不一致

3、如何处理死锁

方式1: 等待，直到超时 (innodb_lock_wait_timeout=50s)
即当两个事务互相等待时，当一个事务等待时间超过设置的闯值时，就将其回滚，另外事务继续进行。这种方法简单有效，在innodb中，参数 innodb_lock_wait_timeout 用来设置超时时间。
缺点:对于在线服务来说，这个等待时间往往是无法接受的。
那将此值修改短一些，比如1s，0.1s是否合适? 不合适，容易误伤到普通的锁等待。

方式2:使用死锁检测进行死锁处理
方式1检测死锁太过被动，innodb还提供了 wait-for graph算法来主动进行死锁检测，每当加锁请求无法立即满足需要并进入等待时，wait-for graph算法都会被触发。
这是一种较为 主动的死锁检测机制 ，要求数据库保存 锁的信息链表 和 事务等待链表 两部分信息。

绘制等待图：

死锁检测的原理是构建一个以事务为顶点，锁为边的有向图，，判断有向图是否存在环，存在即有死锁

一旦检测到回路、有死锁，这时候InnoDB存储引擎会选择回滚undo量最小的事务，让其他事务继续执行(innodb_deadlock-detect=on 表示开启这个逻辑) 。
缺点:每个新的被阻塞的线程，都要判断是不是由于自己的加入导致了死锁，这个操作时间复杂度是o(n)。如果100个并发线程同时更新同一行，意味着要检测100*100 = 1万次，1万个线程就会有1千万次检测。

如何解决?
。方式1: 关闭死锁检测，但意味着可能会出现大量的超时，会导致业务有损。
。方式2: 控制并发访问的数量。比如在中间件中实现对于相同行的更新，在进入引擎之前排队，这样在InnoDB内部就不会有大量的死锁检测工作。

进一步的思路:
可以考虑通过将一行改成逻辑上的多行来减少锁冲突。比如，连锁超市账户总额的记录，可以考虑放到多条记录上。账户总额等于这多个记录的值的总和。