基于curator的分布式锁

  1. 引入依赖
 <dependency>
            <groupId>org.apache.curator</groupId>
            <artifactId>curator-recipes</artifactId>
            <version>5.0.0</version>
        </dependency>

注意curator中带有zookeeper版本,可寻找和自己的zookeeper对应的版本。

  1. config配置
@Configuration
public class ZkConfig {

    @Bean
    public CuratorFramework curatorFramework() {
        RetryPolicy policy = new ExponentialBackoffRetry(1000, 3);
        CuratorFramework framework = CuratorFrameworkFactory.newClient("127.0.0.1:2181", policy);
        framework.start();
        return framework;
    }
}
  1. 使用方式
        InterProcessMutex interProcessMutex = new InterProcessMutex(framework,"/product"+name);
        ///获取锁 可以设置等待时间
		interProcessMutex.acquire();
		//释放锁
        interProcessMutex.release();

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
基于Redis可以使用以下步骤实现分布式: 1. 获取: - 使用Redis的SETNX命令(SET if Not eXists)尝试获取。将的名称作为Redis的key,唯一标识符(如UUID)作为value。 - 如果SETNX返回1,表示成功获取到,执行业务逻辑。 - 如果SETNX返回0,表示已被其他客户端占用,等待一段时间后重试或进行其他处理。 2. 设置的过期时间: - 为了避免的持有者发生异常或崩溃而无法释放,需要为设置一个过期时间。可以使用Redis的EXPIRE命令设置的过期时间。 - 保证在获取后,业务逻辑执行成功并释放之前,不会过期。 3. 释放: - 使用Redis的DEL命令删除的key,以释放。 - 在执行业务逻辑完成后,通过判断的value是否为当前客户端的唯一标识符来确保只有的持有者才能释放。 需要注意的是,分布式的实现还需要考虑以下情况: - 死检测:如果持有的客户端发生异常或崩溃,导致无法正常释放,需要设置一个合理的过期时间,以确保能够被自动释放。 - 重试机制:在获取时,如果已被其他客户端占用,可以根据业务需求进行等待一段时间后重试,或者使用指数退避等策略来避免竞争激烈时的频繁重试。 - 高可用性:当Redis服务器发生故障或网络分区时,需要确保分布式的可用性。可以使用Redis的主从复制、哨兵模式或集群模式等来提高系统的可用性。 另外,为了简化分布式的实现,也可以考虑使用已经实现好的分布式框架,如Redlock、Curator等。这些框架提供了更完善和可靠的分布式解决方案。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值