分布式锁的几种使用方式（redis、zookeeper、数据库）

最新推荐文章于 2024-06-11 13:38:58 发布

tiankong_12345

最新推荐文章于 2024-06-11 13:38:58 发布

阅读量110

点赞数

业务场景：如何保证一致性？

Q:一个业务服务器，一个数据库，操作：查询用户当前余额，扣除当前余额的3%作为手续费

synchronized lock db lock

Q：多个业务服务器，一个数据库，操作：查询用户当前余额，扣除当前余额的3%作为手续费分布式锁

分布式锁应该是什么样的？

可以保证在分布式部署的应用集群中，同一个方法在同一时间只能被一台机器上的一个线程执行
可重入锁（避免死锁）
有高可用的获取锁和释放锁功能。
获取锁和释放锁的性能要好。
最好是阻塞锁（根据业务需求考虑要不要这条）。
最好是公平锁（根据业务需求考虑要不要这条）。

一、基于数据库实现的分布式锁（2种）

基于表实现的分布式锁 和 基于排他锁实现的分布式锁

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

1.2.加锁/解锁

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

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

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

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

delete from methodLock where method_name ='method_name'

1.3.问题+解决方案

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

2.1.基于排他锁实现

除了可以通过增删操作数据表中的记录以外，其实还可以借助数据中自带的锁来实现分布式的锁。我们还用刚刚创建的那张数据库表。可以通过数据库的排他锁来实现分布式锁。基于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;
}

2.2.加锁/解锁

在查询语句后面增加for update，数据库会在查询过程中给数据库表增加排他锁。当某条记录被加上排他锁之后，其他线程无法再在该行记录上增加排他锁。

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

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

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

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

2.3.问题+解决方案

阻塞锁？ for update语句会在执行成功后立即返回，在执行失败时一直处于阻塞状态，直到成功。
锁定之后服务宕机，无法释放？使用这种方式，服务宕机之后数据库会自己把锁释放掉。
但是还是无法直接解决数据库单点、可重入和公平锁的问题。

3.总结

这两种方式都是依赖数据库的一张表，一种是通过表中的记录的存在情况确定当前是否有锁存在，另外一种是通过数据库的排他锁来实现分布式锁。
数据库实现分布式锁的优点：直接借助数据库，容易理解。
数据库实现分布式锁的缺点：会有各种各样的问题，在解决问题的过程中会使整个方案变得越来越复杂。操作数据库需要一定的开销，性能问题需要考虑。

二、基于缓存的分布式锁

1.加锁/解锁

相比较于基于数据库实现分布式锁的方案来说，基于缓存来实现在性能方面会表现的更好一点。目前有很多成熟的缓存产品，包括Redis，memcached等。这里以Redis为例来分析下使用缓存实现分布式锁的方案。基于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); 
}

2.问题+解决方案

单点问题？现在主流的缓存服务都支持集群部署，通过集群来解决单点问题。
没有失效时间？redis的setExpire方法支持传入失效时间，到达时间之后数据会自动删除。
非阻塞？while重复执行。
非可重入？在一个线程获取到锁之后，把当前主机信息和线程信息保存起来，下次再获取之前先检查自己是不是当前锁的拥有者。
非公平？在线程获取锁之前先把所有等待的线程放入一个队列中，然后按先进先出原则获取锁。
失效时间我设置多长时间为好？如何设置的失效时间太短，方法没等执行完，锁就自动释放了，那么就会产生并发问题。如果设置的时间太长，其他获取锁的线程就可能要平白的多等一段时间。对于这个问题目前主流的做法是每获得一个锁时，只设置一个很短的超时时间，同时起一个线程在每次快要到超时时间时去刷新锁的超时时间。在释放锁的同时结束这个线程。如redis官方的分布式锁组件redisson,就是用的这种方案。

3.总结

使用缓存实现分布式锁的优点：性能好。
使用缓存实现分布式锁的缺点：实现过于负责，需要考虑的因素太多。

三、基于Zookeeper实现的分布式锁

1.基础

基于zookeeper临时有序节点可以实现的分布式锁。

2.思想

每个客户端对某个方法加锁时，在zookeeper上的与该方法对应的指定节点的目录下，生成一个唯一的瞬时有序节点。判断是否获取锁的方式很简单，只需要判断有序节点中序号最小的一个。当释放锁的时候，只需将这个瞬时节点删除即可。同时，其可以避免服务宕机导致的锁无法释放，而产生的死锁问题。

3.问题+解决方案

锁无法释放？使用Zookeeper可以有效的解决锁无法释放的问题，因为在创建锁的时候，客户端会在ZK中创建一个临时节点，一旦客户端获取到锁之后突然挂掉（Session连接断开），那么这个临时节点就会自动删除掉。其他客户端就可以再次获得锁。
非阻塞锁？使用Zookeeper可以实现阻塞的锁，客户端可以通过在ZK中创建顺序节点，并且在节点上绑定监听器，一旦节点有变化，Zookeeper会通知客户端，客户端可以检查自己创建的节点是不是当前所有节点中序号最小的，如果是，那么自己就获取到锁，便可以执行业务逻辑了。
不可重入？使用Zookeeper也可以有效的解决不可重入的问题，客户端在创建节点的时候，把当前客户端的主机信息和线程信息直接写入到节点中，下次想要获取锁的时候和当前最小的节点中的数据比对一下就可以了。如果和自己的信息一样，那么自己直接获取到锁，如果不一样就再创建一个临时的顺序节点，参与排队。
单点问题？使用Zookeeper可以有效的解决单点问题，ZK是集群部署的，只要集群中有半数以上的机器存活，就可以对外提供服务。
公平问题？使用Zookeeper可以解决公平锁问题，客户端在ZK中创建的临时节点是有序的，每次锁被释放时，ZK可以通知最小节点来获取锁，保证了公平。

