分布式锁

最新推荐文章于 2025-07-11 15:00:26 发布

原创最新推荐文章于 2025-07-11 15:00:26 发布 · 133 阅读

0 ·

CC 4.0 BY-SA版权

分布式服务专栏收录该内容

20 篇文章

订阅专栏

本文深入解析分布式锁的特点，包括原子性、可重入性、可阻塞性、高可用性和高性能。并详细介绍了三种主流的分布式锁实现方式：基于数据库（乐观锁、悲观锁）、基于Redis和基于ZooKeeper的实现细节。

分布式锁的特点
原子性：同一时刻，只能有一个机器的一个线程得到锁；
可重入性：同一对象（如线程、类）可以重复、递归调用该锁而不发生死锁；
可阻塞：在没有获得锁之前，只能阻塞等待直至获得锁；
高可用：哪怕发生程序故障、机器损坏，锁仍然能够得到被获取、被释放；
高性能：获取、释放锁的操作消耗小。

目前主流的有三种

基于数据库实现
基于Redis实现
基于ZooKeeper实现

基于数据库实现：

基于数据库来做分布式锁的话，通常有两种做法：

基于数据库的乐观锁
基于数据库的悲观锁

乐观锁机制其实就是在数据库表中引入一个版本号（version）字段来实现的。
当要从数据库中读取数据的时候，同时把这个version字段也读出来，如果要对读出来的数据进行更新后写回数据库，则需要将version加1，同时将新的数据与新的version更新到数据表中，且必须在更新的时候同时检查目前数据库里version值是不是之前的那个version，如果是，则正常更新。如果不是，则更新失败，说明在这个过程中有其它的进程去更新过数据了。

悲观锁也叫作排它锁，在Mysql中是基于 for update 来实现加锁的，例如：

//锁定的方法-伪代码
public boolean lock(){
    connection.setAutoCommit(false)
    for(){
        result = 
        select * from user where 
        id = 100 for update;
        if(result){
         //结果不为空，
        //则说明获取到了锁
            return true;
        }
        //没有获取到锁，继续获取
        sleep(1000);
    }
    return false;
}

//释放锁-伪代码
connection.commit();

上面的示例中，user表中，id是主键，通过 for update 操作，数据库在查询的时候就会给这条记录加上排它锁。需要注意的是，在InnoDB中只有字段加了索引的，才会是行级锁，否者是表级锁，所以这个id字段要加索引。当这条记录加上排它锁之后，其它线程是无法操作这条记录的。
那么，这样的话，就可以认为获得了排它锁的这个线程是拥有了分布式锁，然后就可以执行想要做的业务逻辑，当逻辑完成之后，再调用上述释放锁的语句即可。

基于Redis实现

基于Redis实现的锁机制，主要是依赖redis自身的原子操作，例如：

SET user_key user_value NX PX 100

上述代码示例是指，当redis中不存在user_key这个键的时候，才会去设置一个user_key键，并且给这个键的值设置为 user_value，且这个键的存活时间为100ms。

为什么这个命令可以帮实现锁机制呢？
因为这个命令是只有在某个key不存在的时候，才会执行成功。那么当多个进程同时并发的去设置同一个key的时候，就永远只会有一个进程成功。当某个进程设置成功之后，就可以去执行业务逻辑了，等业务逻辑执行完毕之后，再去进行解锁。
解锁很简单，只需要删除这个key就可以了，不过删除之前需要判断，这个key对应的value是当初自己设置的那个。
另外，针对redis集群模式的分布式锁，可以采用redis的Redlock机制。

基于ZooKeeper实现

其实基于ZooKeeper，就是使用它的临时有序节点来实现的分布式锁。
原理就是：当某客户端要进行逻辑的加锁时，就在zookeeper上的某个指定节点的目录下，去生成一个唯一的临时有序节点，然后判断自己是否是这些有序节点中序号最小的一个，如果是，则算是获取了锁。如果不是，则说明没有获取到锁，那么就需要在序列中找到比自己小的那个节点，并对其调用exist()方法，对其注册事件监听，当监听到这个节点被删除了，那就再去判断一次自己当初创建的节点是否变成了序列中最小的。如果是，则获取锁，如果不是，则重复上述步骤。
当释放锁的时候，只需将这个临时节点删除即可。