java分布式锁的处理

分布式锁产生的原因是:当多个客户端要同时并发操作数据库时,可能查出来的数据是相同的而后继续写的时候会出现事务方面的问题。如:商品只有一件而后被出售两次,造成数据幻读。

分布式锁的处理方案有:

  使用redis操作,

  使用zookeeper操作,

  数据库方面操作(行锁)

以上所有的操作都是相当于在多个客户端之间放一把锁,类似于线程之间争夺锁的过程。

三种方案比较:

从理解的难易程度角度(从低到高)

  数据库 > 缓存 > Zookeeper

从实现的复杂性角度(从低到高)

  Zookeeper >= 缓存 > 数据库

从性能角度(从高到低)

  缓存 > Zookeeper >= 数据库

从可靠性角度(从高到低)

  Zookeeper > 缓存 > 数据库

具体的实现过程是:

  1.用redis实现

    可以使用redis的set(key,1,30,Nx)命令(在redis 2.6以上版本支持),其中的key可以使用这些客户端都要操作产品的id号去实现。

    那么当解锁时需删除key,删除key要注意避免出现之前线程执行的时间很长导致删除key时删除了后面的客户端key。那么这是要注意设置key-value时一定要将value设置为对应线程的id号而后执行删除对应线程或者客户端的key。

  2.用数据库实现

    一.基于数据库表

      最简单的方式可能就是直接创建一张锁表,当我们要锁住某个方法或资源时,我们就在该表中增加一条记录,想要释放锁的时候就删除这条记录。给某字段添加唯一性约束,如果有多个请求同时提交到数据库的话,数据库会保证只有一个操作可以成功,那么我们就可以认为操作成功的那个线程获得了该方法的锁,可以执行方法体内容。

      缺点:会引入数据库单点、无失效时间、不阻塞、不可重入等问题

    二.基于数据库的排他锁

      如果使用的是MySql的InnoDB引擎,在查询语句后面增加 for update ,数据库会在查询过程中(须通过唯一索引查询)给数据库表增加排他锁,我们可以认为获得排它锁的线程即可获得分布式锁,而后可以通过 connection.commit() 操作来释放锁。

会引入数据库单点、不可重入、无法保证一定使用行锁(部分情况下MySQL自动使用表锁而不是行锁)、排他锁长时间不提交导致占用数据库连接等问题。

  优点:

    直接借助数据库,容易理解。

  缺点:

    •   会引入更多的问题,使整个方案变得越来越复杂
    •   操作数据库需要一定的开销,有一定的性能问题
    •   使用数据库的行级锁并不一定靠谱,尤其是当我们的锁表并不大的时候

  3.使用zookeeper实现

      借用大佬的博客:https://www.cnblogs.com/garfieldcgf/p/6380816.html

原文地址:https://www.cnblogs.com/chaojibaidu/p/10561366.html

时间: 2024-10-09 18:18:45

java分布式锁的处理的相关文章

java 分布式锁 -图解- 秒懂

