数据库锁机制实现隔离

古城微笑少年丶 2022-05-28 07:44 151阅读 0赞

面对高并发加锁可以从两种层面来考虑：

*  第一种是代码层面的锁如（jvm中的syncrinized，jdk中的lock锁，redis的分布式锁）
 *  第二种是数据库层面的锁如：(乐观锁和悲观锁)
 *  当然除了用加锁的方式也可以用其他方式解决如（使用缓存，横向扩展机器，分布式，加内存等等）

下面介绍：乐观锁、悲观锁（共享锁S和排他锁X）区别

**1.乐观锁**

*  不是数据库自带的，需要我们自己去实现。乐观锁是指操作数据库时(更新操作)，想法很乐观，认为这次的操作不会导致冲突，在操作数据时，并不进行任何其他的特殊处理（也就是不加锁），而在进行更新后，再去判断是否有冲突了。

--------------------

*   乐观锁，大多是基于数据版本 （Version ）记录机制实现。何谓数据版本？
 *          即为数据增加一个版本标识，在基于数据库表的版本解决方案中，一般是通过为数据库表增加一个 “version” 字段来实现。 读取出数据时，将此版本号一同读出，之后更新时，对此版本号加一。此时，将提交数据的版本数据与数据库表对应记录的当前版本信息进行比对，如果提交的数据版本号大于数据库表当前版本号，则予以更新，否则认为是过期数据。
 *          对于上面修改用户帐户信息的例子而言，假设数据库中帐户信息表中有一个 version 字段，当前值为 1 ；而当前帐户余额字段（ balance ）为 $100 。
    
     *    1，操作员 A 此时将其读出（ version=1 ），并从其帐户余额中扣除 $50（ $100-$50 ）。 
     *  2， 在操作员 A 操作的过程中，操作员 B 也读入此用户信息（ version=1 ），并 从其帐户余额中扣除 $20 （ $100-$20 ）。 
     *  3 ，操作员 A 完成了修改工作，将数据版本号加一（ version=2 ），连同帐户扣除后余额（ balance=$50 ），提交至数据库更新，此时由于提交数据版本大于数据库记录当前版本，数据被更新，数据库记录 version 更新为 2 。 
     *  4 ，操作员 B 完成了操作，也将版本号加一（ version=2 ）试图向数据库提交数据（ balance=$80 ），但此时比对数据库记录版本时发现，操作员B提交的数据版本号为 2 ，数据库记录当前版本也为 2 ，不满足 “ 提交版本必须大于记录当前版本才能执行更新 “ 的乐观锁策略。因此，操作员 B 的提交被驳回。 这样，就避免了操作员 B 用基于version=1 的旧数据修改的结果覆盖操作员 A 的操作结果的可能。 
 *          从上面的例子可以看出，乐观锁机制避免了长事务中的数据库加锁开销（操作员 A和操作员 B 操作过程中，都没有对数据库数据加锁），大大提升了大并发量下的系统整体性能表现。 需要注意的是，乐观锁机制往往基于系统中的数据存储逻辑，因此也具备一定的局限性。

--------------------

**2.悲观锁**

*  悲观锁的实现，往往依靠数据库提供的锁机制（也只有数据库层提供的锁机制才能真正保证数据访问的排他性。否则，即使在本系统中实现了加锁机制，也无法保证外部系统不会修改数据）。

--------------------

*  比较，因为乐观锁不是数据库自带的，需要程序层面来控制，所以它的弊端是不能控制外部系统对数据库数据的修改等操作但是效率较悲观所高，而悲观锁是在操作数据是就把数据库锁定即使外部系统也无法操作已锁定的数据所以安全性好但是效率较低
 *  悲观锁又可以分为：共享锁和排他锁，共享锁和排他锁中可以进行行级锁和表级锁

--------------------

**共享锁和排他锁：**

*  1.数据库能实现对数据操作的四种隔离级别的原理就是通过数据库自带的悲观锁来实现的（行级锁和表级锁），但是悲观锁又分为共享锁和排他锁

**共享锁（S锁）和排它锁（X锁）**

