乐趣区

分布式锁4基于Mysql实现

分布式锁(4)- 基于 Mysql 实现

1. 使用场景

在分布式系统里,我们有时执行定时任务,或者处理某些并发请求,需要确保多点系统里同时只有一个执行线程进行处理。

分布式锁就是在分布式系统里互斥访问资源的解决方案。

通常我们会更多地使用 Redis 分布式锁、Zookeeper 分布式锁的解决方案。

本篇文章介绍的是基于 MySQL 实现的分布式锁方案,性能上肯定是不如 Redis、Zookeeper

所以,基于 Mysql 实现分布式锁,适用于 对性能要求不高,并且不希望因为要使用分布式锁而引入新组件

2. 基于唯一索引(insert)实现

2.1 实现方式

  • 获取锁时在数据库中 insert 一条数据,包括 id、方法名(唯一索引)、线程名(用于重入)、重入计数
  • 获取锁如果成功则返回 true
  • 获取锁的动作放在 while 循环中,周期性尝试获取锁直到结束或者可以定义方法来限定时间内获取锁
  • 释放锁的时候,delete 对应的数据

2.2 优点:

  • 实现简单、易于理解

2.3 缺点

  • 没有线程唤醒,获取失败就被丢掉了;
  • 没有超时保护,一旦解锁操作失败,就会导致锁记录一直在数据库中,其他线程无法再获得到锁;
  • 这把锁强依赖数据库的可用性,数据库是一个单点,一旦数据库挂掉,会导致业务系统不可用;
  • 并发量大的时候请求量大,获取锁的间隔,如果较小会给系统和数据库造成压力;
  • 这把锁只能是非阻塞的,因为数据的 insert 操作,一旦插入失败就会直接报错,没有获得锁的线程并不会进入排队队列,要想再次获得锁就要再次触发获得锁操作;
  • 这把锁是非重入的,同一个线程在没有释放锁之前无法再次获得该锁,因为数据中数据已经存在了;
  • 这把锁是非公平锁,所有等待锁的线程凭运气去争夺锁。

2.4 简单实现方案

新建一张表,用于存储锁的信息,需要加锁的时候就插入一条记录,释放锁的时候就删除这条记录

新建一张最简单的表

