从0~1实现分布式锁演变过程

最新推荐文章于 2024-01-24 16:36:55 发布
最新推荐文章于 2024-01-24 16:36:55 发布
阅读量202 收藏
点赞数 1
分类专栏： 点点滴滴 SpringBoot 2.0 专栏 微服务
版权声明：本文为博主原创文章，遵循 CC 4.0 BY 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/Websphere_zxf/article/details/119671928
版权

从0~1实现分布式锁演变过程

工作中用到分布式锁的场景并不多(行业性质决定)，后来在一幅漫画中了解到分布式锁的实现思路对我影响挺深的，在经过一系列的查阅资料后终于决定从0到1将分布式锁的过程演变一次。

点这儿获取完整代码

首先看一段模仿减库存代码：

    @GetMapping("/getStock")
    public String getStock() {
        int stock = Integer.parseInt(stringRedisTemplate.opsForValue().get("stock"));
        if (stock > 0) {
            int realStock = stock - 1;
            stringRedisTemplate.opsForValue().set("stock", realStock + "");
            System.out.println("扣减成功，剩余库存：" + realStock);
        } else {
            System.out.println("扣减失败，库存不足");
        }
        return "操作成功！";
    }

以上代码很简单，就是从redis中取库存并判断是否大于0(有库存)，有库存则减少1，最后更新redis中的库存。
以上代码在单线程中是没有问题，但如果在多线程的情况下就会出现重复减库存现象，这里我用的是JMeter模仿高并发场景，参数配置及压测结果如下：

线程组配置，参数如图所示
在这里插入图片描述
请求参数配置，http://www.com.zxf/getStock 是我本地自己用Nginx 配置的反向代理和负载均衡
在这里插入图片描述
Nginx主要配置如下

#配置上游服务器网关端口集群
	upstream	backServer{
		server	127.0.0.1:8081 weight=1;
		server	127.0.0.1:8082 weight=1;
	}

    server {
        listen       80;
        server_name  www.com.zxf;
        #charset koi8-r;
        #access_log  logs/host.access.log  main;
        location / {
            #root   html;
			proxy_pass http://backServer/;
            index  index.html index.htm;
        }
       
    }

压测结果
在这里插入图片描述
如上图所示，在多线程情况下会出现重复减库存现象，出现这种情况通常做法是加锁，加锁的目的是为了在多线程情况下每次只能有一个线程去减库存，等到该线程处理完释放锁后其他线程再继续执行，修改后的代码如下：

    @GetMapping("/getStock")
    public String getStock() {
        synchronized (this){
            int stock = Integer.parseInt(stringRedisTemplate.opsForValue().get("stock"));
            if (stock > 0) {
                int realStock = stock - 1;
                stringRedisTemplate.opsForValue().set("stock", realStock + "");
                System.out.println("扣减成功，剩余库存：" + realStock);
            } else {
                System.out.println("扣减失败，库存不足");
            }
        }
        return "操作成功！";
    }

压测结果如下：

扣减成功，剩余库存：49
扣减成功，剩余库存：48
扣减成功，剩余库存：47
扣减成功，剩余库存：46
扣减成功，剩余库存：45
扣减成功，剩余库存：44
扣减成功，剩余库存：43
扣减成功，剩余库存：42
扣减成功，剩余库存：41
扣减成功，剩余库存：40
扣减成功，剩余库存：39
扣减成功，剩余库存：38
扣减成功，剩余库存：37
扣减成功，剩余库存：36
扣减成功，剩余库存：35
扣减成功，剩余库存：34
扣减成功，剩余库存：33
扣减成功，剩余库存：32
扣减成功，剩余库存：31
扣减成功，剩余库存：30
扣减成功，剩余库存：29
扣减成功，剩余库存：28
扣减成功，剩余库存：27
扣减成功，剩余库存：26
扣减成功，剩余库存：25
扣减成功，剩余库存：24
扣减成功，剩余库存：23
扣减成功，剩余库存：22
扣减成功，剩余库存：21
扣减成功，剩余库存：20
扣减成功，剩余库存：19
扣减成功，剩余库存：18
扣减成功，剩余库存：17
扣减成功，剩余库存：16
扣减成功，剩余库存：15
扣减成功，剩余库存：14
扣减成功，剩余库存：13
扣减成功，剩余库存：12
扣减成功，剩余库存：11
扣减成功，剩余库存：10
扣减成功，剩余库存：9
扣减成功，剩余库存：8
扣减成功，剩余库存：7
扣减成功，剩余库存：6
扣减成功，剩余库存：5
扣减成功，剩余库存：4
扣减成功，剩余库存：3
扣减成功，剩余库存：2
扣减成功，剩余库存：1
扣减成功，剩余库存：0
扣减失败，库存不足
扣减失败，库存不足

