分布式锁解决方案

分布式锁解决方案:

1.采用数据库乐观锁(不建议,性能不好,需要jdbc连接)

2.基于Redis实现分布式锁(setnx)

3.基于Zookeeper实现分布式锁。Zookeeper是分布式协调工具,在分布式解决方案中使用。

多个客户端(jvm),同时在zk上面创建相同的一个临时节点,因为临时节点路径是保证唯一,只要谁能够创建节点成功,谁就能拿到锁。没有创建成功的节点(jvm)就会进行等待,当释放锁的时候,采用事件通知给客户端重新获取锁的资源。

解决分布式锁的核心思路:在多台服务器集群的情况下,只能保证一个jvm进行操作。

基于redis实现分布式锁

setnx也可以存入key,如果存入key成功返回1,如果key已经存在则返回0,setnx可以做写入key操作,可以获取返回结果(0 | 1)。

多个客户端(jvm),同时在redis上面创建相同的一个key,因为redis的key是不允许重复的,只要谁创建成功就能拿到锁。没有创建key成功的jvm,就会进行等待。

setnx与set区别:

set存入成功之后返回ok,如果存在则覆盖之前的key。

setnx存入成功之后返回1,如果存在则返回0。不会覆盖

在redis中key是唯一的,不允许重复的。

如何释放锁?

在执行完操作的时候,删除操作对应的key,每个对应的key都有自己的有效期。

设置有效期目的:防止产生死锁现象。

原文地址:https://www.cnblogs.com/ming-blogs/p/10486827.html

时间: 2024-09-29 09:38:32

分布式锁解决方案的相关文章

漫谈Redis分布式锁实现

在Redis上,可以通过对key值的独占来实现分布式锁,表面上看,Redis可以简单快捷通过set key这一独占的方式来实现分布式锁,也有许多重复性轮子,但实际情况并非如此.总得来说,Redis实现分布式锁,如何确保锁资源的安全&及时释放,是Redis实现分布式锁的最关键因素.如下逐层分析Redis实现分布式锁的一些过程,以及存在的问题和解决办法. solution 1 :setnx setnx命令设置key的方式实现独占锁 1,#并发线程抢占锁资源setnx an_special_lock

【Zookeeper】分布式锁

一.概述 实现原理 实现代码 一.概述 分布式锁解决方案(目的:为了保证在分布式领域中共享数据安全问题) 数据库实现分布式锁(不推荐.效率特别低) 基于Redis实现分布式锁setNx (非常麻烦考虑死锁.释放问题) .redission分布式锁 基于Zookeeper实现分布式锁(强烈推荐) SpringCloud内置实现全局锁(冷门)实现起来非常简单,使用临时节点释放锁(效率最高).失效时间容易控制 分布式锁(产生的原因:因为服务器产生集群) 在单台服务器上如何生成订号( 保证唯一) UUI

分布式锁三种解决方案

分布式系统中,为了解决执行代码片段/或者任务的唯一性,提出了分布式锁的概念 目前常用的有三种实现方式 1:基于redis的实现 2:基于zk的实现 3:基于db的实现 final DbDistributedLockTemplate template = new DbDistributedLockTemplate();        public void init(){        template.execute("shchgateway", 2000, new Callback(

分布式锁的解决方案

分布式锁的背景,基于数据库.redis.zookeeper实现分布式锁的原理与优缺点你都知道吗?   为什么要分布式锁.分布式锁的实现方式有哪几种.这几种分布式锁实现方式的优缺点有哪些?阅读完本文后你你应该掌握: 基于数据库实现分布式锁具体步骤是什么,优缺点是什么: 基于Redis实现分布式锁具体步骤是什么,优缺点是什么: 基于Zookeeper实现分布式锁具体步骤是什么,优缺点是什么: 分布式锁诞生的背景   我们在开发单机应用的时候,如果需要对某一个共享变量进行多线程同步访问的时候,可以使用

分布式场景中确保线程安全的解决方案,redis实现分布式锁

实际工作中,经常会遇到多线程并发时的类似抢购的功能,本篇描述一个简单的redis分布式锁实现的多线程抢票功能. 直接上代码.首先按照慣例,給出一個错误的示范: 我们可以看看,当20个线程一起来抢10张票的时候,会发生什么事. package com.tiger.utils; public class TestMutilThread { // 总票量 public static int count = 10; public static void main(String[] args) { sta

浅谈分布式锁

分布式一致性问题 首先我们先来看一个小例子: 假设某商城有一个商品库存剩10个,用户A想要买6个,用户B想要买5个,在理想状态下,用户A先买走了6了,库存减少6个还剩4个,此时用户B应该无法购买5个,给出数量不足的提示:而在真实情况下,用户A和B同时获取到商品剩10个,A买走6个,在A更新库存之前,B又买走了5个,此时B更新库存,商品还剩5个,这就是典型的电商"秒杀"活动. 从上述例子不难看出,在高并发情况下,如果不做处理将会出现各种不可预知的后果.那么在这种高并发多线程的情况下,解决

分布式锁1 Java常用技术方案

前言:       由于在平时的工作中,线上服务器是分布式多台部署的,经常会面临解决分布式场景下数据一致性的问题,那么就要利用分布式锁来解决这些问题.所以自己结合实际工作中的一些经验和网上看到的一些资料,做一个讲解和总结.希望这篇文章可以方便自己以后查阅,同时要是能帮助到他人那也是很好的. ===============================================================长长的分割线===================================

使用分布式锁时考虑哪些问题

工作中经常会遇到争抢共享资源的场景,比如用户抢购秒杀商品,如果不对商品库存进行保护,可能会造成超卖的情况.超卖现象在售卖火车票的场景下更加明显,两个人购买到同一天同一辆列车,相同座位的情况是不允许出现的.交易系统中的退款同样如此,由于网络延迟和重复提交极端时间差的情况下,可能会造成同一个用户重复的退款请求.以上无论是超卖,还是重复退款,都是没有对需要保护的资源或业务进行完善的保护而造成的,从设计方面一定要避免这种情况的发生. 本文以退款交易场景入手,引入分布式锁,尝试分析分布式锁需要考虑关注点,

利用多写Redis实现分布式锁原理与实现分析

在我写这篇文章的时候,其实我还是挺纠结的,因为我这个方案本身也是雕虫小技拿出来显眼肯定会被贻笑大方,但是我最终还是拿出来与大家分享,我本着学习的态度和精神,希望大家能够给与我指导和改进方案. 一.关于分布式锁 关于分布式锁,可能绝大部分人都会或多或少涉及到. 我举二个例子: 场景一:从前端界面发起一笔支付请求,如果前端没有做防重处理,那么可能在某一个时刻会有二笔一样的单子同时到达系统后台. 场景二:在App中下订单的时候,点击确认之后,没反应,就又点击了几次.在这种情况下,如果无法保证该接口的幂