基于Redis实现简单的分布式锁

最新推荐文章于 2023-11-04 16:43:18 发布
最新推荐文章于 2023-11-04 16:43:18 发布
阅读量441 收藏
点赞数
分类专栏： redis 分布式锁
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/clamaa/article/details/70046416
版权
 
在分布式场景下，有很多种情况都需要实现最终一致性。在设计远程上下文的领域事件的时候，为了保证最终一致性，在通过领域事件进行通讯的方式中，可以共享存储（领域模型和消息的持久化数据源），或者做全局XA事务（两阶段提交，数据源可分开），也可以借助消息中间件（消费者处理需要能幂等）。通过Observer模式来发布领域事件可以提供很好的高并发性能，并且事件存储也能追溯更小粒度的事件数据，使各个应用系统拥有更好的自治性。 
 
本文主要探讨了一种实现分布式最终一致性的解决方案——采用分布式锁。基于分布式锁的解决方案，比如zookeeper,redis都是相较于持久化（如利用InnoDB行锁，或事务，或version乐观锁）方案提供了高可用性，并且支持丰富化的使用场景。 本文通过Java版本的redis分布式锁开源框架——Redisson来解析一下实现分布式锁的思路。
 
Redis本身支持的事务
 
 
MULTI 、 EXEC 、 DISCARD 和 WATCH 是 Redis 事务的基础，MULTI, EXEC, DISCARD 和 WATCH 命令是Redis事务的基石。一个Redis事务允许一组Redis命令单步执行，并提供下面两个重要保证：一个事务中的所有命令串行执行；要么全部命令要么没有任何命令被处理。具体可参开这篇文章：http://blog.xiping.me/2010/12/transaction-in-redis.html。
 
事务可以一次执行多个命令， 并且带有以下两个重要的保证：
 
  1. 事务是一个单独的隔离操作：事务中的所有命令都会序列化、按顺序地执行。事务在执行的过程中，不会被其他客户端发送来的命令请求所打断。
  2. 事务是一个原子操作：事务中的命令要么全部被执行，要么全部都不执行。
 
EXEC 命令负责触发并执行事务中的所有命令：
 
如果客户端在使用 MULTI 开启了一个事务之后，却因为断线而没有成功执行 EXEC ，那么事务中的所有命令都不会被执行。另一方面，如果客户端成功在开启事务之后执行 EXEC ，那么事务中的所有命令都会被执行。当使用 AOF 方式做持久化的时候， Redis 会使用单个 write(2) 命令将事务写入到磁盘中。然而，如果 Redis 服务器因为某些原因被管理员杀死，或者遇上某种硬件故障，那么可能只有部分事务命令会被成功写入到磁盘中。如果 Redis 在重新启动时发现 AOF 文件出了这样的问题，那么它会退出，并汇报一个错误。
 
自己实现Redis分布式锁
 
根据一些分布式锁相关的文档，开始动手根据redis提供的原子操作进行实现：
 
 
在其中主要用到了Redis中的两条原子命令：
 
1.SETNX key value
  
Available since 1.0.0.
Time complexity: O(1)
Set key to hold string value if key does not exist. In that case, it is equal to SET. When key already holds a value, no operation is performed. SETNX is short for "SET if Not eXists".
Return value
Integer reply, specifically:
1 if the key was set
0 if the key was not set
 
 
 
2. GETSET key value
  
起始版本：1.0.0
时间复杂度：O(1)
 
自动将key对应到value并且返回原来key对应的value，返回之前的旧值，如果之前Key不存在将返回nil。
 
 
 
摘自文章： http://www.jeffkit.info/2011/05/994/，其中有一节： GETSET的妙用，其中有一段：
  
上一个经验虽说可以解决这条数据该“插入还是更新”的问题，但需要知道当前操作是否针对某数据的首次操作的需求还不少。例如我的程序会在不同时间接收到同一条消息的不同分片信息包，我需要在收到该消息的首个信息包（发送是无序的）时做些特殊处理。
 
