说到秒杀抢购，初次涉及的你首先会想到什么呢？
public synchronized void service(){
秒杀业务
}
reentrantLock.lock();
try {
秒杀业务
}finally {
reentrantLock.unlock();
}
是不是跟我想的一样呢？？
你试想一下，抢购跟随的可以高并发，假如同时有1000个人抢购，难道1000个人要一个一个排队查库存、购买、减库存，如果我是用户，我第一个可能就会锤爆你了。
基本的排队，其实并没有我们想象的那么难。
1、服务降级 2、限流 3、加锁 4、加缓存
今天我们主要说限流、加锁、加缓存。
1、乐观锁
上面我们提到了同步锁，这其实是悲观锁，这让我们的用户用起来就很悲观了。所以我们说的加锁就是加乐观锁。
假如我们通过商品id去更新库存，假设刚好11个人同时获取到上面这条信息，每个人都拿到的数量为10，那么是不是每个人都能购买成功呢，这是不是就出现bug了呢？？
所有我们增加了version这个字段，假设刚好11个人同时获取到上面的信息，每个人都拿到数量为10，version是0，但是数据库是表锁或行锁，所以1次只能执行1条语句，第一个人把version+1后，之后剩下的10个人都无法更新此字段，即影响行数为0，所以购物失败，你仔细细品一下。
这就是我们大致上所说的乐观锁了。
2、限流
常用的限流算法有两种：漏桶算法和令牌桶算法。漏桶算法思路很简单，水（请求）先进入到漏桶里，漏桶以一定的速度出水，当水流入速度过大会直接溢出，可以看出漏桶算法能强行限制数据的传输速率。令牌桶算法是每次请求都会从桶里获取令牌才能继续执行，桶里令牌有限，但是会消费后会源源不断生产，遇到没有令牌是你可以选择等待或者直接跳出执行。
令牌桶：
//创建令牌桶实例 30个令牌
private RateLimiter rateLimiter=RateLimiter.create(30);
//没有抢到token请求的一直等待，知道获取到token令牌
log.info("等待的时间"+rateLimiter.acquire());
//设置等待时间，在等待时间内获取令牌，则处理业务，否则，直接抛弃
boolean b = rateLimiter.tryAcquire(4, TimeUnit.SECONDS);
3、缓存
Redis是个好东西，所以我们要好好利用。
提前将要抢购的东西放入redis，设置过期时间，如果时间一到，将所有请求原地打回。
4、其他
- 进行用户信息验证，防止用户随意攻击，对用户设置访问次数
- 进行地址伪装，防止黄牛党
- 设置用户令牌，第一次请求申请令牌，带着令牌进行访问
