分布式锁

1天真无邪1

于 2020-11-22 01:42:08 发布

阅读量151

点赞数

分类专栏： redis

本文链接：https://blog.csdn.net/qq_37997523/article/details/109913016

版权

redis 专栏收录该内容

6 篇文章 0 订阅

订阅专栏

原文链接
1. 基于表实现的分布式锁［非阻塞］

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’
上面这种简单的实现有以下几个问题：
1、这把锁强依赖数据库的可用性，数据库是一个单点，一旦数据库挂掉，会导致业务系统不可用。

2、这把锁没有失效时间，一旦解锁操作失败，就会导致锁记录一直在数据库中，其他线程无法再获得到锁。

3、这把锁只能是非阻塞的，因为数据的insert操作，一旦插入失败就会直接报错。没有获得锁的线程并不会进入排队队列，要想再次获得4、锁就要再次触发获得锁操作。

5、这把锁是非重入的，同一个线程在没有释放锁之前无法再次获得该锁。因为数据中数据已经存在了。

6、这把锁是非公平锁，所有等待锁的线程凭运气去争夺锁。
当然，我们也可以有其他方式解决上面的问题：
1、数据库是单点？搞两个数据库，数据之前双向同步。一旦挂掉快速切换到备库上。

2、没有失效时间？只要做一个定时任务，每隔一定时间把数据库中的超时数据清理一遍。

3、非阻塞的？搞一个while循环，直到insert成功再返回成功。

4、非重入的？在数据库表中加个字段，记录当前获得锁的机器的主机信息和线程信息，那么下次再获取锁的时候先查询数据库，如果当前机器的主机信息和线程信息在数据库可以查到的话，直接把锁分配给他就可以了。

5、非公平的？再建一张中间表，将等待锁的线程全记录下来，并根据创建时间排序，只有最先创建的允许获取锁

2、基于排他锁实现的分布式锁［阻塞］
除了可以通过增删操作数据表中的记录以外，其实还可以借助数据中自带的锁来实现分布式的锁。
我们还用刚刚创建的那张数据库表。可以通过数据库的排他锁来实现分布式锁。基于MySql的InnoDB引擎，可以使用以下方法来实现加锁操作：

public boolean lock(){    
    connection.setAutoCommit(false);
    while(true){        
        try{            
            result = select * from methodLock where method_name=xxx for update;            
            if(result==null){                
                return true;           
            }        
        }catch(Exception e){
 
        }
        sleep(1000);
    }
    return false;
}

我们可以认为获得排它锁的线程即可获得分布式锁，当获取到锁之后，可以执行方法的业务逻辑，执行完方法之后，再通过以下方法解锁：

public void unlock(){ connection.commit(); }

通过connection.commit();操作来释放锁。

这种方法可以有效的解决上面提到的无法释放锁和阻塞锁的问题。

阻塞锁？ for update语句会在执行成功后立即返回，在执行失败时一直处于阻塞状态，直到成功。

锁定之后服务宕机，无法释放？使用这种方式，服务宕机之后数据库会自己把锁释放掉。

但是还是无法直接解决数据库单点、可重入和公平锁的问题。

总结一下使用数据库来实现分布式锁的方式，这两种方式都是依赖数据库的一张表，一种是通过表中的记录的存在情况确定当前是否有锁存在，另外一种是通过数据库的排他锁来实现分布式锁。

mysql的select for update
for update是在数据库中上锁用的，可以为数据库中的行上一个排它锁。当一个事务的操作未完成时候，其他事务可以读取但是不能写入或更新。for update 仅适用于InnoDB，并且必须开启事务，在begin与commit之间才生效。
使用方法：select * from table where xxx for update
InnoDB默认是行级别的锁，当有明确指定的主键时候，是行级锁。否则是表级别。
明确指定主键，并且有此记录，行级锁
明确指定主键/索引，若查无此记录，无锁
无主键/索引，表级锁
主键/索引不明确，表级锁 SELECT * FROM foods WHERE id<>’3’ FOR UPDATE;
SELECT * FROM foods WHERE id LIKE ‘3’ FOR UPDATE；

数据库实现分布式锁的优点：直接借助数据库，容易理解。
数据库实现分布式锁的缺点：会有各种各样的问题，在解决问题的过程中会使整个方案变得越来越复杂。操作数据库需要一定的开销，性能问题需要考虑。
3、基于缓存的分布式锁
基于Redis实现分布式锁在网上有很多相关文章，其中主要的实现方式是使用Jedis.setNX方法来实现。

public boolean trylock(String key) {

    ResultCode code = jedis.setNX(key, "This is a Lock.");    
    if (ResultCode.SUCCESS.equals(code))        
        return true;    
    else        
        return false; 
} 
public boolean unlock(String key){
    ldbTairManager.invalid(NAMESPACE, key); 
}

以上实现方式同样存在几个问题：

1、单点问题。

2、这把锁没有失效时间，一旦解锁操作失败，就会导致锁记录一直在redis中，其他线程无法再获得到锁。

3、这把锁只能是非阻塞的，无论成功还是失败都直接返回。

4、这把锁是非重入的，一个线程获得锁之后，在释放锁之前，无法再次获得该锁，因为使用到的key在redis中已经存在。无法再执行setNX操作。

5、这把锁是非公平的，所有等待的线程同时去发起setNX操作，运气好的线程能获取锁。

当然，同样有方式可以解决。

现在主流的缓存服务都支持集群部署，通过集群来解决单点问题。

没有失效时间？redis的setExpire方法支持传入失效时间，到达时间之后数据会自动删除。

非阻塞？while重复执行。

非可重入？在一个线程获取到锁之后，把当前主机信息和线程信息保存起来，下次再获取之前先检查自己是不是当前锁的拥有者。

非公平？在线程获取锁之前先把所有等待的线程放入一个队列中，然后按先进先出原则获取锁。

redis集群的同步策略是需要时间的，有可能A线程setNX成功后拿到锁，但是这个值还没有更新到B线程执行setNX的这台服务器，那就会产生并发问题。
算法的步骤如下：

1、客户端获取当前时间，以毫秒为单位。
2、客户端尝试获取N个节点的锁，（每个节点获取锁的方式和前面说的缓存锁一样），N个节点以相同的key和value获取锁。客户端需要设置接口访问超时，接口超时时间需要远远小于锁超时时间，比如锁自动释放的时间是10s，那么接口超时大概设置5-50ms。这样可以在有redis节点宕机后，访问该节点时能尽快超时，而减小锁的正常使用。
3、客户端计算在获得锁的时候花费了多少时间，方法是用当前时间减去在步骤一获取的时间，只有客户端获得了超过3个节点的锁，而且获取锁的时间小于锁的超时时间，客户端才获得了分布式锁。
4、客户端获取的锁的时间为设置的锁超时时间减去步骤三计算出的获取锁花费时间。
5、如果客户端获取锁失败了，客户端会依次删除所有的锁。
使用Redlock算法，可以保证在挂掉最多2个节点的时候，分布式锁服务仍然能工作，这相比之前的数据库锁和缓存锁大大提高了可用性，由于redis的高效性能，分布式缓存锁性能并不比数据库锁差。

1天真无邪1

关注

0
点赞
踩
1

收藏

觉得还不错? 一键收藏
0
评论
分布式锁

1. 基于表实现的分布式锁［非阻塞］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 CU
复制链接

扫一扫