为什么基于redis

因为所有redis的操作（这里指的是key的操作，像备份落盘之类的另算）都是单线程的，所以是线程安全的，但是有一点需要注意，这里线程安全仅仅指的是单个操作，如果有连续性的操作，需要使用lua脚本来保证原子性。

针对秒杀商品库存为一个的情况

比如抢单个红包，类似于美团的抢单等多个用户争抢一个资源的情况，这时我们可以使用redis分布式锁来实现比如 setnx。

setnx

setnx:向Redis中添加一个key，只用当key不存在的时候才添加并返回1，存在则不添加返回0。并且这个命令是原子性的。
使用setnx作为分布式锁时，添加成功表示获取到锁，添加失败表示未获取到锁。至于添加的value值无所谓可以是任意值(根据业务需求)，只要保证多个线程使用的是同一个key，所以多个线程添加时只会有一个线程添加成功，就只会有一个线程能够获取到锁。而释放锁锁只需要将锁删除即可。

代码实现

@Service
public class SecKillServiceImpl implements SecKillService {

    private final JedisUtils jedisUtils;

    private final String SecKillKey = "goods_";

    public SecKillServiceImpl(JedisUtils jedisUtils) {
        this.jedisUtils = jedisUtils;
    }

    @Override
    public boolean doSecKill(String userId, String goodsId) {
        Jedis jedis = jedisUtils.getJedis();
        Long result = jedis.setnx(SecKillKey + goodsId, userId);
        if (result == 1) {
            jedis.expire(SecKillKey + goodsId, 5000);
            jedis.close();
            // TODO:写业务逻辑即可
            return true;
        }
        jedis.close();
        return false;
    }
}

测试

使用jmetter模拟5000并发测试结果，仅有一个抢到了该商品其他全部失败。
在这里插入图片描述

针对有多个库存的商品

大家可以想一下上边实现方式对于多个库存的商品是否适用，其实答案很简单，是不太适用的，针对多个库存的商品，不能使用类似于分布式锁的方式，因为该种方式同时只能由一个用户争抢到资源，只有等找个用户完成了下单动作释放掉锁之后其他用户才可以继续进行，所以秒杀效率特别底下。

所以可以采用redis的递减来实现，当秒杀开始的时候我们提前将秒杀商品的库存加载到redis,用户秒杀的时候采用递减来判断是否抢到了库存。

实现

    @Override
    public boolean doComplexSecKill(String userId, String goodsId) {
        Jedis jedis = jedisUtils.getJedis();
        Long result = jedis.decrBy(SecKillKey + goodsId, 1);
        if (result > 0) {
            jedis.close();
            return true;
        }
        jedis.close();
        return false;
    }