如上，在使用synchronized后解决了重复减库存现象，但是又引来了新的问题：synchronized作用是在JVM层，也就是在单体中生效，而我们的服务布署一般都是多节点分布式布署，举个例子，假如布署两个结点，每个结点中都有各自的JVM，而synchronized只是在自己结点中的JVM生效，同样也会出现问题，为了验证上面的问题，我启动两个服务，端口分别是8081和8082，验证如下，

8081端口

  
  .   ____          _            __ _ _
 /\\ / ___'_ __ _ _(_)_ __  __ _ \ \ \ \
( ( )\___ | '_ | '_| | '_ \/ _` | \ \ \ \
 \\/  ___)| |_)| | | | | || (_| |  ) ) ) )
  '  |____| .__|_| |_|_| |_\__, | / / / /
 =========|_|==============|___/=/_/_/_/
 :: Spring Boot ::                (v2.4.0)

2021-08-13 12:26:35.416  INFO 7540 --- [           main] com.zxf.DistributeApplication            : Starting DistributeApplication using Java 1.8.0_45 on DESKTOP-KB6ANRO with PID 7540 (H:\IDEA\workspace\distribute\target\classes started by Administrator in H:\IDEA\workspace\distribute)
2021-08-13 12:26:35.420  INFO 7540 --- [           main] com.zxf.DistributeApplication            : No active profile set, falling back to default profiles: default
2021-08-13 12:26:36.596  INFO 7540 --- [           main] .s.d.r.c.RepositoryConfigurationDelegate : Multiple Spring Data modules found, entering strict repository configuration mode!
2021-08-13 12:26:36.600  INFO 7540 --- [           main] .s.d.r.c.RepositoryConfigurationDelegate : Bootstrapping Spring Data Redis repositories in DEFAULT mode.
2021-08-13 12:26:36.628  INFO 7540 --- [           main] .s.d.r.c.RepositoryConfigurationDelegate : Finished Spring Data repository scanning in 7 ms. Found 0 Redis repository interfaces.
2021-08-13 12:26:37.583  INFO 7540 --- [           main] o.s.b.w.embedded.tomcat.TomcatWebServer  : Tomcat initialized with port(s): 8081 (http)
2021-08-13 12:26:37.604  INFO 7540 --- [           main] o.apache.catalina.core.StandardService   : Starting service [Tomcat]
2021-08-13 12:26:37.604  INFO 7540 --- [           main] org.apache.catalina.core.StandardEngine  : Starting Servlet engine: [Apache Tomcat/9.0.39]
2021-08-13 12:26:37.745  INFO 7540 --- [           main] o.a.c.c.C.[Tomcat].[localhost].[/]       : Initializing Spring embedded WebApplicationContext
2021-08-13 12:26:37.745  INFO 7540 --- [           main] w.s.c.ServletWebServerApplicationContext : Root WebApplicationContext: initialization completed in 2148 ms
2021-08-13 12:26:38.908  INFO 7540 --- [           main] o.s.s.concurrent.ThreadPoolTaskExecutor  : Initializing ExecutorService 'applicationTaskExecutor'
2021-08-13 12:26:39.415  INFO 7540 --- [           main] o.s.b.w.embedded.tomcat.TomcatWebServer  : Tomcat started on port(s): 8081 (http) with context path ''
2021-08-13 12:26:39.431  INFO 7540 --- [           main] com.zxf.DistributeApplication            : Started DistributeApplication in 4.953 seconds (JVM running for 5.868)
2021-08-13 12:30:45.410  INFO 7540 --- [io-8081-exec-59] o.a.c.c.C.[Tomcat].[localhost].[/]       : Initializing Spring DispatcherServlet 'dispatcherServlet'
2021-08-13 12:30:45.426  INFO 7540 --- [io-8081-exec-59] o.s.web.servlet.DispatcherServlet        : Initializing Servlet 'dispatcherServlet'
2021-08-13 12:30:45.426  INFO 7540 --- [io-8081-exec-59] o.s.web.servlet.DispatcherServlet        : Completed initialization in 0 ms
扣减成功，剩余库存：49
扣减成功，剩余库存：48
扣减成功，剩余库存：47
扣减成功，剩余库存：46
扣减成功，剩余库存：45
扣减成功，剩余库存：44
扣减成功，剩余库存：43
扣减成功，剩余库存：42
扣减成功，剩余库存：41
扣减成功，剩余库存：40
扣减成功，剩余库存：39
扣减成功，剩余库存：38
扣减成功，剩余库存：37
扣减成功，剩余库存：36
扣减成功，剩余库存：35
扣减成功，剩余库存：34
扣减成功，剩余库存：33
扣减成功，剩余库存：32
扣减成功，剩余库存：31
扣减成功，剩余库存：30
扣减成功，剩余库存：29
扣减成功，剩余库存：28
扣减成功，剩余库存：26
扣减成功，剩余库存：25
扣减成功，剩余库存：24
扣减成功，剩余库存：23
扣减成功，剩余库存：22
扣减成功，剩余库存：21
扣减成功，剩余库存：20
扣减成功，剩余库存：21
扣减成功，剩余库存：20
扣减成功，剩余库存：19
扣减成功，剩余库存：18
扣减成功，剩余库存：16
扣减成功，剩余库存：15
扣减成功，剩余库存：14
扣减成功，剩余库存：14
扣减成功，剩余库存：13
扣减成功，剩余库存：12
扣减成功，剩余库存：11
扣减成功，剩余库存：10
扣减成功，剩余库存：9
扣减成功，剩余库存：7
扣减成功，剩余库存：6
扣减成功，剩余库存：5
扣减成功，剩余库存：4
扣减成功，剩余库存：3
扣减成功，剩余库存：2
扣减成功，剩余库存：1
扣减成功，剩余库存：0
扣减失败，库存不足

8082端口

   .   ____          _            __ _ _
 /\\ / ___'_ __ _ _(_)_ __  __ _ \ \ \ \
( ( )\___ | '_ | '_| | '_ \/ _` | \ \ \ \
 \\/  ___)| |_)| | | | | || (_| |  ) ) ) )
  '  |____| .__|_| |_|_| |_\__, | / / / /
 =========|_|==============|___/=/_/_/_/
 :: Spring Boot ::                (v2.4.0)