4.总结

使用Zookeeper实现分布式锁的优点：有效的解决单点问题，不可重入问题，非阻塞问题以及锁无法释放的问题。实现起来较为简单。
使用Zookeeper实现分布式锁的缺点：性能上不如使用缓存实现分布式锁。需要对ZK的原理有所了解。

5.其他

Zookeeper需要集群部署，会不会出现Redis集群那样的数据同步问题呢？

Zookeeper是一个保证了弱一致性即最终一致性的分布式组件。

Zookeeper采用称为Quorum Based Protocol的数据同步协议。假如Zookeeper集群有N台Zookeeper服务器(N通常取奇数，3台能够满足数据可靠性同时有很高读写性能，5台在数据可靠性和读写性能方面平衡最好)，那么用户的一个写操作，首先同步到N/2 + 1台服务器上，然后返回给用户，提示用户写成功。基于Quorum Based Protocol的数据同步协议决定了Zookeeper能够支持什么强度的一致性。
在分布式环境下，满足强一致性的数据储存基本不存在，它要求在更新一个节点的数据，需要同步更新所有的节点。这种同步策略出现在主从同步复制的数据库中。但是这种同步策略，对写性能的影响太大而很少见于实践。因为Zookeeper是同步写N/2+1个节点，还有N/2个节点没有同步更新，所以Zookeeper不是强一致性的。
用户的数据更新操作，不保证后续的读操作能够读到更新后的值，但是最终会呈现一致性。牺牲一致性，并不是完全不管数据的一致性，否则数据是混乱的，那么系统可用性再高分布式再好也没有了价值。牺牲一致性，只是不再要求关系型数据库中的强一致性，而是只要系统能达到最终一致性即可。

Zookeeper是否满足因果一致性，需要看客户端的编程方式。

不满足因果一致性的做法：

A进程向Zookeeper的/z写入一个数据，成功返回
A进程通知B进程，A已经修改了/z的数据
B读取Zookeeper的/z的数据
由于B连接的Zookeeper的服务器有可能还没有得到A写入数据的更新，那么B将读不到A写入的数据

满足因果一致性的做法

B进程监听Zookeeper上/z的数据变化
A进程向Zookeeper的/z写入一个数据，成功返回前，Zookeeper需要调用注册在/z上的监听器，Leader将数据变化的通知告诉B
B进程的事件响应方法得到响应后，去取变化的数据，那么B一定能够得到变化的值

这里的因果一致性提现在Leader和B之间的因果一致性，也就是是Leader通知了数据有变化

第二种事件监听机制也是对Zookeeper进行正确编程应该使用的方法，所以，Zookeeper应该是满足因果一致性的。所以我们在基于Zookeeper实现分布式锁的时候，应该使用满足因果一致性的做法，即等待锁的线程都监听Zookeeper上锁的变化，在锁被释放的时候，Zookeeper会将锁变化的通知告诉满足公平锁条件的等待线程。

可以直接使用zookeeper第三方库客户端，这个客户端中封装了一个可重入的锁服务。

public boolean tryLock(long timeout, TimeUnit unit) throws InterruptedException {    
    try {        
        return interProcessMutex.acquire(timeout, unit);    
    } catch (Exception e) {        
        e.printStackTrace();    
    }    
    return true; 
} 

public boolean unlock() {    
    try {        
        interProcessMutex.release();    
    } catch (Throwable e) {        
        log.error(e.getMessage(), e);    
    } finally {        
        executorService.schedule(new Cleaner(client, path), delayTimeForClean, TimeUnit.MILLISECONDS);    
    }    
    return true; 
}

使用ZK实现的分布式锁好像完全符合了本文开头我们对一个分布式锁的所有期望。但是，其实并不是，Zookeeper实现的分布式锁其实存在一个缺点，那就是性能上可能并没有缓存服务那么高。因为每次在创建锁和释放锁的过程中，都要动态创建、销毁瞬时节点来实现锁功能。ZK中创建和删除节点只能通过Leader服务器来执行，然后将数据同不到所有的Follower机器上。

三种方案的比较

从理解的难易程度角度（从低到高）：数据库 > 缓存 > Zookeeper
从实现的复杂性角度（从低到高）：Zookeeper > 缓存 > 数据库
从性能角度（从高到低）：缓存 > Zookeeper >= 数据库
从可靠性角度（从高到低）：Zookeeper > 缓存 > 数据库

转载自：https://blog.csdn.net/u010963948/article/details/79006572

tiankong_12345

关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
分布式锁的几种使用方式（redis、zookeeper、数据库）

业务场景：如何保证一致性？Q:一个业务服务器，一个数据库，操作：查询用户当前余额，扣除当前余额的3%作为手续费synchronized lock db lockQ：多个业务服务器，一个数据库，操作：查询用户当前余额，扣除当前余额的3%作为手续费分布式锁分布式锁应该是什么样的？可以保证在分布式部署的应用集群中，同一个方法在同一时间只能被一台机器上的一个...
复制链接

扫一扫