早些时候的做法是为消息在MongoDB维护一个状态对象，有信息包来的时候就走“上锁->检查消息状态->根据状态决定做不做特殊操作->解锁” 这个流程，虽然同事已经把锁的粒度控制得非常细了，但有锁的程序遇上多实例部署就歇了。
 
Redis的GETSET是解决这个问题的终极武器，只需要把当前信息包的唯一标识对指定的状态属性进行一次GETSET操作，再判断返回值是否为空则知道是否首次操作。GETSET替我们把两次读写的操作封装成了原子操作。
 
 
实现逻辑
 
获取redis针对某个锁的时候，需要根据lockKey区进行setnx（set not exist，顾名思义，如果key值为空，则正常设置，返回1，否则不会进行设置并返回0）操作，如果设置成功，表示已经获得锁，否则并没有获取锁。
 
如果没有获得锁，去Redis上拿到该key对应的值，在该key上我们存储一个时间戳（用毫秒表示，t1），为了避免死锁以及其他客户端占用该锁超过一定时间（5秒），使用该客户端当前时间戳，与存储的时间戳作比较。
 
如果没有超过该key的使用时限，返回false，表示其他人正在占用该key，不能强制使用；如果已经超过时限，那我们就可以进行解锁，使用我们的时间戳来代替该字段的值。使用getset来设置该字段的值，getset可以返回设置完成之前的值t2，如果t2!=t1，说明在getset之前已经有其他线程已经设置了该字段，事实上，我们还是没有获得该锁（已经被其他人抢占）。但是这会造成一定的数据错误，因为我们已经用getset设置了一个新的时间戳（并不是抢占该锁的客户端设置的时间戳），所幸这样操作的误差比较小可以忽略不计。
 
但是如果在setnx失败后，get该值却无法拿到该字段时，说明在我们操作之前该锁已经被释放，这个时候，最好的办法就是重新执行一遍setnx方法来获取其值以获得该锁。当然，这仍然可能失败，但失败的逻辑与之前的相同。虽然出现这种情况非常少见，但是为了避免每次都出现导致StackOverflowError的错误，设置调用层次。
 
  
public static final int ACQUIRE_LOCK_MAX_ATTEMPTS = 10;
    public static final long EXPIRE_TIME = 5000L;
 
    /**
     * 基于时间戳根据lockKey尝试获取锁，需要与releaseLock成对使用;
     * <p/>使用该方法的前提是必须要保证服务器之间时间同步
     * <p/>如果持有锁的时间超过 #{EXPIRE_TIME}，视为超时，其他客户端可以对其进行重新获取锁的操作
     *
     * @param lockKey - 锁键值，即争夺的资源
     * @return - 当成功获取锁后，返回true，否则返回false；如果没有获取锁，需要客户端进行轮询来尝试获取
     */
    public boolean acquireLock(String lockKey) {
        return acquireLock(lockKey, 0);
    }
 
    private boolean acquireLock(String lockKey, int depth) {
        long setnx = jedis.setnx(lockKey, String.valueOf(System.currentTimeMillis()));
        if (setnx == 1L) {
            //说明客户端已经获得锁
            LOG.info(String.format("lock key : %s is acquired!", lockKey));
            return true;
        } else {
            //此时，该lockKey已经被其他客户端加锁
            String keyTimestamp = jedis.get(lockKey);
            if (keyTimestamp == null) {
                //如果该值已经被清空，就尝试去重新获取
                if (depth == ACQUIRE_LOCK_MAX_ATTEMPTS) {
                    //如果尝试次数超过10次，则不再尝试，直接返回false
                    LOG.info(String.format("lock key : %s exceed max attemps: %s, quit!", lockKey,
                            ACQUIRE_LOCK_MAX_ATTEMPTS));
                    return false;
                }
                return acquireLock(lockKey, depth + 1);
            }
 
            long intervalTime = System.currentTimeMillis() - Long.valueOf(keyTimestamp);
            if (intervalTime < EXPIRE_TIME) {
                //锁在一定时间内并没有超时，获取锁失败
                LOG.info("lock key : %s acquire failed! other client persist this lock!", lockKey);
                return false;
            } else {
                //锁已经超时，尝试执行getset操作，设置当前时间戳
                String getSetTimestamp = jedis.getSet(lockKey, String.valueOf(System.currentTimeMillis()));
                if (getSetTimestamp == null) {
                    //考虑非常特殊的情况，有人释放了锁执行del操作
                    //此时get/set拿到的是nil值，说明已经获得了锁
                    LOG.info(String.format("lock key : %s is acquired! GETSET returns null!", lockKey));
                    return true;
                }
                if (!getSetTimestamp.equals(keyTimestamp)) {
                    //在设置时，说明该锁已经被其他client加上
                    //此时会有对应的副作用，比如
                    LOG.info("lock key : %s acquire failed! other client acquire this lock!", lockKey);
                    return false;
                } else {
                    //锁已更新，可以正常返回
                    LOG.info(String.format("lock key : %s is acquired! origin client is time out!", lockKey));
                    return true;
                }
            }
        }
    }
 
 