2021-08-13 12:26:52.642  INFO 5456 --- [           main] com.zxf.DistributeApplication            : Starting DistributeApplication using Java 1.8.0_45 on DESKTOP-KB6ANRO with PID 5456 (H:\IDEA\workspace\distribute\target\classes started by Administrator in H:\IDEA\workspace\distribute)
2021-08-13 12:26:52.648  INFO 5456 --- [           main] com.zxf.DistributeApplication            : No active profile set, falling back to default profiles: default
2021-08-13 12:26:53.802  INFO 5456 --- [           main] .s.d.r.c.RepositoryConfigurationDelegate : Multiple Spring Data modules found, entering strict repository configuration mode!
2021-08-13 12:26:53.806  INFO 5456 --- [           main] .s.d.r.c.RepositoryConfigurationDelegate : Bootstrapping Spring Data Redis repositories in DEFAULT mode.
2021-08-13 12:26:53.834  INFO 5456 --- [           main] .s.d.r.c.RepositoryConfigurationDelegate : Finished Spring Data repository scanning in 7 ms. Found 0 Redis repository interfaces.
2021-08-13 12:26:54.907  INFO 5456 --- [           main] o.s.b.w.embedded.tomcat.TomcatWebServer  : Tomcat initialized with port(s): 8082 (http)
2021-08-13 12:26:54.926  INFO 5456 --- [           main] o.apache.catalina.core.StandardService   : Starting service [Tomcat]
2021-08-13 12:26:54.926  INFO 5456 --- [           main] org.apache.catalina.core.StandardEngine  : Starting Servlet engine: [Apache Tomcat/9.0.39]
2021-08-13 12:26:55.091  INFO 5456 --- [           main] o.a.c.c.C.[Tomcat].[localhost].[/]       : Initializing Spring embedded WebApplicationContext
2021-08-13 12:26:55.092  INFO 5456 --- [           main] w.s.c.ServletWebServerApplicationContext : Root WebApplicationContext: initialization completed in 2254 ms
2021-08-13 12:26:56.296  INFO 5456 --- [           main] o.s.s.concurrent.ThreadPoolTaskExecutor  : Initializing ExecutorService 'applicationTaskExecutor'
2021-08-13 12:26:56.709  INFO 5456 --- [           main] o.s.b.w.embedded.tomcat.TomcatWebServer  : Tomcat started on port(s): 8082 (http) with context path ''
2021-08-13 12:26:56.725  INFO 5456 --- [           main] com.zxf.DistributeApplication            : Started DistributeApplication in 5.081 seconds (JVM running for 6.427)
2021-08-13 12:30:45.894  INFO 5456 --- [nio-8082-exec-1] o.a.c.c.C.[Tomcat].[localhost].[/]       : Initializing Spring DispatcherServlet 'dispatcherServlet'
2021-08-13 12:30:45.894  INFO 5456 --- [nio-8082-exec-1] o.s.web.servlet.DispatcherServlet        : Initializing Servlet 'dispatcherServlet'
2021-08-13 12:30:45.910  INFO 5456 --- [nio-8082-exec-1] o.s.web.servlet.DispatcherServlet        : Completed initialization in 16 ms
扣减成功，剩余库存：37
扣减成功，剩余库存：32
扣减成功，剩余库存：30
扣减成功，剩余库存：27
扣减成功，剩余库存：26
扣减成功，剩余库存：24
扣减成功，剩余库存：22
扣减成功，剩余库存：19
扣减成功，剩余库存：17
扣减成功，剩余库存：15
扣减成功，剩余库存：13
扣减成功，剩余库存：11
扣减成功，剩余库存：8
扣减成功，剩余库存：7
扣减成功，剩余库存：6
扣减成功，剩余库存：5
扣减成功，剩余库存：3
扣减成功，剩余库存：1
扣减成功，剩余库存：0
扣减失败，库存不足