CREATE TABLE `t_lock` (`lock_key` varchar(64) NOT NULL COMMENT '锁的标识',
  PRIMARY KEY (`lock_key`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='分布式锁'

根据插入 sql 返回受影响的行数,大于 0 表示成功占有锁

insert ignore into t_lock(lock_key) values(:lockKey)

释放锁的时候就删除记录

delete from t_lock where lock_key = :lockKey

2.5 完善实现方案

上面这种简单的实现有以下几个问题:

  • 这把锁强依赖数据库的可用性,数据库是一个单点,一旦数据库挂掉,会导致业务系统不可用。
  • 这把锁没有失效时间,一旦解锁操作失败,就会导致锁记录一直在数据库中,其他线程无法再获得到锁。
  • 这把锁只能是非阻塞的,因为数据的 insert 操作,一旦插入失败就会直接报错。没有获得锁的线程并不会进入排队队列,要想再次获得锁就要再次触发获得锁操作。
  • 这把锁是非重入的,同一个线程在没有释放锁之前无法再次获得该锁。因为数据中数据已经存在了。

当然,我们也可以有其他方式解决上面的问题。

  • 数据库是单点?搞两个数据库,数据之前双向同步。一旦挂掉快速切换到备库上。
  • 没有失效时间?只要做一个定时任务,每隔一定时间把数据库中的超时数据清理一遍。
  • 非阻塞的?搞一个 while 循环,直到 insert 成功再返回成功。
  • 非重入的?在数据库表中加个字段,记录当前获得锁的机器的主机信息和线程信息,那么下次再获取锁的时候先查询数据库,如果当前机器的主机信息和线程信息在数据库可以查到的话,直接把锁分配给他就可以了。

3. 基于排他锁(for update)实现

3.1 实现方式

  • 获取锁可以通过,在 select 语句后增加for update,数据库会在查询过程中给数据库表增加排他锁。当某条记录被加上排他锁之后,其他线程无法再在该行记录上增加排他锁,我们可以认为获得排它锁的线程即可获得分布式锁;
  • 其余实现与使用唯一索引相同;
  • 释放锁通过 connection.commit(); 操作,提交事务来实现。

3.2 优点

  • 实现简单、易于理解。

3.3 缺点

  • 排他锁会占用连接,产生连接爆满的问题;
  • 如果表不大,可能并不会使用行锁;
  • 同样存在单点问题、并发量问题。

3.4 伪代码

CREATE TABLE `methodLock` (`id` INT ( 11) NOT NULL AUTO_INCREMENT COMMENT '主键',
    `method_name` VARCHAR (64) NOT NULL DEFAULT ''COMMENT' 锁定的方法名 ',
    `desc` VARCHAR (1024) NOT NULL DEFAULT '备注信息',
    `update_time` TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '保存数据时间,自动生成',
    PRIMARY KEY (`id`),
    UNIQUE KEY `uidx_method_name` (`method_name `) USING BTREE 
) ENGINE = INNODB DEFAULT CHARSET = utf8 COMMENT = '锁定中的方法';
/**
 * 加锁
 */
public boolean lock() {
    // 开启事务
    connection.setAutoCommit(false);
    // 循环阻塞,等待获取锁
    while (true) {
        // 执行获取锁的 sql
        result = select * from methodLock where method_name = xxx for update;
        // 结果非空,加锁成功
        if (result != null) {return true;}
    }
    // 加锁失败
    return false;
}

/**
 * 解锁
 */
public void unlock() {
    // 提交事务,解锁
    connection.commit();}

4. 乐观锁实现

一般是通过为数据库表添加一个 version 字段来实现读取出数据时,将此版本号一同读出.

之后更新时,对此版本号加 1,在更新过程中,会对版本号进行比较,如果是一致的,没有发生改变,则会成功执行本次操作;如果版本号不一致,则会更新失败。

实际就是个 CAS 过程。

缺点:

  1. 这种操作方式,使原本一次的 update 操作,必须变为 2 次操作: select 版本号一次;update 一次。增加了数据库操作的次数。
  2. 如果业务场景中的一次业务流程中,多个资源都需要用保证数据一致性,那么如果全部使用基于数据库资源表的乐观锁,就要让每个资源都有一张资源表,这个在实际使用场景中肯定是无法满足的。而且这些都基于数据库操作,在高并发的要求下,对数据库连接的开销一定是无法忍受的。
  3. 乐观锁机制往往基于系统中的数据存储逻辑,因此可能会造成脏数据被更新到数据库中。

5. 总结

数据库锁现在使用较多的就上面说的 3 种方式,排他锁(悲观锁),版本号(乐观锁),记录锁,各有优缺点。

注意点:

  • 使用 mysql 分布式锁,必须保证多个服务节点使用的是同一个 mysql 库。

优点

  • 直接借助 DB 简单易懂。
  • 方便快捷,因为基本每个服务都会连接,但是不是每个服务都会使用 redis 或者 zookeeper;
  • 如果客户端断线了会自动释放锁,不会造成锁一直被占用;
  • mysql 分布式锁是可重入锁,对于旧代码的改造成本低;

缺点

  • 加锁直接打到数据库,增加了数据库的压力;
  • 加锁的线程会占用一个 session,也就是一个连接数,如果并发量大可能会导致正常执行的 sql 语句获取不到连接;
  • 服务拆分后如果每个服务使用自己的数据库,则不合适;
  • 锁的可用性和数据库强关联,一旦数据库挂了,则整个分布式锁不可用;
  • 如果需要考虑极限情况,会有超时等各种问题,在解决问题的过程中会使整个方案变得越来越复杂;
  • 数据库的性能瓶颈相较于 rediszk 要低很多,当调用量大的时候,性能问题将成为关键;
  • 还需要考虑超时等问题。
退出移动版