【mysql】基于mysql数据库的分布式锁

前言:在前面的zk和redis篇已经多次介绍什么是分布式锁,这里就不再赘述了,分布式锁常见的实现方式主要由三种,一种是基于zookeeper实现,一种是基于redis实现,今天要介绍的就是用的最少,最简单,但不太推荐使用的基于mysql数据库实现的分布式锁...之所以不推荐,主要是因为性能不怎样,而且容易造成死锁,但你要想成为一名"高级"java程序猿,即便它不好用,你也得学,说不定哪天就碰上了,说不定哪个面试官就问到了,说不定学了可以学到一些好的思想...

基于mysql数据库实现分布式锁主要有两种方式:一种是基于数据库表实现的乐观锁和悲观锁,另一种是基于Mysql自带的悲观锁,下面就来一起看一看这几种实现方式及其差异和使用场景.

---

1.基于数据库表

1.1 悲观锁

Mysql实现分布式悲观锁:直接创建一张锁表，然后通过操作该表中的数据来实现了。当我们要锁住某个方法或资源时，我们就在该表中增加一条记录，想要释放锁的时候就删除这条记录。

创建这样一张数据库表：

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='锁定中的方法';

当我们想要锁住某个方法时，执行以下SQL：

insert into methodLock(method_name,desc) values (‘method_name’,‘desc’)

 

因为我们对method_name做了唯一性约束，这里如果有多个请求同时提交到数据库的话，数据库会保证只有一个操作可以成功，那么我们就可以认为操作成功的那个线程获得了该方法的锁，可以执行方法体内容。

当方法执行完毕之后，想要释放锁的话，需要执行以下Sql:

delete from methodLock where method_name ='method_name'

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

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

 针对上面的问题,我们可以对症下药:

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

但无论如何,Mysql数据库的性能和效率大家心里都有点abcd数的,在高并发的情况下, 用Mysql做分布式锁,无异于是找死...

1.2 乐观锁

大多数是基于数据版本(version)的记录机制实现的.何谓数据版本号?即为数据增加一个版本标识,在基于数据库表的版本解决方案中,一般是通过为数据库表添加一个 “version”字段来实现读取出数据时,将此版本号一同读出,之后更新时,对此版本号加1.在更新过程中,会对版本号进行比较,如果是一致的,没有发生改变,则会成功执行本次操作;如果版本号不一致,则会更新失败.

对乐观锁的含义有了一定的了解后，结合具体的例子，我们来推演下我们应该怎么处理：

假设我们有一张资源表,态(1未分配  2已分配)、资源创建时间、资源更新时间、资源数据版本号.

据进行分配,假设我们现在我们对id=5780这条数那么非分布式场景的情况下,我们一般先查询出来state=1(未分配)的数据，然后从其中选取一条数据可以通过以下语句进行,如果可以更新成功,那么就说明已经占用了这个资源

update t_resource set state=2 where state=1 and id=5780。

如果在分布式场景中，由于数据库的update操作是原子是原子的，其实上边这条语句理论上也没有问题，但是这条语句如果在典型的“ABA”情况下，我们是无法感知的。有人可能会问什么是“ABA”问题呢？大家可以网上搜索一下，这里我说简单一点就是，如果在你第一次select和第二次update过程中，由于两次操作是非原子的，所以这过程中，如果有一个线程，先是占用了资源(state=2)，然后又释放了资源(state=1)，实际上最后你执行update操作的时候，是无法知道这个资源发生过变化的。也许你会说这个在你说的场景中应该也还好吧，但是在实际的使用过程中，比如银行账户存款或者扣款的过程中，这种情况是比较恐怖的.

那么如果使用乐观锁我们如何解决上边的问题呢?

a. 先执行select操作查询当前数据的数据版本号,比如当前数据版本号是26：

select id, resource, state,version from t_resource  where state=1 and id=5780;

b. 执行更新操作：

update t_resoure set state=2, version=27, update_time=now() where resource=xxxxxx and state=1 and version=26

c.如果上述update语句真正更新影响到了一行数据，那就说明占位成功。如果没有更新影响到一行数据，则说明这个资源已经被别人占位了。

通过上面的讲解，相信大家已经对如何基于数据库表做乐观锁有有了一定的了解了，但是这里还是需要说明一下基于数据库表做乐观锁的一些缺点:

①这种操作方式，使原本一次的update操作，必须变为2次操作: select版本号一次；update一次。增加了数据库操作的次数。

②如果业务场景中的一次业务流程中，多个资源都需要用保证数据一致性，那么如果全部使用基于数据库资源表的乐观锁，就要让每个资源都有一张资源表，这个在实际使用场景中肯定是无法满足的。而且这些都基于数据库操作，在高并发的要求下，对数据库连接的开销一定是无法忍受的。

③乐观锁机制往往基于系统中的数据存储逻辑，因此可能会造成脏数据被更新到数据库中。在系统设计阶段，我们应该充分考虑到这些情况出现的可能性，并进行相应调整，如将乐观锁策略在数据库存储过程中实现，对外只开放基于此存储过程的数据更新途径，而不是将数据库表直接对外公开。

 2.基于Mysql自带的悲观锁实现

利用for update加显式的行锁，这样就能利用这个行级的排他锁来实现分布式锁了，同时unlock的时候只要释放commit这个事务，就能达到释放锁的目的。

/**
     * 超时获取锁
     * @param lockID
     * @param timeOuts
     * @return
     * @throws InterruptedException
     */
    public boolean acquireByUpdate(String lockID, long timeOuts) throws InterruptedException, SQLException {

        String sql = "SELECT id from test_lock where id = ? for UPDATE ";
        long futureTime = System.currentTimeMillis() + timeOuts;
        long ranmain = timeOuts;
        long timerange = 500;
        connection.setAutoCommit(false);
        while (true) {
            CountDownLatch latch = new CountDownLatch(1);
            try {
                PreparedStatement statement = connection.prepareStatement(sql);
                statement.setString(1, lockID);
                statement.setInt(2, 1);
                statement.setLong(1, System.currentTimeMillis());
                boolean ifsucess = statement.execute();//如果成功，那么就是获取到了锁
                if (ifsucess)
                    return true;
            } catch (SQLException e) {
                e.printStackTrace();
            }
            latch.await(timerange, TimeUnit.MILLISECONDS);
            ranmain = futureTime - System.currentTimeMillis();
            if (ranmain <= 0)
                break;
            if (ranmain < timerange) {
                timerange = ranmain;
            }
            continue;
        }
        return false;

    }


    /**
     * 释放锁
     * @param lockID
     * @return
     * @throws SQLException
     */
    public void unlockforUpdtate(String lockID) throws SQLException {
        connection.commit();

    }

优点：实现简单

缺点：连接池爆满和事务超时的问题单点的问题，单点问题，行锁升级为表锁的问题，并发量大的时候请求量太大、没有线程唤醒机制。

连接池爆满和事务超时的问题单点的问题：利用事务进行加锁的时候，query需要占用数据库连接，在行锁的时候连接不释放，这就会导致连接池爆满。同时由于事务是有超时时间的，过了超时时间自动回滚，会导致锁的释放，这个超时时间要把控好。

适用场景:并发量略高于上面使用乐观锁的情况下,可以采用这种方法.

---

总结:不论如何,使用Mysql来实现分布式锁都不推荐,其性能,可靠性,以及实现上跟其它两种方式对比均没啥优势,正如我开篇所述,学习Mysql实现分布式锁可以仅仅作为一种了解和思想升华.