释放锁的过程相对来说比较简单，但是我们采用这种方式的话，不能控制什么时候该释放锁，当然也可以采用回调的方式来实现默认释放掉锁，以便于控制释放过程。
 
    
 /**
     * 释放lockKey对应的锁，注意需要与acquireLock成对使用
     * <p/>不能随意对其他人使用的锁进行释放操作
     *
     * @param lockKey
     * @return - 如果释放成功返回true
     */
    public boolean releaseLock(String lockKey) {
        boolean result = jedis.del(lockKey) == 1L;
        LOG.info(String.format("lock key: %s is released!", lockKey));
        return result;
    }
 
 
但这套毕竟是自己实现的，还会有很多漏洞，在github发现了一套开源的实现： https://github.com/mrniko/redisson/wiki，可以对其进行深入研究并应用到我们的系统中，这样系统会更加健壮。
 
在简单对其使用Jmeter进行性能测试，发现库存控制比较好，能够满足实际需求，但测试过程中也遇到了一些问题。
 
我们如果使用这种方式，能否让没有拿到锁的线程能够及时收到通知，重新连接？
 
对于使用的JedisClient时，不能每次都使用同一个实例，需要在必要的情况化对其执行回收。
 
  
四月 28, 2016 5:03:18 下午 org.apache.catalina.core.StandardWrapperValve invoke
严重: Servlet.service() for servlet [springmvc] in context with path [] threw exception [Request processing failed; nested exception is redis.clients.jedis.exceptions.JedisConnectionException: java.net.SocketException: Broken pipe] with root cause
java.net.SocketException: Broken pipe
    at java.net.SocketOutputStream.socketWrite0(Native Method)
    at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:109)
    at java.net.SocketOutputStream.write(SocketOutputStream.java:153)
    at redis.clients.util.RedisOutputStream.flushBuffer(RedisOutputStream.java:52)
    at redis.clients.util.RedisOutputStream.flush(RedisOutputStream.java:213)
    at redis.clients.jedis.Connection.flush(Connection.java:288)
    at redis.clients.jedis.Connection.getBinaryBulkReply(Connection.java:214)
    at redis.clients.jedis.Connection.getBulkReply(Connection.java:205)
    at redis.clients.jedis.Jedis.get(Jedis.java:101)
    at com.api.example.controller.UserController.decrElement(UserController.java:52)
    at sun.reflect.GeneratedMethodAccessor25.invoke(Unknown Source)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:483)
    at org.springframework.web.method.support.InvocableHandlerMethod.doInvoke(InvocableHandlerMethod.java:221)
    at org.springframework.web.method.support.InvocableHandlerMethod.invokeForRequest(InvocableHandlerMethod.java:137)
    at org.springframework.web.servlet.mvc.method.annotation.ServletInvocableHandlerMethod.invokeAndHandle(ServletInvocableHandlerMethod.java:110)
    at org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerAdapter.invokeHandleMethod(RequestMappingHandlerAdapter.java:777)
    at org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerAdapter.handleInternal(RequestMappingHandlerAdapter.java:706)
    at org.springframework.web.servlet.mvc.method.AbstractHandlerMethodAdapter.handle(AbstractHandlerMethodAdapter.java:85)
    at org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:943)
    at org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:877)
    at org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:966)
    at org.springframework.web.servlet.FrameworkServlet.doGet(FrameworkServlet.java:857)
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:620)
    at org.springframework.web.servlet.FrameworkServlet.service(FrameworkServlet.java:842)
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:727)
    at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:303)
    at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208)
    at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52)
    at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:241)
    at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208)
    at org.springframework.web.filter.CharacterEncodingFilter.doFilterInternal(CharacterEncodingFilter.java:88)
    at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107)
    at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:241)
    at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208)
    at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:220)
    at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:122)
    at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:501)
    at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:171)
    at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
    at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:950)
    at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:116)
    at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:408)
    at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1040)
    at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:607)
    at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:314)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
    at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
    at java.lang.Thread.run(Thread.java:745)
 
 
