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

在分布式场景下，有很多种情况都需要实现最终一致性。在设计远程上下文的领域事件的时候，为了保证最终一致性，在通过领域事件进行通讯的方式中，可以共享存储（领域模型和消息的持久化数据源），或者做全局XA事务（两阶段提交，数据源可分开），也可以借助消息中间件（消费者处理需要能幂等）。通过Observer模式来发布领域事件可以提供很好的高并发性能，并且事件存储也能追溯更小粒度的事件数据，使各个应用系统拥有更好的自治性。

本文主要探讨了一种实现分布式最终一致性的解决方案——采用分布式锁。基于分布式锁的解决方案，比如zookeeper,redis都是相较于持久化（如利用InnoDB行锁，或事务，或version乐观锁）方案提供了高可用性，并且支持丰富化的使用场景。本文通过Java版本的redis分布式锁开源框架——Redisson来解析一下实现分布式锁的思路。

Redis本身支持的事务

http://redisdoc.com/topic/transaction.html

MULTI 、 EXEC 、 DISCARD 和 WATCH 是 Redis 事务的基础，MULTI, EXEC, DISCARD 和 WATCH 命令是Redis事务的基石。一个Redis事务允许一组Redis命令单步执行，并提供下面两个重要保证：一个事务中的所有命令串行执行；要么全部命令要么没有任何命令被处理。具体可参开这篇文章：http://blog.xiping.me/2010/12/transaction-in-redis.html。

事务可以一次执行多个命令，并且带有以下两个重要的保证：

事务是一个单独的隔离操作：事务中的所有命令都会序列化、按顺序地执行。事务在执行的过程中，不会被其他客户端发送来的命令请求所打断。
事务是一个原子操作：事务中的命令要么全部被执行，要么全部都不执行。

EXEC 命令负责触发并执行事务中的所有命令：

如果客户端在使用 MULTI 开启了一个事务之后，却因为断线而没有成功执行 EXEC ，那么事务中的所有命令都不会被执行。另一方面，如果客户端成功在开启事务之后执行 EXEC ，那么事务中的所有命令都会被执行。当使用 AOF 方式做持久化的时候， Redis 会使用单个 write(2) 命令将事务写入到磁盘中。然而，如果 Redis 服务器因为某些原因被管理员杀死，或者遇上某种硬件故障，那么可能只有部分事务命令会被成功写入到磁盘中。如果 Redis 在重新启动时发现 AOF 文件出了这样的问题，那么它会退出，并汇报一个错误。

自己实现Redis分布式锁

根据一些分布式锁相关的文档，开始动手根据redis提供的原子操作进行实现：

http://blog.csdn.net/ugg/article/details/41894947

在其中主要用到了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次，则不再尝试，直接返回falseLOG.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时，不能每次都使用同一个实例，需要在必要的情况化对其执行回收。

http://stackoverflow.com/questions/32429981/jedis-broken-pipe-exception

四月 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 pipeat 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();}

转载于:https://www.cnblogs.com/mmaa/p/5789865.html

基于Redis实现简单的分布式锁相关推荐

springboot mysql行锁_SpringBoot基于数据库实现简单的分布式锁
本文介绍SpringBoot基于数据库实现简单的分布式锁. 1.简介分布式锁的方式有很多种,通常方案有: 基于mysql数据库基于redis 基于ZooKeeper 网上的实现方式有很多,本文主要 ...
基于 Redis + Lua 脚本实现分布式锁，确保操作的原子性
为了保证数据的争用安全,通常要采用锁机制控制. 如果是单应用部署,直接通过synchronized关键字修改方法,就能解决,但是如果是分布式的部署该方法就不能解决这个问题啦,此时就引出了一个分布式锁 ...
redis多服务器共享_基于redis和shedlock实现分布式锁（超简单）
一.背景线上部署了两台服务器,通过nginx轮询的方式进行负载均衡.但是这样存在一个问题同一个用户的session共享问题.你或许会说,使用ipHash模式就可以解决session共享的问题,是的确 ...
基于redis集群的分布式锁redlock
Redis 作者为了解决因为主备切换.脑裂导致 Redis 单集群分布式锁不安全的问题,提出了 redlock 算法,下面是针对文章的翻译和一些自我理解. 一.安全性和可用性保证用三个属性来建模 ...
Redis应用学习——Redis事务与实现分布式锁
2019独角兽企业重金招聘Python工程师标准>>> 1. Redis事务机制 1. 与MySQL等关系数据库相同,Redis中也有事务机制,Redis的事务实质上是命令的集合,但 ...
redisson redlock（基于redisson框架和redis集群使用分布式锁）
一.关于分布式锁的两篇文章文章1 文章2 二.redis分布式锁存在的问题 redis实现分布式锁有很多种方案,比较完善的方案应该是用setNx + lua进行实现.简单实现如下: java代码-加 ...
在 Redis 上实现的分布式锁
由于近排很忙,忙各种事情,还有工作上的项目,已经超过一个月没写博客了,确实有点惭愧啊,没能每天或者至少每周坚持写一篇博客.这一个月里面接触到很多新知识,同时也遇到很多技术上的难点,在这我将对每一个有用 ...
redis set 超时_redis分布式锁3种实现方式对比分析总结
我在这篇文章提到了分布式锁,但没有展开来讲,抛砖引玉,今天就来说说高并发服务编程中的redis分布式锁. 这里罗列出3种redis实现的分布式锁,并分别对比说明各自特点. Redis单实例分布式锁实 ...
Day137-139.尚品汇：制作SKU、商品详情、项目优化：Redis缓存、redssion分布式锁
目录 Day5 制作SKU 1. 制作SKU 2. 多表查询如何写? 3. 制作SKU 4. Thymeleaf Day06 商品详情 1. 获取分类信息 2. 获取最新价格信息 3. 获取销售信息 ...

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

基于Redis实现简单的分布式锁相关推荐

最新文章

热门文章