MySQL中的乐观锁和悲观锁具体怎么实现的?

 文章介绍

对于MySQL中的乐观锁和悲观锁,可能不少的开发者还不是很熟悉,并不知道其中具体是如何实现的。本文就针对这个问题作一个实际案例演示,让你完全明白这两种锁的区别。mysql

相关文章

以前针对MySQL中的锁单独分享过一篇文章,对于MySQL锁还不够了解的能够仔细阅读如下该文。sql

锁分类

MySQL的中锁按照范围主要分为表锁、行锁和页面锁。其中myisam存储引擎只支持表锁,InnoDB不只仅支持行锁,在必定程度上也支持表锁。按照行为能够分为共享锁(读锁)、排他锁(写锁)和意向锁。按照思想分为乐观锁和悲观锁。并发

今天的文章演示一下实际中的乐观锁和悲观锁是如何操做的。ide

表结构

下面的SQL语句是表的结构。性能

CREATE TABLE `demo`.`user`  (
  `id` int(10) UNSIGNED ZEROFILL NOT NULL AUTO_INCREMENT,
  `name` varchar(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci NOT NULL,
  `sex` tinyint(1) UNSIGNED NOT NULL DEFAULT 0,
  `email` varchar(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci NULL DEFAULT NULL,
  `mobile` varchar(20) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci NULL DEFAULT NULL,
  `version` int(1) NULL DEFAULT 1 COMMENT '数据版本号',
  PRIMARY KEY (`id`) USING BTREE
) ENGINE = InnoDB AUTO_INCREMENT = 8 CHARACTER SET = utf8mb4 COLLATE = utf8mb4_unicode_ci ROW_FORMAT = Dynamic;

插入模拟数据spa

BEGIN;
INSERT INTO `user` VALUES (0000000001, '张三', 0, '18228937997@163.com', '18228937997', 1);
INSERT INTO `user` VALUES (0000000002, '李四', 0, '1005349393@163.com', '15683202302', 1);
INSERT INTO `user` VALUES (0000000003, '李四1', 0, '1005349393@163.com', '15683202302', 1);
INSERT INTO `user` VALUES (0000000004, '李四2', 0, '1005349393@163.com', '15683202302', 1);
INSERT INTO `user` VALUES (0000000005, '李四3', 0, '1005349393@163.com', '15683202302', 1);
INSERT INTO `user` VALUES (0000000006, '李四4', 0, '1005349393@163.com', '15683202302', 1);
INSERT INTO `user` VALUES (0000000007, '李四55', 0, '1005349393@163.com', '15683202302', 1);
COMMIT;

表中数据。code

mysql root@127.0.0.1:demo> select * from user;
+----+--------+-----+---------------------+-------------+---------+
| id | name   | sex | email               | mobile      | version |
+----+--------+-----+---------------------+-------------+---------+
| 1  | 张三   | 0   | 18228937997@163.com | 18228937997 | 2       |
| 2  | 李四   | 0   | 1005349393@163.com  | 15683202302 | 1       |
| 3  | 李四1  | 0   | 1005349393@163.com  | 15683202302 | 1       |
| 4  | 李四2  | 0   | 1005349393@163.com  | 15683202302 | 1       |
| 5  | 李四3  | 0   | 1005349393@163.com  | 15683202302 | 1       |
| 6  | 李四4  | 0   | 1005349393@163.com  | 15683202302 | 1       |
| 7  | 李四55 | 0   | 1005349393@163.com  | 15683202302 | 1       |
+----+--------+-----+---------------------+-------------+---------+
7 rows in set
Time: 0.011s

悲观锁

悲观锁,比较消极的一种锁处理方式。直接在操做数据时,抢占锁。其余的事务在进行时就会等待,直到占有锁的事务释放锁为止。blog

这种处理方式能保证数据的最大一致性,可是容易致使锁超时、并发程度低等问题。 首先咱们开启事务一,而且对id=1的数据进行update操做,此时咱们不提交事务。事务

mysql root@127.0.0.1:demo> begin;
Query OK, 0 rows affected
Time: 0.002s
mysql root@127.0.0.1:demo> update `user` set  name = '张三111111'where id = 1;
Query OK, 1 row affected
Time: 0.004s

接着咱们开启事务二,对id=1的数据进行update操做,查看此时会发生什么状况?ci

mysql root@127.0.0.1:demo> begin;
Query OK, 0 rows affected
Time: 0.002s
mysql root@127.0.0.1:demo> update `user` set  sex = 1 where id = 1;

咱们执行完update语句以后,就处于等待状态,SQL语句也不会立刻被执行,这是由于事务一没有commit,也就没有释放id=1的数据对应的写锁。效果以下图:

watermark,size_14,text_QDUxQ1RP5Y2a5a6i,color_FFFFFF,t_100,g_se,x_10,y_10,shadow_20,type_ZmFuZ3poZW5naGVpdGk=

经过上面的例子,咱们就能比较直观的感觉到悲观锁的实现过程是如何的。

乐观锁

乐观锁认为数据通常状况下不会形成冲突,只有当数据去执行修改状况时,才会针对数据冲突作处理。这里是如何发现冲突了呢?常规的方式,都是在数据行上加一个版本号或者时间戳等字段。(本文使用version做为版本好方式,使用时间戳方式同理)

乐观锁的实现原理:

  1. 一个事务在读取数据时,将对应的版本号字段读取出来,假设此时的版本号是1。

  2. 另一个事务也是执行一样的读取操做。当事务一提交时,对版本号执行+1,此时该数据行的版本号就是2。

  3. 第二个事务执行修改操做时,针对业务数据作条件,并默认增长一个版本号做为where条件。此时修改语句中的版本号字段是不知足where条件,该事务执行失败。经过这种方式来达到锁的功能。

watermark,size_14,text_QDUxQ1RP5Y2a5a6i,color_FFFFFF,t_100,g_se,x_10,y_10,shadow_20,type_ZmFuZ3poZW5naGVpdGk=

客户端一

mysql root@127.0.0.1:demo> select * from user where id = 1;
+----+------------+-----+---------------------+-------------+---------+
| id | name       | sex | email               | mobile      | version |
+----+------------+-----+---------------------+-------------+---------+
| 1  | 张三111111 | 0   | 18228937997@163.com | 18228937997 | 1       |
+----+------------+-----+---------------------+-------------+---------+
1 row in set
Time: 0.012s
mysql root@127.0.0.1:demo> update `user` set  name = '事务一', version = version + 1  where id = 1 and version = 1;
Query OK, 1 row affected
Time: 0.008s
mysql root@127.0.0.1:demo> select * from user where id = 1;
+----+--------+-----+---------------------+-------------+---------+
| id | name   | sex | email               | mobile      | version |
+----+--------+-----+---------------------+-------------+---------+
| 1  | 事务一 | 1   | 18228937997@163.com | 18228937997  |  2      |
+----+--------+-----+---------------------+-------------+---------+
1 row in set
Time: 0.009s

执行update语句的顺序应该在客户端二执行了select以后,在执行。

客户端二

mysql root@127.0.0.1:demo> select * from user where id = 1;
+----+------------+-----+---------------------+-------------+---------+
| id | name       | sex | email               | mobile      | version |
+----+------------+-----+---------------------+-------------+---------+
| 1  | 张三111111 | 1   | 18228937997@163.com | 18228937997 | 1       |
+----+------------+-----+---------------------+-------------+---------+
1 row in set
Time: 0.015s
mysql root@127.0.0.1:demo> update `user` set  name = '事务二', version = version + 1  where id = 1 and version = 1;
Query OK, 0 rows affected
Time: 0.003s
mysql root@127.0.0.1:demo> select * from user where id = 1;
+----+--------+-----+---------------------+-------------+---------+
| id | name   | sex | email               | mobile      | version |
+----+--------+-----+---------------------+-------------+---------+
| 1  | 事务一 | 1   | 18228937997@163.com | 18228937997 | 2       |
+----+--------+-----+---------------------+-------------+---------+
1 row in set
Time: 0.012s

此时根据update返回的结构,能够看出受影响的行数为0,同时select查询以后,返现数据也是事务一的数据。

适用场景

悲观锁:比较适合写入操做比较频繁的场景,若是出现大量的读取操做,每次读取的时候都会进行加锁,这样会增长大量的锁的开销,下降了系统的吞吐量。

乐观锁:比较适合读取操做比较频繁的场景,若是出现大量的写入操做,数据发生冲突的可能性就会增大,为了保证数据的一致性,应用层须要不断的从新获取数据,这样会增长大量的查询操做,下降了系统的吞吐量。

总结

两种所各有优缺点,读取频繁使用乐观锁,写入频繁使用悲观锁。

像乐观锁适用于写比较少的状况下,即冲突真的不多发生的时候,这样能够省去了锁的开销,加大了系统的整个吞吐量。但若是常常产生冲突,上层应用会不断的进行retry,这样反却是下降了性能,因此这种状况下用悲观锁就比较合适,之因此用悲观锁就是由于两个用户更新同一条数据的几率高,也就是冲突比较严重的状况下,因此才用悲观锁。

悲观锁比较适合强一致性的场景,但效率比较低,特别是读的并发低。乐观锁则适用于读多写少,并发冲突少的场景。

 

相关文章
相关标签/搜索