随着现在分布式架构越来越盛行,在很多场景下需要使用到分布式锁。很多小伙伴对于分布式锁还不是特别了解,所以特地总结了一篇文章,让大家一文读懂分布式锁的前世今生。
常用的即 synchronize 或 Lock 等 JDK 自带的锁,只能锁住当前进程,仅适用于单体架构服务。 而在分布式多服务实例场景下必须使用分布式锁
在分布式系统中,多个节点可能同时操作同一资源,此时需要使用分布式锁来保护共享资源的访问。分布式锁要求在多个节点上都能起到保护作用,并且能够保证在高并发情况下的正确性和效率。
我们可以借助于redis中的命令setnx(key, value),key不存在就新增,存在就什么都不做。同时有多个客户端发送setnx命令,只有一个客户端可以成功,返回1(true);其他的客户端返回0(false),流程图如下图所示:
现在的系统都是集群部署,每个服务都不是单节点的了。比如库存服务,可能部署到3台机器上分别命名为节点1,节点2,节点3。库存服务需要扣减库存,扣减库存肯定需要锁吧,如果使用Lock或者synchronized,只能锁住自己的节点。而从前台访问是随机路由到这3台节点的。如果线程一进来使节点1上了锁,当线程二进来可能访问到的是节点2,这时节点2还没有上锁,那么库存就会扣减错误。而库存扣减还是一个核心操作,现在居然有Bug,想想就可怕。
在单机部署的时候,我们可以使用 Java 中提供的 JUC 锁机制避免多线程同时操作一个共享变量产生的安全问题。JUC 锁机制只能保证同一个 JVM 进程中的同一时刻只有一个线程操作共享资源。
分布式锁,其实原理是就是多台机器,去争抢一个资源,谁争抢成功,那么谁就持有了这把锁,然后去执行后续的业务逻辑,执行完毕后,把锁释放掉。
分布式锁可以保证在分布式系统中,同一操作只被一台机器上的一个线程执行,保证共享数据的一致性。
主要 用来 给方法、代码块加锁。当某个方法或者代码块使用锁时,那么在同一时刻至多仅有一个线程可以执行该段代码。当有多个线程访问同一对象的加锁方法/代码块时,同一时间只有一个线程在执行,其余线程必须要等待当前线程执行完之后才能执行该代码。但是,其余线程是可以访问对象中没有被加锁的代码。线程锁只在同一个JVM 中有效果,因为线程锁的实现在根本上是依靠线程之间共享内存实现的,比如 Synchrogazeed、Lock 等。
在单体架构中,我们处理并发的手段有多种,例如synchronized或使用ReentrantLock等常用手段,但是在分布式架构中,上述所说的就不能解决某些业务的并发问题了,那么接下来我们就开始聊聊分布式锁。
随着业务中缓存及分布式锁的加入,业务代码变的复杂起来,除了需要考虑业务逻辑本身,还要考虑缓存及分布式锁的问题,增加了程序员的工作量及开发难度。而缓存的玩法套路特别类似于事务,而声明式事务就是用了aop的思想实现的。
常用的即 synchronize 或 Lock 等 JDK 自带的锁,只能锁住当前进程,仅适用于单体架构服务。
演示如何使用分布式锁(基于Redis的分布式锁)和消息队列(基于Spring Boot和RabbitMQ)来优化高并发抢购场景。请注意,这只是一个基本示例,实际场景可能需要更多的细节和安全性考虑。
本文是我们小项目的第三篇文了,本次我们来把分布式锁应用到我们的项目中,使用Redis实现的分布式锁功能,这一切都是为我们往后的工作做铺垫,希望大家能get到分布式锁这项新技能。
开发一个高并发预约管理处理系统,其中用户可以预约倾听者。由于并发预约可能导致冲突和混乱,需要实现分布式锁来确保同一时间段只有一个用户可以进行预约。为了实现这一目的,使用Redis作为分布式锁的存储介质,并设计一组表来存储倾听者的预约情况。
在当今这个时代,单体应用(standalone)已经很少了,java提供的synchronized已经不能满足需求,大家自然 而然的想到了分布式锁。谈到分布式锁,比较流行的方法有3中:
在如今高并发、分布式大行其道的今天,如果你还只会单体项目,那未免也太落伍了。撇开技术落伍、受人耻笑外(脸皮厚的人根本不在乎耻笑),更为现实的问题是:如果你是刚进入职场的新人,即将面临找工作,估计连面试机会都没有;如果你是已经在职的人士,不知晓分布式的各种成人姿势,那你也只有在公司任人玩弄的份。说到分布式这么重要,那今天我作为一个潜伏IT圈多年的老将,跟大家分享下分布式下的分布式锁的各种成人姿势,注意是成人哦,未成年人勿入。
看到标题,有人可能会满心疑惑?张小帅是谁?咳咳,老猫在此先卖个关子,关于张小帅,老猫后续会向大家正式介绍的,标题算是彩蛋了。
作者简介:曾任职于阿里巴巴,每日优鲜等互联网公司,任技术总监,15年电商互联网经历。
随着业务发展的需要,原单体单机部署的系统被演化成分布式集群系统后,由于分布式系统多线程、多进程并且分布在不同机器上,这将使原单机部署情况下的并发控制锁策略失效,单纯的Java API并不能提供分布式锁的能力。为了解决这个问题就需要一种跨JVM的互斥机制来控制共享资源的访问,这就是分布式锁要解决的问题!
为了保证一个在高并发存场景下只能被同一个线程操作,java并发处理提供ReentrantLock或Synchronized进行互斥控制。但是这仅仅对单机环境有效。我们实现分布式锁大概通过三种方式。
需要一种支持分布式集群环境下的锁:查询 DB 时,只有一个线程能访问,其他线程都需要等待第一个线程释放锁资源后,才能继续执行。
上一篇文章讲解了分布式锁,分布式锁-腾讯云开发者社区-腾讯云 (tencent.com)
数据库乐观锁 基于Redis的分布式锁 基于Zookeeper的分布式锁 本文介绍的是基于Redis的分布式锁;
在当今这个时代,单体应用(standalone)已经很少了,java提供的synchronized已经不能满足需求,大家自然
管理后台的部署架构(多台tomcat服务器+redis【多台tomcat服务器访问一台redis】+mysql【多台tomcat服务器访问一台服务器上的mysql】)就满足使用分布式锁的条件。多台服务器要访问redis全局缓存的资源,如果不使用分布式锁就会出现问题。 看如下伪代码:
大多数互联网系统都是分布式部署的,分布式部署确实能带来性能和效率上的提升,但为此,我们就需要多解决一个分布式环境下,数据一致性的问题。
关于为什么要有「分布式锁」这个东西,欢迎阅读我的zk分布式锁的实现,介绍了单机高并发、分布式高并发的解决方案:
Redis支持五种数据类型:string(字符串),hash(哈希),list(列表),set(集合)及zset(sorted set:有序集合)。
新接手的项目,偶尔会出现账不平的问题。之前的技术老大临走时给的解释是:排查了,没找到原因,之后太忙就没再解决,可能是框架的原因……
基于Redis使用分布式锁在当今已经不是什么新鲜事了。本篇文章主要是基于我们实际项目中因为redis分布式锁造成的事故分析及解决方案。
基于 Redis 使用分布式锁在当今已经不是什么新鲜事了。本篇文章主要是基于我们实际项目中因为 Redis 分布式锁造成的事故分析及解决方案。
本篇文章主要是基于我们实际项目中因为redis分布式锁造成的事故分析及解决方案。我们项目中的抢购订单采用的是分布式锁来解决的,有一次,运营做了一个飞天茅台的抢购活动,库存100瓶,但是却超卖了100瓶!要知道,这个地球上飞天茅台的稀缺性啊!!!
基于Redis使用分布式锁在当今已经不是什么新鲜事了。本篇文章主要是基于我们实际项目中因为Redis分布式锁造成的事故分析及解决方案。
随着业务发展的需要,原单机部署的系统被演化成分布式集群系统后,由于分布式系统多线程、多进程并且分布在不同机器上,这将使原单机部署情况下的并发控制锁策略失效,单纯的 Java API 并不能提供分布式锁的能力。为了解决这个问题就需要一种跨 JVM 的互斥机制来控制共享资源的访问,这就是分布式锁要解决的问题!
我们今天来看看这个 Redis 的看门狗机制,毕竟现在还是有很多是会使用 Redis 来实现分布式锁的,我们现在看看这个 Redis 是怎么实现分布式锁的,然后我们再来分析这个 Redis 的看门狗机制,如果没有这个机制,很多使用 Redis 来做分布式锁的小伙伴们,经常给导致死锁。
使用Redis做K-V存储,一定要注意过期时间的把控,任何K-V的存储都要设置过期时间,不管多长时间。一般在封装Redis操作工具类时提供默认使用系统公共超时时间的操作API,避免新手在使用时不设置过期时间,导致内存的浪费。另外,通过连接池 Jedis jedis = JedisPool.getResource(); 这样获取Redis连接最好使用try/finally块,并且在finally块中调用 jedis.close(); 将连接归还给连接池,否则将会一直持有连接,很有可能导致在将来的某一时刻报拿不到连接的错。这也是之前某一个同事犯过的错导致生产bug!
项目内引入spring-session-data-redis,配合spring-boot-starter-data-redis
领取专属 10元无门槛券
手把手带您无忧上云