Redis高并发分布式锁实战：库存扣减中理解分布式锁的含义

已于 2024-06-30 22:12:12 修改
阅读量115 收藏 1
点赞数 1
文章标签： redis 分布式 数据库
于 2024-06-30 21:22:32 首次发布
原文链接：https://blog.csdn.net/qq_43631716/article/details/118510581?spm=1001.2014.3001.5506
版权

一、分布式锁场景

1、互联网秒杀

2、抢优惠券

3、接口幂等性校验

二、扣减库存实战

1、不加锁版本

	<parent>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-parent</artifactId>
        <version>2.3.0.RELEASE</version>
        <relativePath/> <!-- lookup parent from repository -->
    </parent>
    <modelVersion>4.0.0</modelVersion>


    <dependencies>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-web</artifactId>
        </dependency>

        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-data-redis</artifactId>
        </dependency>

        <dependency>
            <groupId>org.apache.commons</groupId>
            <artifactId>commons-pool2</artifactId>
        </dependency>

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

server:
  port: 8080

spring:
  redis:
    database: 0
    timeout: 3000
    host: 192.168.131.171
    port: 6380


package com.jihu.redis;

import org.redisson.Redisson;
import org.redisson.config.Config;
import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.context.annotation.Bean;

@SpringBootApplication
public class RedisApplication {
    public static void main(String[] args) {
        SpringApplication.run(RedisApplication.class, args);
    }
	
	// 注意要注入redisson 否则会出错
    @Bean
    public Redisson redisson() {
        Config config = new Config();
        config.useSingleServer().setAddress("redis://192.168.131.171:6380").setDatabase(0);
        return (Redisson) Redisson.create(config);
    }
}

直接上代码，我们模拟一个扣减库存的简单场景。
【初始版本】

package com.jihu.redis.lock;

import org.redisson.Redisson;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.data.redis.core.StringRedisTemplate;
import org.springframework.web.bind.annotation.RequestMapping;

@RestController
public class StockController {

    @Autowired
    private Redisson redisson;

    @Autowired
    private StringRedisTemplate stringRedisTemplate;


    /**
     * 模拟减库存
     * @return ""
     */
    @RequestMapping("/deduct_stock")
    public String deductStock() {
		// 从redis获取库存数量
        int stock = Integer.parseInt(stringRedisTemplate.opsForValue().get("stock"));
        // 如果库存数量大于0
        if (stock > 0) {
            int realStock = stock -1;

            stringRedisTemplate.opsForValue().set("stock", realStock + "");
            System.out.println("扣减成功，剩余库存：" + realStock + "");
        } else { // 如果库存数量小于0
            System.out.println("扣减失败，库存不足！");
        }

        return "end";
    }
}

这样扣减库存的代码，如果我们直接部署到生产环境，会不会出问题？

我们来分析一下，假如现在是高并发的场景，用户需要秒杀抢一些商品。
问题分析
当大量请求同时去执行从Redis获取数据这一行代码的时候：

/ 从redis获取库存数量，此时值设置为50
int stock = Integer.parseInt(stringRedisTemplate.opsForValue().get("stock"));

此时由于我们没有任何的同步措施，这些请求都会直接从Redis中获取数据，查询到的结果自然就都是50了。

然后判断49大于0，然后都减1，库存剩余都是49.

然后都调用下面的代码将库存设置到Redis中，并且设置的值都是49.

stringRedisTemplate.opsForValue().set("stock", realStock + "");

但是这样显然不对呀！如果我是5个请求同时进来，都执行了减库存，库存应该是45呀，现在竟然还是49了！这样就会产生超卖的问题！

2、改进：加JVM锁

我们从上面的代码中分析得知，之所以会发生超卖，是因为我们读取Redis库存、扣减库存和将扣减后库存设置到Redis中的这些操作不是原子的，所以导致了超卖问题的产生。
【改进方案一：加JVM锁】
我们可以给以上操作库存的的操作加锁，从而实现原子性操作，这样应该可以避免超卖问题吧！于是乎，我们使用Synchronized来加锁：