此时就需要使用JedisPool来获取资源，可以避免出现这个问题，注意在最后要回收资源：
  
Jedis jedis = jedisPool.getResource();
        try {
            while (true) {
                String productCountString = jedis.get("product");
                if (Integer.parseInt(productCountString) > 0) {
                    if (acquireLock(jedis, "abc")) {
                        int productCount = Integer.parseInt(jedis.get("product"));
                        System.out.println(String.format("%tT --- Get product: %s", new Date(), productCount));
//                        System.out.println(productCount);
                        jedis.decr("product");
                        releaseLock(jedis, "abc");
                        return "Success";
                    }
                    Thread.sleep(1000L);
                } else {
                    return "Over";
                }
            }
        } finally {
            jedis.close();
        }
 
 
 
clamaa
关注
  • 0
    点赞
  • 踩
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
专栏目录
redis和redisson实现分布式锁
05-26
redis分布式锁demo。包括守护线程的锁延迟过期时间，锁竞争时的循环重试
redis学习笔记
hasijingsi的博客
04-02 899
文章目录Redis基础Redis中的五种数据类型StringHashListSetZsetRedis 数据类型应用场景总结:Java中Redis的使用直接使用jedisssm整合redisSpringBoot整合redis 一直以来用的都是mysql ,直到近期做了一个项目，发现数据的检索奇慢无比，这还是数据量很小的情况下， 由此开始进入redis的世界！ Redis基础 Redis 是 C 语言...
redis配置说明
全力付出
04-16 820
redis配置说明maxmemory设置 redis 能够使用的最大内存。当内存满了的时候，如果还接收到 set 命令，redis 将 先尝试剔除设置过 expire 信息的 key，而不管该 key 的过期时间还没有到达。在删除时， 将按照过期时间进行删除，最早将要被过期的 key 将最先被删除。如果带有 expire 信息 的 key 都删光了，那么将返回错误。这样，redis 将不再接收写请求
jediscluster的maxAttempts的理解
lixia0417mul2的博客
10-12 6621
1.我们知道进行redis配置的时候可以配置maxAttempts参数，那么这个参数的含义是什么呢？ ` return execute(connection); } catch (JedisNoReachableClusterNodeException jnrcne) { throw jnrcne; } catch (JedisConnectionException jce) { // release current connection before recursion releas
基于Redis的分布式锁的简单实现方法
09-09
主要介绍了基于Redis的分布式锁的简单实现方法，Redis官方给出两种思路，小编觉得挺不错的，现在分享给大家，也给大家做个参考。一起跟随小编过来看看吧
基于redis分布式锁实现秒杀功能
01-19
最近在项目中遇到了类似“秒杀”的业务场景，在本篇博客中，我将用一个非常简单的demo，阐述实现所谓“秒杀”的基本思路。 业务场景 所谓秒杀，从业务角度看，是短时间内多个用户“争抢”资源，这里的资源在大部分...
基于 Redis 的分布式锁
01-22
自己整理的如何利用redis实现分布式锁，redis实现分布式锁看这一篇绝对够。
Redis实现分布式锁的方法示例
01-19
锁的本质就是互斥，保证任何时候能有一个客户端持有同一个锁，如果考虑使用redis来实现一个分布式锁，最简单的方案就是在实例里面创建一个键值，释放锁的时候，将键值删除。但是一个可靠完善的分布式锁需要考虑的...
Java三种方式实现redis分布式锁
了迹奇有没
04-28 1万+
一、引入原因 在分布式服务中，常常有如定时任务、库存更新这样的场景。 在定时任务中，如果不使用quartz这样的分布式定时工具，只是简单的使用定时器来进行定时任务，在服务分布式部署中，就有可能存在定时任务并发执行，造成一些问题。 在库存更新这样的场景中，我们服务对数据库同一条记录进行更新，并记录。对记录更新可以使用分布式锁，但对操作进行记录时，可能造成读未提交，造成记录错乱的情况。 在以上的场景中，我们引入了分布式事务锁。 二、分布式锁实现过程中的问题 问题一：异常导致锁没有释放 这个问题形成的原因就是程序
Redis学习笔记（七）jedis超时重试机制注意事项
热门推荐
刘本龙的专栏
12-22 2万+
jedis客户端在创建连接时会设置一个超时，并且会有重试机制。 问题起源在使用jedis客户端的时候，我测试了一下incr命令，该命令在执行过程中是原子的，所以理论上不会出现问题（不论单线程还是多线程）代码如下：/** * incrf: * 将 key 中储存的数字值增一。 如果 key 不存在，那么 key 的值会先被初始化为 0 ，然后再执行 INCR 操作。
Redis分布式锁的正确实现方式（Java版）
zth_killer的博客
06-19 3343
一、什么是分布式锁？ 要介绍分布式锁，首先要提到与分布式锁相对应的是线程锁、进程锁。 线程锁：主要用来给方法、代码块加锁。当某个方法或代码使用锁，在同一时刻仅有一个线程执行该方法或该代码段。线程锁只在同一JVM中有效果，因为线程锁的实现在根本上是依靠线程之间共享内存实现的，比如synchronized是共享对象头，显示锁Lock是共享某个变量（state）。 进程锁：为了控制同一操作系统中多个进程访问某个共享资源，因为进程具有独立性，各个进程无法访问其他进程的资源，因此无法通过synchronized等线程
【Java】三种方案实现 Redis 分布式锁
最新发布
人生苦短，我用python
11-04 4234
三种 Redis 分布式锁的实现方案
Java+Redis：使用java实现分布式锁--redis篇
netyeaxi的专栏
04-04 3939
使用java实现分布式锁-redis篇
Redis分布式锁注解（Java实现）
weixin_47224121的博客
06-07 1753
在项目中遇到了插入重复数据的问题，为了防止并发造成重复数据的插入，故使用加锁，而传统的加锁是单机锁并不适用分布式项目，故采用Redis分布式锁。
springBoot中使用redis实现分布式锁实例demo
qq_28130847的博客
05-17 1328
首先RedisLockUtils工具类完整的Controller完整pom.xml以上是完整服务端下面来写一个程序,多线程异步去模拟大量同时的商品抢购请求 看一下抢购成功的用户数量和库存情况。
java -Redis分布式锁学习
qq_27561019的博客
04-25 884
分布式锁是一种用于分布式系统的锁机制，它能够保证在分布式环境下对共享资源进行互斥访问，防止并发访问时出现数据竞争和不一致问题。在分布式系统中，多个节点可能同时修改共享资源，为了保证数据的正确性和一致性，需要对共享资源进行串行化访问。传统的单节点锁无法满足分布式系统的要求，因此需要使用分布式锁来保证在整个分布式系统中只会有一个节点可以获取到锁，从而保证共享资源的独占性。实现分布式锁的方法有很多种，包括利用数据库、缓存系统等。
Redis学习（八）Java三种方式实现分布式锁
ACGkaka的博客
08-14 3407
Redis学习（八）Java三种方式实现分布式锁
java 基于redis实现的分布式锁工具类
09-21
Java基于Redis实现的分布式锁是一种并发控制的机制，可以确保在分布式环境中只有一个线程能够获得锁并执行关键代码块。以下是一个基本的分布式锁工具类的实现思路： 1. 引入依赖：首先需要引入Redis的Java客户端...

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值