目录 写在前面 1.1. 分布式锁 简介 1.1.1. 图解:公平锁和可重入锁 模型 1.1.2. 图解: zookeeper分布式锁的原理 1.1.3. 分布式锁的基本流程 1.1.4. 加锁的实现 1.1.5. 释放锁的实现 1.1.1. 分布式锁的应用场景 写在最后 疯狂创客圈 亿级流量 高并发IM 实战 系列 疯狂创客圈 Java 分布式聊天室[ 亿级流量]实战系列之 -26[ 博客园 总入口 ] 写在前面 ? 大家好,我是作者尼恩.目前和几个小伙伴一起,组织了一个高并发的实战社群[疯狂

java 分布式锁

转自:http://www.hollischuang.com/archives/1716 目前几乎很多大型网站及应用都是分布式部署的,分布式场景中的数据一致性问题一直是一个比较重要的话题.分布式的CAP理论告诉我们“任何一个分布式系统都无法同时满足一致性(Consistency).可用性(Availability)和分区容错性(Partition tolerance),最多只能同时满足两项.”所以,很多系统在设计之初就要对这三者做出取舍.在互联网领域的绝大多数的场景中,都需要牺牲强一致性来换取系

Java分布式锁实现详解

在进行大型网站技术架构设计以及业务实现的过程中,多少都会遇到需要使用分布式锁的情况.那么问题也就接踵而至,哪种分布式锁更适合我们的项目? 下面就这个问题,我做了一些分析: 分布式锁现状: 目前几乎很多大型网站及应用都是分布式部署的,分布式场景中的数据一致性问题一直是一个比较重要的话题. 分布式的CAP理论告诉我们"任何一个分布式系统都无法同时满足一致性(Consistency).可用性(Availability)和分区容错性(Partition tolerance),最多只能同时满足两项.&qu

Java分布式锁,搞懂分布式锁实现看这篇文章就对了

随着微处理机技术的发展,人们只需花几百美元就能买到一个CPU芯片,这个芯片每秒钟执行的指令比80年代最大的大型机的处理机每秒钟所执行的指令还多.如果你愿意付出两倍的价钱,将得到同样的CPU,但它却以更高的时钟速率运行.因此,最节约成本的办法通常是在一个系统中使用集中在一起的大量的廉价CPU.所以,倾向于分布式系统的主要原因是它可以潜在地得到比单个的大型集中式系统好得多的性价比.实际上,分布式系统是通过较低廉的价格来实现相似的性能的. 随着互联网的兴起,越来越多的人使用者互联网产品.一般互联网系统

搞懂Java分布式锁实现看这篇文章就对了

前言: 随着微处理机技术的发展,人们只需花几百美元就能买到一个CPU芯片,这个芯片每秒钟执行的指令比80年代最大的大型机的处理机每秒钟所执行的指令还多.如果你愿意付出两倍的价钱,将得到同样的CPU,但它却以更高的时钟速率运行.因此,最节约成本的办法通常是在一个系统中使用集中在一起的大量的廉价CPU.所以,倾向于分布式系统的主要原因是它可以潜在地得到比单个的大型集中式系统好得多的性价比.实际上,分布式系统是通过较低廉的价格来实现相似的性能的. 随着互联网的兴起,越来越多的人使用者互联网产品.一般互

java 分布式锁方案

第一步,自身的业务场景: 在我日常做的项目中,目前涉及了以下这些业务场景: 场景一: 比如分配任务场景.在这个场景中,由于是公司的业务后台系统,主要是用于审核人员的审核工作,并发量并不是很高,而且任务的分配规则设计成了通过审核人员每次主动的请求拉取,然后服务端从任务池中随机的选取任务进行分配.这个场景看到这里你会觉得比较单一,但是实际的分配过程中,由于涉及到了按用户聚类的问题,所以要比我描述的复杂,但是这里为了说明问题,大家可以把问题简单化理解.那么在使用过程中,主要是为了避免同一个任务同时被两

两种分布式锁实现方案(一)

一.为何使用分布式锁?当应用服务器数量超过1台,对相同数据的访问可能造成访问冲突(特别是写冲突).单纯使用关系数据库比如MYSQL的应用可以借助于事务来实现锁,也可以使用版本号等实现乐观锁,最大的缺陷就是可用性降低(性能差).对于GLEASY这种满足大规模并发访问请求的应用来说,使用数据库事务来实现数据库就有些捉襟见肘了.另外对于一些不依赖数据库的应用,比如分布式文件系统,为了保证同一文件在大量读写操作情况下的正确性,必须引入分布式锁来约束对同一文件的并发操作. 二.对分布式锁的要求1.高性能(

spring data redis分布式锁

问题 项目采用spring-boot-starter-data-redis,RedisTemplate中没有同时设置NX和EX的方法,如果使用setIfAbsent()方法也就是NX,再设置过期时间expire()也就是EX,如果在设置EX时失败则会造成死锁.在jedis中提供了同时设置NX和EX的方法,这里通过RedisTemplate的execute()方法获取Jedis. 存在问题 解决方案可以可以参考Redisson 哨兵模式下有问题,Master挂了可能没有复制到Slave导致锁丢失

分布式锁2 Java非常用技术方案探讨之ZooKeeper

前言:       由于在平时的工作中,线上服务器是分布式多台部署的,经常会面临解决分布式场景下数据一致性的问题,那么就要利用分布式锁来解决这些问题.以自己结合实际工作中的一些经验和网上看到的一些资料,做一个讲解和总结.之前我已经写了一篇关于分布式锁的文章: 分布式锁1 Java常用技术方案 .上一篇文章中主要写的是在日常项目中,较为常见的几种实现分布式锁的方法.通过这些方法,基本上可以解决我们日常工作中大部分场景下使用分布式锁的问题.       本篇文章主要是在上一篇文章的基础上,介绍一些虽