package com.jihu.redis.lock;

import org.redisson.Redisson;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.data.redis.core.StringRedisTemplate;
import org.springframework.web.bind.annotation.RequestMapping;

@RestController
public class StockController {

    @Autowired
    private Redisson redisson;

    @Autowired
    private StringRedisTemplate stringRedisTemplate;


    /**
     * 模拟减库存
     * @return ""
     */
    @RequestMapping("/deduct_stock")
    public String deductStock() {
    	// 将操作库存的操作放到同步块中
        synchronized (this) {
            // 从redis获取库存数量
            int stock = Integer.parseInt(stringRedisTemplate.opsForValue().get("stock"));
            // 如果库存数量大于0
            if (stock > 0) {
                int realStock = stock -1;

                stringRedisTemplate.opsForValue().set("stock", realStock + "");
                System.out.println("扣减成功，剩余库存：" + realStock + "");
            } else { // 如果库存数量小于0
                System.out.println("扣减失败，库存不足！");
            }

        }
                
        return "end";
    }
}

分析，这样当多个请求执行进来的时候，线程会原子性的执行同步块中的扣减库存操作，可以防止超卖问题的产生。
问题分析
这样的加锁处理，在单机环境下，确实没什么问题，可以防止超卖情况的发生。

但是，现在的互联网公司基本都是集群架构，后端会存在多个服务实例。如果我们还是这样来使用JVM级别的锁，还能防止超卖情况的发生吗？

显然是不能的。因为JVM锁只能锁住同一个JVM进程中的线程，分布式集群架构下，请求往往是跨多个JVM进程的。

如下图，如果有两个tomcat同时去Redis查库存，Synchronized同步块只能锁住自己JVM中的并发请求，那另一台JVM中的请求是无法锁住的。这样依然会产生，多个请求同时去Redis查库存的情况。查询后发现都是50，都减去一个库存，然后都把49写入到Redis中，这样就产生了超卖的问题。
在这里插入图片描述
那在这样分布式的场景下，我们又该如何的解决超卖问题的？
此时我们需要一把分布式锁！

何为分布式锁，就是可以锁住不同JVM进程的锁，可以使用Redis、zookeeper等实现。原理就是，多个JVM都可以或都需要访问这些第三方中间件，这样Redis或zooKeeper就相当于一个管理者，可以对不同的JVM请求进行管理。这样就达到了管理多个JVM中请求的功能了。
超卖测试
1、我们先启动端口为8080的服务；
2、修改端口为8090，然后修改IDEA，在Allow parallel run打钩，这样基于可以启动多个服务实例了，只是运行在不同端口。我们启动8080和8090的服务；
在这里插入图片描述

# 配置Redis分发（我使用的是windows本机的nginx）
    upstream redislock {
	server 127.0.0.1:8080 weight=1;
	server 127.0.0.1:8090 weight=1;
    }

    server {
	listen       80;
        server_name  localhost;

	 location / {
		root html;
		index index.html index.htm;
		proxy_pass http://redislock;
        }
    }

4、配置好之后，确保执行http://localhost/deduct_stock之后，8080和8090都可以接收到转发的请求：

在这里插入图片描述
在这里插入图片描述

5、随后我们使用jmeter进行压测准备：
我们配置200个请求，为了模拟高并发，在0s内发完；并且持续4轮；即总共会压800个请求。

压测地址：http://localhost/deduct_stock

6、开始压测

等待压测成功后，我们来分别查看8080和8090两个服务的日志。

我们来思考：如果两个日志打印出的 剩余库存的值有相同的，那么就以为着可能会发生超卖！

首先看8080的日志：

然后看8090的日志：

很明显的看到，两个日志中的剩余库存出现了大量相同的数字，这意味着已经发生了超卖的情况！！！

3、改进：加分布式锁

【改进方案二：加分布式锁】

三、Redis分布式锁实现

1、Setnx实现分布式锁

【setnx基础版本】存在问题！

package com.jihu.redis.lock;