*  共享锁【S锁】
 *  又称读锁，若事务T对数据对象A加上S锁，则事务T可以读A但不能修改A，其他事务只能再对A加S锁，而不能加X锁，直到T释放A上的S锁。这保证了其他事务可以读A，但在T释放A上的S锁之前不能对A做任何修改。
 *  排他锁【X锁】
 *  又称写锁。若事务T对数据对象A加上X锁，事务T可以读A也可以修改A，其他事务不能再对A加任何锁，直到T释放A上的锁。这保证了其他事务在T释放A上的锁之前不能再读取和修改A。

**死锁的产生原理：**因为共享锁可以被多个事物同时施加所以才会产生死锁产生

*  举例：两个事物A和B，如果事物A对一个资源加上了共享锁，这时事物B也对该资源加上了共享锁，这时如果事物A想要修改该数据就必须对他加上排他锁，所有就必须等待事物B释放他自身的共享锁，同样，事物B也想要修改该资源也同样在等待者事物A释放他自身的共享锁，这样就会产生两个事物在互相的等待对方释放锁而产生死锁现象（这个例子只是产生死一种场景）

**避免死锁:**

*  其中最具有代表性的避免死锁算法是银行家算法。

**解除死锁:**

*  当发现有进程死锁后，便应立即把它从死锁状态中解脱出来，常采用的方法有：
 *  剥夺资源：从其它进程剥夺足够数量的资源给死锁进程，以解除死锁状态；
 *  撤消进程：可以直接撤消死锁进程或撤消代价最小的进程，直至有足够的资源可用，死锁状态.消除为止；所谓代价是指优先级、运行代价、进程的重要性和价值等。
 *  (4).使用较低的隔离级别。(注：使用较低的隔离级别（例如已提交读）比使用较高的隔离级别（例如可序列化）持有共享锁的时间更短，减少锁竞争)

事物的四种隔离级别

1、Read uncommitted：对数据进行行级加锁（行级锁）

2、Read committed ：对数据进行行级加锁（行级锁）

3、Repeated  Read ：对数据进行行级加锁（行级锁）

4、serializable：对数据进行表级加锁（表级锁）

由于程序只要对数据库数据进行操作，包括读取操作都是必须要先对操作的数据进行加锁之后才能操作，所以数据库的隔离级别机制原理就是通过对数据进行加不同的锁来操作的

不过我们需要注意的是一些锁的级别，mysql的MyiSAM存储引擎使用的是表所，Innodb默认使用行级锁,但是行级锁是基于索引的，如果一条sql语句用不到索引是不会使用行级锁的，会使用表级锁把整张表锁住，这点需要注意（这也是为什么数据库字段加索引会对数据操作效率高的一个因素），

还有就是行级锁别不是直接锁数据而是锁索引，索引分为主键索引和非主键索引两种，如果一条sql 语句操作了主键索引，Mysql 就会锁定这条主键索引；如果一条语句操作了非主键索引，MySQL会先锁定该非主键索引，再锁定相关的主键索引。  
InnoDB 行锁是通过给索引项加锁实现的，如果没有索引，InnoDB 会通过隐藏的聚簇索引来对记录加锁。也就是说：如果不通过索引条件检索数据，那么InnoDB将对表中所有数据加锁，实际效果跟表锁一样。因为没有了索引，找到某一条记录就得扫描全表，要扫描全表，就得锁定表。

例如：user表有主键索引id和name两个属性，那么

select  \*  from  id=xxx(使用到了索引所以只会对id为xxx的索引进行行级加锁)

select  \*  from name=xxx(没有使用到索引，会对整张user表加锁)

附：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM4NTQ1NzEz_size_16_color_FFFFFF_t_70][]

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM4NTQ1NzEz_size_16_color_FFFFFF_t_70 1][]

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM4NTQ1NzEz_size_16_color_FFFFFF_t_70]: /images/20220528/54b37904a4ca4910b14416a8bba4d10d.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM4NTQ1NzEz_size_16_color_FFFFFF_t_70 1]: /images/20220528/b5f71006ea3f4740a996455c9cd1eb31.png