zookeeper实现分布式锁实战

本文涉及的产品
MSE Nacos/ZooKeeper 企业版试用,1600元额度,限量50份
服务治理 MSE Sentinel/OpenSergo,Agent数量 不受限
任务调度 XXL-JOB 版免费试用,400 元额度,开发版规格
简介: zookeeper实现分布式锁实战

zookeeper实现分布式锁实战

分布式锁

分布式锁(多服务共享锁) 在分布式的部署环境下,通过锁机制来让多客户端互斥的对共享资源进行访问。

对于一个分布式系统中同一个方法,如果多个线程同时访问,对数据库的修改会产生错误,所以就需要在整个分布式系统上的多线程同时访问造成数据错误的代码段或者说方法上加分布式锁。

分布式锁的种类

  1. 基于数据库本身的锁
  2. 基于redis中的setnx的锁
  3. 基于zookeeper的分布式锁

zookeeper分布式锁

因为zookeeper的结构是一个树形的结构,所以使用zokeeper实现分布式锁的方式就是,建立锁就是建立一个文件夹,然后多线程要获取分布式锁的过程中,可以在这个锁(也就是文件夹)下创建一个个有序的文件,代表获取锁的多线程的顺序。

如下实现原理:

zookeeper实战

使用docker安装安装zookeeper

docker run --name some-zookeeper -d --privileged=true -p 2181:2181 -p 8080:8080 zookeeper:latest

启动后:访问http://ip:8080/commands

代表启动成功

创建springboot项目并引入依赖

<dependency>
    <groupId>org.apache.curator</groupId>
    <artifactId>curator-recipes</artifactId>
    <version>5.2.0</version>
</dependency>
<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-web</artifactId>
</dependency>

实现zookeeper分布式锁

@RestController
public class zookeeperTest {
    @RestController
    public class TestControl {
        private int a = 10;
        @RequestMapping("/test")
        public String test() throws Exception {
            //设置zk的客户端重试策略 每隔5秒重试一次,最多10次
            RetryPolicy policy = new ExponentialBackoffRetry(5000, 10);
            //创建zk客户端 链接zookeeper服务器
            CuratorFramework client = CuratorFrameworkFactory.builder().connectString("ip(改成自己的):2181").retryPolicy(policy).build();
            //创建与zookeeper服务器的连接
            client.start();
            //声明锁的对象,本质就是ZK顺序临时节点
            final InterProcessMutex mutex = new InterProcessMutex(client, "/lock/shoe");
            try {
                //请求锁,创建锁
                mutex.acquire();
                if(a>0){
                    Thread.sleep(500);
                    return "你抢到了"+(a--);
                }else{
                       return "商品已无";
                }
            } catch (Exception e) {
                e.printStackTrace();
            }finally {
                mutex.release();
            }
            return "null";
        }
    }
}

启动项目使用jmeter测试

  1. 创建线程组并设置线程数为15

2. 创建http请求

3. 创建结果树(便于查看请求结果)

  1. 查看zookeper的树结构的节点

可以看出文件树是有序的,也就是需要执行一个之后再执行其他的,并发度降低了,所以适合并发小的程序。