import org.redisson.Redisson;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.data.redis.core.StringRedisTemplate;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RestController;

@RestController
public class StockController {

    @Autowired
    private Redisson redisson;

    @Autowired
    private StringRedisTemplate stringRedisTemplate;


    /**
     * 模拟减库存
     * @return ""
     */
    @RequestMapping("/deduct_stock")
    public String deductStock() {
        String lockKey = "lockKey";

        // setIfAbsent 相当于jedis.setnx(key, value)操作
        /**
         * setnx(lockKey, value):
         *
         *      如果这个lockKey在Redis中是已经存在的，则这条命令不做任何操作，返回false
         *      如果这个lockey不存在于Redis中，则设置成功，并返回true
         *
         *  此时如果多个请求来执行这个命令，会在Redis中排队，此时只会有一个请求成功设置了lockKey并返回true.
         *  生育的请求查询发现这个lockKey已经存在了，会直接返回false，不进行任何操作
         */
        Boolean result = stringRedisTemplate.opsForValue().setIfAbsent(lockKey, "xiaoyan");

        // ========= setnx 竞争锁失败 ==========
        if (!result) {
            return "{code: 10001, message:请重新再试！}";
        }

        // ========== setnx 竞争锁成功 =======

        // 从redis获取库存数量
        int stock = Integer.parseInt(stringRedisTemplate.opsForValue().get("stock"));
        // 如果库存数量大于0
        if (stock > 0) {
            int realStock = stock -1;
            // 相当于jedis.set(key, value)
            stringRedisTemplate.opsForValue().set("stock", realStock + "");
            System.out.println("扣减成功，剩余库存：" + realStock + "");
        } else { // 如果库存数量小于0
            System.out.println("扣减失败，库存不足！");
        }

        // 成功扣减库存后的请求，需要释放这个lockKey
        stringRedisTemplate.delete(lockKey);

        return "end";
    }
}

我们这样使用setnx命令来实现Redis分布式锁，现在只会有一个请求使用setnx设置lockKey成功，然后执行扣减库存操作，然后删除lockKey. 剩余的请求竞争失败的会直接返回false。

那现在这样还存在其他问题吗？大家思考一下？如果执行扣减库存的时候抛出异常了呢？这样lockKey的锁岂不是永远都不会被释放了？

如果服务宕机了？该怎么删除lockKey呢 ?

所以说对于上面的问题，我们必须优化一下：
1、使用finally块来删除lockKey;
2、给setnx设置的lockKey添加过期时间。
【setnx升级版本】依然存在问题！

package com.jihu.redis.lock;

import org.redisson.Redisson;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.data.redis.core.StringRedisTemplate;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RestController;

@RestController
public class StockController {

    @Autowired
    private Redisson redisson;

    @Autowired
    private StringRedisTemplate stringRedisTemplate;


    /**
     * 模拟减库存
     * @return ""
     */
    @RequestMapping("/deduct_stock")
    public String deductStock() {
        String lockKey = "lockKey";

        try {
            // setIfAbsent 相当于jedis.setnx(key, value)操作
            /**
             * setnx(lockKey, value):
             *
             *      如果这个lockKey在Redis中是已经存在的，则这条命令不做任何操作，返回false
             *      如果这个lockey不存在于Redis中，则设置成功，并返回true
             *
             *  此时如果多个请求来执行这个命令，会在Redis中排队，此时只会有一个请求成功设置了lockKey并返回true.
             *  生育的请求查询发现这个lockKey已经存在了，会直接返回false，不进行任何操作
             */
            // Redis内部会原子性的保证设置value和设置过期时间同时成功。
            Boolean result = stringRedisTemplate.opsForValue().setIfAbsent(lockKey, "xiaoyan", 10, TimeUnit.SECONDS);
            // 添加过期时间，防止服务宕机后无法删除

            // 这是错误的设置过期的方式！！！如果服务还没执行到这行就宕机了，依然会无法释放锁！Redis过期时间一定要在set数据的时候就设置！！！
            // stringRedisTemplate.expire(lockKey, 10, TimeUnit.SECONDS);

            // ========= setnx 竞争锁失败 ==========
            if (!result) {
                return "{code: 10001, message:请重新再试！}";
            }

            // ========== setnx 竞争锁成功 =======

            // 从redis获取库存数量
            int stock = Integer.parseInt(stringRedisTemplate.opsForValue().get("stock"));
            // 如果库存数量大于0
            if (stock > 0) {
                int realStock = stock -1;
                // 相当于jedis.set(key, value)
                stringRedisTemplate.opsForValue().set("stock", realStock + "");
                System.out.println("扣减成功，剩余库存：" + realStock + "");
            } else { // 如果库存数量小于0
                System.out.println("扣减失败，库存不足！");
            }
        } finally { // 防止异常导致锁无法释放！！！
            // 成功扣减库存后的请求，需要释放这个lockKey
            stringRedisTemplate.delete(lockKey);
        }

        return "end";
    }
}