如上结果显示，在两结点中公有37、32、30等库存字样，从而说明上面的问题是存在的。

那么怎么解决这个问题呢，首先，还是加锁的概念，加锁的目的是为了在多线程情况下每次只能有一个线程去减库存，只不过这儿的锁换成了redis锁而非JVM中的同步锁。

修改后的代码如下：

    @GetMapping("/getStock")
    public String getStock() {
        String lockKey = "lockKey_stock";
        try {
            //setIfAbsent 相当于setnx(key, vlue),只有在key不存在时设置key的值，key存在时返回false
            Boolean result = stringRedisTemplate.opsForValue().setIfAbsent(lockKey, "lockKey_stock");
            stringRedisTemplate.expire(lockKey, 10, TimeUnit.SECONDS);
            if (!result) {
                return "error";
            }
            int stock = Integer.parseInt(stringRedisTemplate.opsForValue().get("stock"));
            if (stock > 0) {
                int realStock = stock - 1;
                stringRedisTemplate.opsForValue().set("stock", realStock + "");
                System.out.println("扣减成功，剩余库存：" + realStock);
            } else {
                System.out.println("扣减失败，库存不足");
            }
        } finally {
            // 释放锁
            stringRedisTemplate.delete(lockKey);
        }
        return "操作成功！";
    }

如上所示代码，有没有什么问题呢，或者有什么可以改进的地方，答案是肯定的，首先，
问题一：先加锁，再设置过期时间就有问题，如果加锁成功后由于不可抗力因素(redis宕机)没有成功设置过期时间，那么就会一致处于被锁状态；
问题二：默认过期时间为10秒，假设线程一进来处理业务需要15秒，10秒后redis自动释放锁，这时线程二进来一看没有锁，于是线程二加锁，这时恰好第一个线程业务处理完释放锁，注意：此时线程一释放的是线程二的锁，以此类推会导致锁失效问题。