相关文章
|
4月前
|
人工智能 Kubernetes 数据可视化
Kubernetes下的分布式采集系统设计与实战:趋势监测失效引发的架构进化
本文回顾了一次关键词监测任务在容器集群中失效的全过程,分析了中转IP复用、调度节奏和异常处理等隐性风险,并提出通过解耦架构、动态IP分发和行为模拟优化采集策略,最终实现稳定高效的数据抓取与分析。
Kubernetes下的分布式采集系统设计与实战:趋势监测失效引发的架构进化
|
6月前
|
消息中间件 运维 Kafka
直播预告|Kafka+Flink双引擎实战:手把手带你搭建分布式实时分析平台!
在数字化转型中,企业亟需从海量数据中快速提取价值并转化为业务增长动力。5月15日19:00-21:00,阿里云三位技术专家将讲解Kafka与Flink的强强联合方案,帮助企业零门槛构建分布式实时分析平台。此组合广泛应用于实时风控、用户行为追踪等场景,具备高吞吐、弹性扩缩容及亚秒级响应优势。直播适合初学者、开发者和数据工程师,参与还有机会领取定制好礼!扫描海报二维码或点击链接预约直播:[https://developer.aliyun.com/live/255088](https://developer.aliyun.com/live/255088)
422 35
直播预告|Kafka+Flink双引擎实战:手把手带你搭建分布式实时分析平台!
|
11天前
|
消息中间件 分布式计算 资源调度
《聊聊分布式》ZooKeeper与ZAB协议:分布式协调的核心引擎
ZooKeeper是一个开源的分布式协调服务,基于ZAB协议实现数据一致性,提供分布式锁、配置管理、领导者选举等核心功能,具有高可用、强一致和简单易用的特点,广泛应用于Kafka、Hadoop等大型分布式系统中。
|
6月前
|
消息中间件 运维 Kafka
直播预告|Kafka+Flink 双引擎实战:手把手带你搭建分布式实时分析平台!
直播预告|Kafka+Flink 双引擎实战:手把手带你搭建分布式实时分析平台!
195 12
|
8月前
|
数据采集 存储 数据可视化
分布式爬虫框架Scrapy-Redis实战指南
本文介绍如何使用Scrapy-Redis构建分布式爬虫系统,采集携程平台上热门城市的酒店价格与评价信息。通过代理IP、Cookie和User-Agent设置规避反爬策略,实现高效数据抓取。结合价格动态趋势分析,助力酒店业优化市场策略、提升服务质量。技术架构涵盖Scrapy-Redis核心调度、代理中间件及数据解析存储,提供完整的技术路线图与代码示例。
724 0
分布式爬虫框架Scrapy-Redis实战指南
|
4月前
|
数据采集 缓存 NoSQL
分布式新闻数据采集系统的同步效率优化实战
本文介绍了一个针对高频新闻站点的分布式爬虫系统优化方案。通过引入异步任务机制、本地缓存池、Redis pipeline 批量写入及身份池策略,系统采集效率提升近两倍,数据同步延迟显著降低,实现了分钟级热点追踪能力,为实时舆情监控与分析提供了高效、稳定的数据支持。
116 1
分布式新闻数据采集系统的同步效率优化实战
|
5月前
|
数据采集 机器学习/深度学习 数据可视化
让回归模型不再被异常值"带跑偏",MSE和Cauchy损失函数在噪声数据环境下的实战对比
本文探讨了MSE与Cauchy损失函数在线性回归中的表现,特别是在含噪声数据环境下的差异。研究发现,MSE虽具良好数学性质,但对异常值敏感;而Cauchy通过其对数惩罚机制降低异常值影响,展现出更强稳定性。实验结果表明,Cauchy损失函数在处理含噪声数据时参数估计更接近真实值,为实际应用提供了更鲁棒的选择。
166 1
让回归模型不再被异常值"带跑偏",MSE和Cauchy损失函数在噪声数据环境下的实战对比
|
5月前
|
缓存 NoSQL 算法
高并发秒杀系统实战(Redis+Lua分布式锁防超卖与库存扣减优化)
秒杀系统面临瞬时高并发、资源竞争和数据一致性挑战。传统方案如数据库锁或应用层锁存在性能瓶颈或分布式问题,而基于Redis的分布式锁与Lua脚本原子操作成为高效解决方案。通过Redis的`SETNX`实现分布式锁,结合Lua脚本完成库存扣减,确保操作原子性并大幅提升性能(QPS从120提升至8,200)。此外,分段库存策略、多级限流及服务降级机制进一步优化系统稳定性。最佳实践包括分层防控、黄金扣减法则与容灾设计,强调根据业务特性灵活组合技术手段以应对高并发场景。
1273 7
|
6月前
|
监控 Java 调度
SpringBoot中@Scheduled和Quartz的区别是什么?分布式定时任务框架选型实战
本文对比分析了SpringBoot中的`@Scheduled`与Quartz定时任务框架。`@Scheduled`轻量易用,适合单机简单场景,但存在多实例重复执行、无持久化等缺陷;Quartz功能强大,支持分布式调度、任务持久化、动态调整和失败重试,适用于复杂企业级需求。文章通过特性对比、代码示例及常见问题解答,帮助开发者理解两者差异,合理选择方案。记住口诀:单机简单用注解,多节点上Quartz;若是任务要可靠,持久化配置不能少。
555 4

热门文章

最新文章

下一篇
开通oss服务