注意，设置过期时间的时候，一定要和set值一起设置，让Redis原子性的去执行这个两个命令！

注意这个自动过期的时间设置，我们现在设置的是10s，即如果超过10s没有释放，Redis会自动释放。
我们这样设置完，好像各种情况都考虑到了！

那么，大家仔细再思考，是否还存在其他问题呢？

在一般的软件公司下，这样确实可以应对并发减库存的问题。

那么问题来了，在大型互联网公司中，如果此时的并发量非常大，大家想有没有可能存在这样的问题。我的一个请求成功竞争到了lockKey, 但是在执行扣减库存的业务的时候由于某些原因，导致执行的时间超过了10s.

这时候，Redis会自动释放这个lockKey的锁，但是我的这个请求并没有执行完扣减库存的业务呀。这时候其他请求也进入到扣减库存的业务代码中来。此时第一个请求还没来得及将扣减后的库存写回到Redis中，新的请求却体检查询了Redis数据库，这样一来，直接导致库存数量不准确，一定会产生超卖!!!

并且，如果第二个请求执行的过程中，第一个请求恰好执行15s结束，执行finally块中的删除lockKey，这样就会把第二个请求加的lockKey给删除掉。这样就会出现一个问题，某个请求的锁好像加成功了，一会又失败了。这样已经存在了很多问题…

我们来分析此时的问题，因为第一个请求扣减库存的时间太长，导致加的锁过期，从而新的请求可以加锁成功，而新的请求执行扣减库存的过程中，第一个请求恰好执行完，然后再finally块中释放了锁。但事实上，这个锁是第二个请求加的，不再是第一个请求的锁了。因为第一个请求的锁已经因为过期被Redis自己释放了。

总结来说：现在的问题是，不同的请求都可以操作同一个lockKey。所以，我们要思考，是否可以给每一个请求一个不同的lockkey，从而使得每一个请求只能自己加锁、解锁。

我们只是只是用了一个lockKey，那么我们现在可以针对每一个请求都生成一个lockKey:

【setnx最终版本】可用

 @RequestMapping("/deduct_stock")
    public String deductStock() {
        String lockKey = "lockKey";
        String clientId = UUID.randomUUID().toString();
        try {
            // setIfAbsent 相当于jedis.setnx(key, value)操作
            /**
             * setnx(lockKey, value):
             *
             *      如果这个lockKey在Redis中是已经存在的，则这条命令不做任何操作，返回false
             *      如果这个lockey不存在于Redis中，则设置成功，并返回true
             *
             *  此时如果多个请求来执行这个命令，会在Redis中排队，此时只会有一个请求成功设置了lockKey并返回true.
             *  生育的请求查询发现这个lockKey已经存在了，会直接返回false，不进行任何操作
             */
            // Redis内部会原子性的保证设置value和设置过期时间同时成功。
            // clientId: 每一个请求都生成一个clientId, 这样只有自己才能释放锁 
            Boolean result = stringRedisTemplate.opsForValue().setIfAbsent(lockKey, clientId, 30, TimeUnit.SECONDS);
            // 添加过期时间，防止服务宕机后无法删除

            // 这是错误的设置过期的方式！！！如果服务还没执行到这行就宕机了，依然会无法释放锁！Redis过期时间一定要在set数据的时候就设置！！！
            // stringRedisTemplate.expire(lockKey, 30, TimeUnit.SECONDS);

            // ========= setnx 竞争锁失败 ==========
            if (!result) {
                return "{code: 10001, message:请重新再试！}";
            }

            // ========== setnx 竞争锁成功 =======

            // 从redis获取库存数量
            int stock = Integer.parseInt(stringRedisTemplate.opsForValue().get("stock"));
            // 如果库存数量大于0
            if (stock > 0) {
                int realStock = stock -1;
                // 相当于jedis.set(key, value)
                stringRedisTemplate.opsForValue().set("stock", realStock + "");
                System.out.println("扣减成功，剩余库存：" + realStock + "");
            } else { // 如果库存数量小于0
                System.out.println("扣减失败，库存不足！");
            }
        } finally { // 防止异常导致锁无法释放！！！
            // 成功扣减库存后的请求，需要释放这个lockKey
            // 如果lockKey对应的value是本次请求设置的value，才允许释放锁！
            
            // 下面这个代码也有问题！！！判断和删除不是原子的，并发场景可能存在问题：
            // t1加锁成功，执行到get时候 ，判断equals为true，
            // 刚好这个时候发生了expire，已经自动释放了锁。然后，t2加锁成功。
            // t1 由于判断了equals,  执行del。实际上释放了t2加的锁
            if (clientId.equals(stringRedisTemplate.opsForValue().get(lockKey))) {
                stringRedisTemplate.delete(lockKey);
            }
        }

        return "end";
    }

使用Redis的setnx来实现分布式锁的话，这样的解决方案是可行的，一些公司也有这样使用分布式锁的！

存在的的问题：这样虽然解决了不同请求释放锁的问题，但是依然可能导致bug. 如果第一个请求要执行15s, 而超过了10s的过期时间，导致锁被自动释放，其他的请求就会进入扣减库存的代码。如果第一个请求恰好扣减完库存，还没来得及将结果写入到Redis中的时候，新的请求查询了库存。这样可能出现库存拆卖的问题。所以，这个过期时间设置为多少，需要我们自己权衡好。

那么，还有没有更好的解决方案呢？

现在存在的问题的原因是我们不太能确定下起来，这个过期时间到底设置为多少比较合适！

设置的太长，如果服务宕机没有在finally块中释放锁的话，这样就需要等待很久的时间才能释放锁。

设置的太短，可能会因为第一个请求时间异常导致锁被提前释放，而扣减库存的业务还没执行完，从而导致超卖问题！

归根结底，是这超时时间的设置问题！

在当前认知中，似乎已经没有更好的解决方案了。我们需要打破认知，引入新的概念了：font color=“red”> 锁续命/font>。
锁续命（也称看门狗）

Boolean result = stringRedisTemplate.opsForValue().setIfAbsent(lockKey, clientId, 30, TimeUnit.SECONDS);

假如我们现在设置锁的过期时间是30s，我们可以再后台启动一个子线程去执行一个定时器，每过1 / 3的过期时间后（30 / 3 = 10 s）就去检查一下当前的锁状态：

如果锁还没有被释放（说明依然在执行扣减库存的业务代码），那么我们就重新给这个请求设置锁的过期时间为30s。从而让这个请求可以持续的持有锁。

如果发现锁已经被释放了，那么就直接结束这个子线程。

这个锁续命的想法非常之巧妙，但是在高并发的场景下让我们自己来实现，势必不是那么容易。

这个一个简单的分布式锁，我们就踩了很多坑，如果没有高并发经验的人来写，那后果更不可想象。

所以，市面上现在已经存在一些技术来帮助我们解决Redis分布式锁的问题了。

我们用的比较多的是Redisson. 下面我们来学习一下Redeisson.

2、使用Redisson实现分布式锁

依赖：

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

