分布式锁的概念、应用场景、实现方式和优缺点对比

一:什么是分布式锁

分布式锁是一种用于协调分布式系统中多个节点对共享资源的访问的机制。在分布式系统中,由于多个节点的并发执行,可能会导致对共享资源的竞争,而分布式锁的目的就是确保在任何时刻,只有一个节点能够持有锁,从而避免对共享资源的冲突访问

分布式锁的设计考虑到以下问题:

  • 互斥性(Mutual Exclusion): 任意时刻只有一个节点能够持有锁。
  • 安全性(Safety): 即使持有锁的节点崩溃或发生其他故障,系统仍能够继续正常工作。
  • 活性(Liveness): 在没有故障发生的情况下,最终会有一个节点成功获取到锁。

二:使用分布式锁的场景

多台服务器中,同一套代码,只需要执行一次【定时任务等】

不同的节点可能会同时对共享资源进行操作,如果没有有效的措施,就会发生数据不一致的情况。例如,两个节点同时对同一个数据进行修改,如果没有严格的同步机制,就会导致数据出现覆盖或冲突的情况。

三:分布式锁的实现类型

  1. 基于数据库 (MySql等) 实现;
  2. 基于缓存(Redis等)实现;
  3. 基于Zookeeper 实现;
    ps:每种实现类型中都有不同实现方式 ,比如mysql有悲观锁和乐观锁的两种实现方式

基于zookeeper分布式锁,使用InterProcessMutex对象代码案例

相关依赖

xml 复制代码
<dependency>
    <groupId>org.apache.curator</groupId>
    <artifactId>curator-framework</artifactId>
    <version>4.3.0</version> <!-- 使用最新版本 -->
</dependency>
<dependency>
    <groupId>org.apache.curator</groupId>
    <artifactId>curator-recipes</artifactId>
    <version>4.3.0</version> <!-- 使用最新版本 -->
</dependency>
java 复制代码
import org.apache.curator.framework.CuratorFramework;
import org.apache.curator.framework.CuratorFrameworkFactory;
import org.apache.curator.retry.ExponentialBackoffRetry;
import org.apache.curator.framework.recipes.locks.InterProcessMutex;

public class DistributedLockExample {

    private static final String ZOOKEEPER_CONNECTION_STRING = "localhost:2181"; // 替换为实际的 ZooKeeper 服务器地址
    private static final String LOCK_PATH = "/example/lock"; //用于获取锁的zookeeper临时目录

    public static void main(String[] args) {
    
        CuratorFramework curatorFramework = createCuratorFramework();
        // 创建分布式锁对象
        InterProcessMutex lock = new InterProcessMutex(curatorFramework, LOCK_PATH);
        try {
            // 尝试获取锁,阻塞直到获取锁成功  参数1 等待时间   参数2 等待时间单位 
            lock.acquire(1,TimeUnit.SECONDS);
            // 在这里执行需要加锁的业务逻辑
            System.out.println("Locked code block");

        } catch (Exception e) {
            e.printStackTrace();
        } finally {
            try {
                // 释放锁
                lock.release();
            } catch (Exception e) {
                e.printStackTrace();
            }
        }

        // 关闭 CuratorFramework 客户端
        curatorFramework.close();
    }
	//获取zookeeper连接
    private static CuratorFramework createCuratorFramework() {
        return CuratorFrameworkFactory.newClient(
                ZOOKEEPER_CONNECTION_STRING,
                new ExponentialBackoffRetry(1000, 3));
    }
}

四:优缺点对比

从性能角度(从高到低)来看:"缓存方式>Zookeeper方式>=数据库方式"。

  • 基于数据库实现分布式锁:

    优点:

    简单易实现,不需要引入额外的组件。

    使用数据库的事务特性,可以保证原子性。

    缺点:

    性能相对较差,因为每次加锁都要涉及到数据库的操作。

    可能会有死锁风险,需要谨慎处理事务隔离级别。

    对数据库的压力较大。

  • 基于缓存(Redis等)实现分布式锁:

    优点:

    性能较高,因为缓存系统通常能够提供快速的读写操作。

    可以设置锁的过期时间,避免死锁。

    缺点:

    对于分布式环境,需要确保缓存的高可用性。

    在某些情况下,可能会发生锁失效或过期的问题。

    不同缓存系统的实现方式和性能特性有差异。

  • 基于 ZooKeeper 实现分布式锁:

    优点:

    具备较好的一致性和可靠性,适用于需要高一致性的场景。

    可以利用 ZooKeeper 的顺序节点和监听机制实现较为复杂的锁管理。

    缺点:

    相对较为复杂,需要引入额外的组件。

    性能相对较低,ZooKeeper 的写入操作开销较大。

    部署和维护 ZooKeeper 集群可能较为复杂。

PS:文章如有不当之处,烦请后台私信,第一时间处理

相关推荐
CodeWithMe4 小时前
【Note】《Kafka: The Definitive Guide》 第8章: Cross-Cluster Data Mirroring
分布式·kafka
Alaia.5 小时前
【kafka 3.9.1】单机版集群部署并配置kafka的SASL认证
分布式·kafka
勤奋的知更鸟6 小时前
Kettle + 大数据实战:从数据采集到分布式处理的完整流程指南
大数据·分布式
Kookoos6 小时前
ABP VNext + Cosmos DB Change Feed:搭建实时数据变更流服务
数据库·分布式·后端·abp vnext·azure cosmos
掘金-我是哪吒19 小时前
分布式微服务系统架构第156集:JavaPlus技术文档平台日更-Java线程池使用指南
java·分布式·微服务·云原生·架构
亲爱的非洲野猪20 小时前
Kafka消息积压的多维度解决方案:超越简单扩容的完整策略
java·分布式·中间件·kafka
活跃家族20 小时前
分布式压测
分布式
前端世界21 小时前
HarmonyOS开发实战:鸿蒙分布式生态构建与多设备协同发布全流程详解
分布式·华为·harmonyos
DavidSoCool1 天前
RabbitMQ使用topic Exchange实现微服务分组订阅
分布式·微服务·rabbitmq