针对以上两点问题代码优化如下：

    @GetMapping("/getStock")
    public String getStock() {
        String lockKey = "lockKey_stock";
        String threadId = String.valueOf(Thread.currentThread().getId());
        try {
            //setIfAbsent 相当于setnx(key, vlue),只有在key不存在时设置key的值，key存在时返回false
            /*Boolean result = stringRedisTemplate.opsForValue().setIfAbsent(lockKey, "lockKey_stock");
            stringRedisTemplate.expire(lockKey, 10, TimeUnit.SECONDS);*/
            // 在添加锁的同时设置过期时间
            Boolean result = stringRedisTemplate.opsForValue().setIfAbsent(lockKey, threadId, 10, TimeUnit.SECONDS);
            if (!result) {
                return "error";
            }
            int stock = Integer.parseInt(stringRedisTemplate.opsForValue().get("stock"));
            if (stock > 0) {
                int realStock = stock - 1;
                stringRedisTemplate.opsForValue().set("stock", realStock + "");
                System.out.println("扣减成功，剩余库存：" + realStock);
            } else {
                System.out.println("扣减失败，库存不足");
            }
        } finally {
            // 释放锁,解决锁失效问题
            if (threadId.equals(stringRedisTemplate.opsForValue().get(lockKey))) {
                stringRedisTemplate.delete(lockKey);
            }
        }
        return "操作成功！";
    }

针对问题1解决方案：在添加锁的同时设置过期时间，这时一个原子性操作，要么同时成功，要么同时失败；
针对问题2解决方案：在加锁时获取当前线程ID，在释放时判断当前线程跟加锁的线程是否一致。

再仔细考虑一下，设置的锁的默认过期时间是10秒，但是如果处理业务代码超过10秒依然会释放，能不能做到让程序自动去判断是否要给当前锁延续寿命，
思路：后台写一个定时器定时监控当前线程是否还持有锁，如果持有说明业务逻辑还没有处理完，自动更新过期时间！

其实对于以上的一切Redisson框架已经帮我们全部实现了！其流程如图所示
在这里插入图片描述

引入依赖

<dependency>
	<groupId>org.redisson</groupId>
	<artifactId>redisson</artifactId>
	<version>3.6.5</version>
</dependency>

实现代码

@GetMapping("/getStock")
public String getStock() {
  String lockKey = "lockKey_stock";
  RLock redissonLock = redisson.getLock(lockKey);
  try {
      redissonLock.lock(10, TimeUnit.SECONDS);
      int stock = Integer.parseInt(stringRedisTemplate.opsForValue().get("stock"));
      if (stock > 0) {
          int realStock = stock - 1;
          stringRedisTemplate.opsForValue().set("stock", realStock + "");
          System.out.println("扣减成功，剩余库存：" + realStock);
      } else {
          System.out.println("扣减失败，库存不足");
      }
  } finally {
      // 释放锁,解决锁失效问题
      redissonLock.unlock();
  }
  return "操作成功！";
}

如上，使用Redisson实现分布式锁只需要简单的三步就可以做好上面写的一切，而且还更加完美。

获取锁：RLock redissonLock = redisson.getLock(lockKey);
设置初始过期时间：redissonLock.lock(10, TimeUnit.SECONDS);
释放锁：redissonLock.unlock();