在这里插入图片描述
在这里插入图片描述
准备工作做好之后，我们就来开始使用Redisson实现分布式锁吧

package com.jihu.redis.lock;

import org.redisson.Redisson;
import org.redisson.api.RLock;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.data.redis.core.StringRedisTemplate;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RestController;

@RestController
public class StockForRedissonController {

    @Autowired
    private Redisson redisson;

    @Autowired
    private StringRedisTemplate stringRedisTemplate;


    /**
     * 模拟减库存
     * @return ""
     */
    @RequestMapping("/deduct_stock")
    public String deductStock() {
        String lockKey = "lockKey";

        // 获取到redisson锁对象
        RLock redissonLock = redisson.getLock(lockKey);
        try {
            // ========= 添加redisson锁并实现锁续命功能 =============
            /**
             *  主要执行一下几个操作
             *
             *  1、将localKey设置到Redis服务器上，默认过期时间是30s
             *  2、每10s触发一次锁续命功能
             */
            redissonLock.lock();

            // ======== 扣减库存业务员开始 ============
            // 从redis获取库存数量
            int stock = Integer.parseInt(stringRedisTemplate.opsForValue().get("stock"));
            // 如果库存数量大于0
            if (stock > 0) {
                int realStock = stock -1;
                // 相当于jedis.set(key, value)
                stringRedisTemplate.opsForValue().set("stock", realStock + "");
                System.out.println("扣减成功，剩余库存：" + realStock + "");
            } else { // 如果库存数量小于0
                System.out.println("扣减失败，库存不足！");
            }
            // ======== 扣减库存业务员结束 ============
        } finally { // 防止异常导致锁无法释放！！！
            // ============= 释放redisson锁 ==========
            redissonLock.unlock();
        }

        return "end";
    }
}

就这！！！！！？？？？

就这么几行代码就搞定了分布式锁？

不得不说，这个Redisson有点东西呀。我们自己及使用setnx的时候要考虑各种情况，而且稍不注意，就会出错。

