乐观锁实现分布式锁

╰+攻爆jí腚メ 2023-07-24 09:24 48阅读 0赞

\*\*

## 乐观锁 ##

\*\*  
就是说特别乐观，比如说每次去吃饭的时候，都认为窗口没有人，只有到了吃饭的窗口才看有没有人，如果有人则去别的地方吃饭。就像系统认为数据的更新在大多数情况下是不会产生冲突的， 只在数据库更新操作的提交的时候才对数据作冲突检测。如果检测的结果出现了与预期数据不一致的情况，则返回失败的信息。

乐观锁在大多数是基于数据版本（version）的记录机制实现的。

为了更好的理解数据库乐观锁在实际项目中的使用，下面举一个典型的电商库存的例子。当用户进行购买的时候就会对库存进行操作（库存减1代表已经卖出了一件）。我们将这个库存模型用下面的一张表optimistic\_lock来表述，参考如下：

CREATE TABLE `optimistic_lock` (
      `id` bigint(20) NOT NULL AUTO_INCREMENT,
      `resource` int(11) NOT NULL COMMENT '锁定的资源',
      `version` int(11) NOT NULL COMMENT '版本信息',
      `created_time` datetime DEFAULT NULL COMMENT '创建时间',
      `updated_time` datetime DEFAULT NULL COMMENT '更新时间',
      `deleted_time` datetime DEFAULT NULL COMMENT '删除时间',
      PRIMARY KEY (`id`),
      UNIQUE KEY `uiq_idx_resource` (`resource`)
    ) ENGINE=InnoDB AUTO_INCREMENT=2 DEFAULT CHARSET=utf8mb4 COMMENT='数据库分布式锁表';

其中：id表示主键；resource表示具体操作的资源，在这里也就是特指库存；version表示版本号。

在使用乐观锁之前要确保表中有相应的数据，比如：

INSERT INTO `database1`.`optimistic_lock`(`id`, `resource`, `version`, `created_time`, `updated_time`, `deleted_time`) VALUES (1, 100, 1, '2020-04-10 22:05:52', '2020-04-10 22:05:52', '2020-04-10 22:05:52');

如果是单线程进行操作，数据库本身就能保证操作的正确性。主要步骤如下：

*  STEP1 - 获取资源：SELECT resource FROM optimistic\_lock WHERE id = 1
 *  STEP2 - 执行业务逻辑
 *  STEP3 - 更新资源：UPDATE optimistic\_lock SET resource = resource -1 WHERE  
    id = 1

然而大多数情况下是不会单线程的，要是单线程的话 ，公司岂不是要凉凉。比如两个以上的线程购买同一件商品，在数据库层实际操作的时候应该是库存（resource）减2，但是由于是高并发的情况，第一个线程执行之后（执行了STEP1、STEP2但是还没有完成STEP3），第二个线程在购买相同的商品（执行STEP1），此时查询出的库存并没有完成减1的动作，那么最终会导致2个线程购买的商品却出现库存只减1的情况。  
在引入了version字段之后，那么具体的操作就会演变成下面的内容：

*  STEP1 - 获取资源： SELECT resource, version FROM optimistic\_lock WHERE id  
    = 1
 *  STEP2 - 执行业务逻辑
 *  STEP3 - 更新资源：UPDATE optimistic\_lock SET resource = resource -1,  
    version = version + 1 WHERE id = 1 AND version = oldVersion  
    其实，借助更新时间戳（updated\_at）也可以实现乐观锁，和采用version字段的方式相似：更新操作执行前线获取记录当前的更新时间，在提交更新时，检测当前更新时间是否与更新开始时获取的更新时间戳相等。
 *  乐观锁的优点  
    检测数据冲突时不依赖数据库库本省的机制，所以不会影响请求的性能，当产生并发且并发量较小的时候只有少部分请求会失败。
 *  乐观锁的缺点  
    对表的设计增加额外的字段，增加了数据库的冗余，另外当并发量高的时候，version的值在频繁变化，则会导致大量请求失败，影响系统的可用性。  
    **综上所述，乐观锁比较适合并发量不高，并且写操作不频繁的场景**