新时代~农民工
关注
专栏目录
RedisTemplate 分布式锁演变，Redission 分布式锁实现
xiaofs3223的博客
07-03 138
基本原理阶段一阶段二阶段三阶段四阶段五-最终形态4) Redisson我们可以同时去一个地方“占坑”，如果占到，就执行逻辑。否则就必须等待，直到释放锁。“占坑”可以去redis，可以去数据库，可以去任何大家都能访问的地方。等待可以自旋的方式。 问题：1、setnx占好了位，业务代码异常或者程序在页面过程中宕机。没有执行删除锁逻辑，这就造成了死锁解决：设置锁的自动过期，即使没有删除，会自动删除 问题：1、setnx设置好，正要去设置过期时间，宕机。又死锁了。解决：设置过期时间和占位必须是原子的。red
Redis高级-分布式锁的演变过程
蔚蓝
01-30 317
分布式锁，即分布式系统中的锁。在单体应用中我们通过锁解决的是控制共享资源访问的问题，而分布式锁，就是解决了分布式系统中控制共享资源访问的问题。与单体应用不同的是，分布式系统中竞争共享资源的最小粒度从线程升级成了进程。
分布式锁演进过程
w4477516的博客
08-25 214
这里写自定义目录标题欢迎使用Markdown编辑器新的改变功能快捷键合理的创建标题，有助于目录的生成如何改变文本的样式插入链接与图片如何插入一段漂亮的代码片生成一个适合你的列表创建一个表格设定内容居中、居左、居右SmartyPants创建一个自定义列表如何创建一个注脚注释也是必不可少的KaTeX数学公式新的甘特图功能，丰富你的文章UML 图表FLowchart流程图导出与导入导出导入 欢迎使用Ma...
分布式锁的进化过程
程序员小董的专栏
02-20 1384
使用setnx 来作为锁的底层实现 case1 拿到锁 执行代码 但是如果此时服务器宕机就完了 case2 拿到锁 设置超时时间 然后执行代码 存在两个问题 2.1 设置超时时间和获取锁 得原子性完成 2.2 如果超时时间到了 任务还没有完成 怎么办？ 2.2 存在两个问题 假如 a 先获得锁 设置十秒过期 a运行完成需要15s b在第十秒拿到了锁 此时两个线程都拥有锁（第一个问题） 等到第15s，a删除了锁，此时b相当于没有锁的保护了，谁想进来就都能进来（第...
redis setnx 过期时间_科普：Redis 分布式锁进化史（解读 + 缺陷分析）
weixin_39773215的博客
12-04 671
点击上方“Java知音”，选择“置顶公众号”技术文章第一时间送达！来源：点我达技术http://tech.dianwoda.com/各个版本的Redis分布式锁V1.0V1.1 基于[GETSET]V2.0 基于[SETNX]V3.0V3.1分布式Redis锁：Redlock总结近两年来微服务变得越来越热门，越来越多的应用部署在分布式环境中，在分布式环境中，数据一致性是一直以来需要关注并...
java 从零实现属于你的 redis 分布式锁
10-17 491
点赞再看，已成习惯。 为什么需要分布式锁 在 jdk 中为我们提供了加锁的方式： （1）synchronized 关键字 （2）volatile + CAS 实现的乐观锁 （3）ReadWriteLock 读写锁 （4）ReenTrantLock 可重入锁 等等，这些锁为我们变成提供极大的便利性，保证在多线程的情况下，保证线程安全。 但是在分布式系统中，上面的锁就统统没用了。 我们想要解决分布式系统中的并发问题，就需要引入分布式锁的概念。 上一节我们已经对分布式锁原理进行了详细讲解，参见： red.
redis分布式锁演变过程
学习达人的日记本
11-01 373
最近研究了下redis分布式锁,分享下演变过程，怎么一步步实现抗高并发的分布式锁 ** 首先看下单线程的代码，未加分布式锁的情况如下： ** @Override public String secKill() { String goodsId = "666666"; String goodsCountStr = redisTemplate.opsForValue().get(goodsId); int goodsCount = Integer.pars
细说分布式锁实现
等一杯咖啡的博客
09-20 496
Redis分布式锁 获取锁 当一个进程前来请求分布式锁，首先通过 setnx 来尝试获取锁，如果获取锁成功，OK，设置好过期时间，可以返回去干自己事情了。如果 setnx 没获取成功，事情麻烦了，说明肯定有人拿到锁了。这个时候就要看看拿锁的进程是不是该让让位了——比较当前时间和锁里设置的过期时间（通过 get 查看），如果没到过期时间，好吧，自己就只好放弃或者继续等待了。如果发现当前时间已经超过过...
从单机锁到分布式锁的演进
最新发布
qq_31287229的博客
01-24 938
通过使用锁，我们可以有效地管理并发操作，确保数据的一致性和完整性。然而，使用锁时也需要注意避免死锁和性能问题。因此，选择合适的锁类型、合理地设计加锁和解锁的逻辑、以及必要的异常处理是至关重要的。在开头生成工单编码的场景中，单号是先要获取当前最大条目然后+1,看似很简单，在页面上操作是如果多个人同时创建，同时进去这这块代码，如果没用锁机制，就导致多人创建的单号都是一样的。
分布式锁演进过程.doc
08-25
最初尝试使用Redis实现分布式锁时，通常采用`setnx`命令来获取锁。`setnx`命令是Redis提供的一个设置键值对的方法，如果键不存在则设置成功并返回1，如果键已存在则返回0。具体的伪代码实现如下： ```plaintext // ...
探讨Redis分布式锁解决优惠券拼抢问题
m0_71777195的博客
08-19 1278
分布式锁是控制不同系统之间访问共享资源的一种锁实现，如果不同的系统或同一个系统的不同主机之间共享了某个资源时，往往需要互斥来防止彼此干扰来确保数据一致性。本文通过单机环境本地锁->集群环境锁演变->分布式锁的延伸，深入浅出的介绍了不同方式实现分布式锁的问题和改进之处，通过不同的例子详细展开说明，并且分析了Redission分布式锁的实现原理和实现。
经验总结：如何实现分布式锁？使用指南
m0_56835488的博客
04-21 198
今年互联网形式依旧严峻，再次爆发几次大规模裁员潮。我决定把这篇文章分享出来帮助那些对前途感到迷茫的朋友。 在猎头的眼里，我已不是根正苗红的程序员。何为根正苗红？计算机专业毕业，从毕业起就从事特定方向的开发工作，这才是猎头眼中的香饽饽。 毕业之后的那段岁月，可以用悲惨形容，每当和人提起，我总会有点自嘲的说“睡过凌晨一点的办公室，吃过凌晨三点的便利店，做过凌晨五点的首班车”。但是回头想想，我却要感谢那不堪的经历，让我找到了适合自己的方向。 作为技术人员，我一直有个疑问，什么是你引以为傲的资本？面对已经来临..
分布式锁演变思路（基于Redis）
记录
12-10 240
简易版本 最基本的要求就是保证唯一性。 这里的唯一性是指线程A加锁后，线程B对同一把锁加锁不会产生新的锁数据。 那么redis里面的过程就是：使用redis命令setnx(set if not exist)，即只能被一个客户端占坑,如果redis实例存在唯一键，如果再想在该key上设置值，就会被拒绝。业务执行成功后，执行 del命令删除锁。 增加过期时间 上面这个版本存在的问题就是，释放锁需要客户端的操作，如果此时客户端突然挂了，就没有释放锁的操作了，其他客户端想要重新加锁就加不了了。所以利用redis的
看透springboot
loveyuenan5296的博客
10-18 448
1、前言 相比动态语言，使用Spring开发的java项目开发起来显得格外笨重：繁多的配置、低下的开发效率、复杂的部署流程以及第三方技术较大的集成难度，都让Spring的开发广受诟病，在这样的环境下，Springboot应运而生，它强调“习惯优于配置”的理念，将spring及常用的第三方库习惯性的配置交由springboot来自动配置，让java项目快速运行起来，使用springboot很容...
集群redis哨兵模式连接方式，解决database不生效问题（附源码）
热门推荐
cucgyfjklx的博客
05-20 1万+
集群redis哨兵模式连接方式，解决database不生效问题（附源码）
spring 整合redis
climber
01-28 1405
java之redis篇(spring-data-redis整合)   redis的知识：官网 1，利用spring-data-redis整合 项目使用的pom.xml： project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance
几种常见的JVM调优场景
上善若泪
02-08 359
文章目录1 JVM调优1.1 问题引入1.2 cpu占用过高1.2.1 排查死循环1.3 死锁1.4 内存泄漏1.4.1 模拟内存泄露1.4.2 mat分析dump1.4.3 线上分析 转载于：https://mp.weixin.qq.com/s/HpMQOZwhIGCSpJemBiICdA 1 JVM调优 1.1 问题引入 最近很多小伙伴跟我说，自己学了不少JVM的调优知识，但是在实际工作中却不知道何时对JVM进行调优。今天，我就为大家介绍几种JVM调优的场景。 在阅读本文时，假定大家已经了解了运行时的数
springboot项目整合redis报错
weixin_44735825的博客
11-23 4444
今天尝试在项目中整合redis实现缓存的功能，结果当整合完启动项目时，报了一下的错误： 2020-11-23 18:06:29.286 INFO 8864 --- [ restartedMain] c.f.c.CertificateCollectorApplication : Starting CertificateCollectorApplication using Java 1.8.0_191 on FXR-DESKTOP-54BJKDF with PID 8864 (E:\文档\idea_p
springboot设置运行内存_spring boot应用优化，6s内启动，内存减半
weixin_27885845的博客
01-14 1350
前言taptap-developer是一个spring boot框架驱动的纯Grpc服务，所以，只用了四步，移除了web和spring cloud相关的模块后，启动速度就稳稳的保持在了6s内。除了启动速度提升外，在服务待机状态下，内存锐减了50%左右，从500M左右的内存占用，缩减到了250M不到。分析日志日志是一个应用的门面，在未深入了解一个应用的架构前，通过启动的日志输出基本可以分析出这个应用...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值