一枚来自底层的努力奋斗程序员
关注
  • 1
    点赞
  • 踩
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
Redis——Redis分布式锁原理与实战
庄小焱
03-13 622
分布式应用进行逻辑处理时经常会遇到并发问题。比如一个操作要修改用户的状态，修改状态需要先读出用户的状态，在内存里进行修改，改完了再存回去。如果这样的操作同时进行了，就会出现并发问题，因为读取和保存状态这两个操作不是原子的。（ Wiki 解释：所谓原子操作是指不会被线程调度机制打断的操作；这种操作一旦开始，就一直运行到结束，中间不会有任何 context switch 线程切换。）这个时候就要使用到分布式锁来限制程序并发的执行。
Redis架构实战：高并发情况下并发扣减库存
m0_58554082的博客
08-13 1980
相信大家从网上学习项目大部分人第一个项目都是电商，生活中时时刻刻也会用到电商APP，例如淘宝，京东等。做技术的人都知道，电商的业务逻辑简单，但是大部分电商都会涉及到高并发高可用，对并发和对数据的处理要求是很高的。这里我今天就讲一下高并发情况下是如何扣减库存的？ 我们对扣减库存所需要关注的技术点如下： 当前剩余的数量大于等于当前需要扣减的数量，不允许超卖 对于同一个数据的数量存在用户并发扣减，需要保证并发的一致性 需要保证可用性和性能，性能至少是秒级 一次的扣减包含多个目标数量 当次扣减有多个数量
分布式锁和mysql事物扣库存_利用redis实现分布式事务锁,解决高并发环境下库存扣减...
weixin_33242934的博客
01-28 268
利用redis实现分布式事务锁,解决高并发环境下库存扣减发布时间：2018-02-27 14:22,浏览次数：432, 标签：redis问题描述:某电商平台,首发一款新品手机,每人限购2台,预计会有10W的并发,在该情况下,如果扣减库存,保证不会超卖解决方案一利用数据库锁机制,对记录进行锁定,再进行操作SELECT * from goods where ID =1 for update; UPDA...
Redis 实现高并发库存扣减方案
最新发布
zquwei的博客
07-09 647
redis，库存
redis 扣减库存
面朝大海，春暖花开
01-26 282
使用 redisTemplate 操作。如果该商品库存不存在，返回。，说明库存不足，返回。
基于Redis商品库存扣减方案
程序员小潘
02-22 1538
电商业务场景下，对于库存的处理是比较重要的，表面上看只是对商品库存数做一个扣减操作，但是要做到不超卖、不少卖，同时还要保证高性能，却是一件非常困难的事。
redis 库存扣减
weixin_43839681的博客
05-06 1785
前言 本文内容基于单机redis操作，暂不探讨集群及数据分片。 分别采用redis 数字increment和 list的push pop操作扣减库存。 1.不加锁操作 1.1 数据准备 设置key=100，向list push100条简单数据作为库存。示例： redisTemplate.opsForValue().set("key","100"); for (int i = 0;i < 1...
分布式锁和mysql事物扣库存_浅谈库存扣减和锁
weixin_36225248的博客
02-05 295
先说场景:物品W现在库存剩余1个, 用户P1,P2同时购买.则只有1人能购买成功.(前提是不允许超卖)秒杀也是类似的情况, 只有1件商品,N个用户同时抢购,只有1人能抢到..这里不谈秒杀设计,不谈使用队列等使请求串行化,就谈下怎么用锁来保证数据正确.常见的实现方案有以下几种:1.代码同步, 例如使用 synchronized ,lock 等同步方法2.不查询,直接更新 update table...
【高并发】高并发分布式锁架构解密，不是所有的锁都是分布式锁！！
01-26
【高并发】高并发分布式锁架构解密，不是所有的锁都是分布式锁！！在高并发的系统设计中，正确地处理并发访问是至关重要的。本文主要探讨了如何在高并发环境中解决资源竞争问题，特别是通过引入分布式锁来确保线程...
基于Redis+Lua实现分布式锁模拟秒杀扣减库存业务(非常详细，良心解析)
奋斗的IT青年
09-22 6639
最近和几个小伙伴聊了聊基于Redis的分布式锁实现秒杀扣减库存业务的一些技术细节，刚好最近钻研了一段时间，本篇内容通过1个详细的案例，把这个实现方案作个记录，当做自己对知识的总结积累，同时也欢迎广大开发者朋友一起交流，学习，大家可以留言讨论，原创写作不易，请勿喷，如果觉得有用，不要忘了关注点赞哦。 前言 首先我们可以讨论以下4个问题： 1、什么是分布式锁 ？ 要说起分布式锁，首先要提到与分布式锁相对应的是线程锁、进程锁。 线程锁：主要用来给方法、代码块加锁。当某个方法或代码使用锁，在同一时刻仅有一
利用redis实现分布式事务锁,解决高并发环境下库存扣减
热门推荐
xiongyouqiang的博客
02-27 3万+
问题描述: 某电商平台,首发一款新品手机,每人限购2台,预计会有10W的并发,在该情况下,如果扣减库存,保证不会超卖 解决方案一 利用数据库锁机制,对记录进行锁定,再进行操作 SELECT * from goods where ID =1 for update; UPDATE goods set stock = stock - 1; 利用排它锁将并行转化为串行操作,但该方案的性...
全面理解并发编程之分布式架构下Redis、ZK分布式锁的前世今生
lt_xiaodou的博客
10-05 425
本篇中从单机锁的隐患 -> 分布式架构下的安全问题引出 -> 分布式锁的实现推导 -> redis实现分布式锁 -> redis实现分布式锁的细节问题分析 -> redisson框架实现及其连锁应用与源码分析 -> zookeeper实现分布式锁 -> zookeeper实现原理这条思路依次剖析了分布式锁的前世今生，总的一句话概括分布式锁的核心原理就是：在多个进程中所有线程都可见的区域实现了互斥量而已。最后再来说说Redis与Zookeeper实现的区别与项目中如何抉择？
Redis学习笔记：Redis扣减库存案例 逐步优化
RuaaaHaHa的博客
10-10 817
例如有三个用户并发执行，三个用户都获取了stock的值后进入if判断语句，现在三者获得的stock都是初始值298，那么该业务执行后stock的值是297，但是实际上还多卖给了两个用户，出现超卖现象。：出现当前获取锁的用户需要的执行时间大于分布式锁的超时时间，自动释放后，下一个用户获取分布式锁，而当前用户会执行释放锁的操作，就把下一个用户获取的锁释放了，以此类推。：将分布式锁的value设置为UUID，每次删除之前，判断当前锁的value与执行删除锁逻辑的线程的UUID是否相同，不同则等待，相同则删除。
Redis 实现高并发下的库存扣减（高频面试）
IT技术精选文摘
08-03 1732
若有收获,请记得分享和转发哦简历中使用电商当项目经验已经非常普遍了，不管你是包装的还是真实的，起码要能讲清楚电商中常见的问题，比如库存的操作怎么防止商品被超卖。在日常开发中有很多地方都有类似扣减库存的操作，比如电商系统中的商品库存，抽奖系统中的奖品库存等。解决方案常见的解决方案有以下三种：使用 mysql 数据库，使用一个字段来存储库存，每次扣减库存去更新这个字段。还是使...
Redis分布式锁实战(库存扣减 Setnx、Redisson及底层源码、RedLock)
Jay112011的博客
02-18 3461
Redis高并发分布式锁实战(Setnx、Redisson及底层源码、RedLock)：库存扣减中理解分布式锁的含义
分布式事务--01 redis实现分布式事务锁,解决高并发环境下库存扣减
envinfo2012的博客
06-19 395
某东新发一块新机,每人限购2台,预计会有10W的并发,在该情况下,如果扣减库存,保证不会超卖 解决方案一 利用数据库锁机制,对记录进行锁定,再进行操作 SELECT * from goods where ID =1 for update; UPDATE goods set stock = stock - 1; 解决方案二 使用时间戳字段实现数据更新，避免强制性的数据独占 比如goods表新增一个 version字段 select * from goods where ID=1 update g
Redis实现库存扣减操作
竹林幽深
08-24 1138
具体关于lua脚本的内容使用请移步至 redis命令参考–Script脚本 ： http://doc.redisfans.com/script/index.html 在日常开发中有很多地方都有类似扣减库存的操作，比如电商系统中的商品库存，抽奖系统中的奖品库存等。 解决方案 使用mysql数据库，使用一个字段来存储库存，每次扣减库存去更新这个字段。 还是使用数据库，但是将库存分层多份存到多条记录里面，扣减库存的时候路由一下，这样子增大了并发量，但是还是避免不了大量的去访问数据库来更新库存。 将库存放到re
用redis实现分布式事务锁,解决高并发环境下库存扣减
weixin_43370079的博客
06-25 2255
问题描述: 某电商平台,首发一款新品手机,每人限购2台,预计会有10W的并发,在该情况下,如果扣减库存,保证不会超卖 解决方案一 利用数据库锁机制,对记录进行锁定,再进行操作 SELECT * from goods where ID =1 for update; UPDATE goods set stock = stock - 1; 1 2 利用排它锁将并行转化为串行操作,但该方案的性能和用户体验...
springboot整合redisson实现分布式锁，实现商品下单库存扣减功能
Xmi2599的博客
05-24 3419
对于库存更新这样的场景，我们需要考虑对同一条记录进行更新并记录所可能出现的问题，比如读未提交造成的记录错乱。，也就是说，锁的过期时间到了，但是业务没处理完，那么redisson会自动给redis中的目标key延长超时时间，这在Redisson中称之为 Watch Dog 看门狗机制。如果不使用专业的分布式定时工具（如quartz），而是简单地依赖定时器来做定时任务，那么会有并发执行的情况，可能造成某些问题。锁资源被多个线程获取，成功则执行lua脚本，保存数据到redis数据库。（2）分布式锁工具类。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值