秒杀系统-限流

秒杀系统

• 秒杀令牌
• 秒杀大闸
• 队列泄洪

一、秒杀令牌

用户利用自己的 token和商品的 id等信息，很容易就能写个脚本不停的发送请求，在活动没开始前，就开始刷，这样就会影响正常用户的下单，存在不公平现象；利用秒杀令牌机制，在活动开始前，秒杀令牌是不会发送给用户的，因此其活动请求之前没有令牌的请求都是无效的。

1. 秒杀原则

• 秒杀下单前，需要先获得秒杀令牌才能进行秒杀下单
• 秒杀接口需要依靠令牌才能进入，令牌合法之后，才能进入秒杀下单的逻辑；
• 秒杀活动模块全权负责秒杀令牌的生成周期以及生成方式；

2. 秒杀令牌实现

2.1. 秒杀令牌创建

​ 生成秒杀令牌，并存入 Redis 中，针对一个活动、一个商品，每个用户只能获得一个令牌；如果用户多次下单，每次下单，该用户对应的秒杀令牌都会更新；

生成流程：

• 获取活动信息
• 判断活动是否正在进行
• 校验商品信息和用户信息
• 生成秒杀令牌并存储返回。生成令牌的方式可参考：
  • 活动id+用户id+商品id 作为key
  • 创建一个UUID 作为value 【将此返回】
  • 存储到缓存如redis，设置过期时间

以上逻辑尽量在秒杀模块编写

2.2. 下单接口

​ 秒杀商品需增加对秒杀令牌的校验，此后进行创建订单。接口参数包括商品id,活动id，数量，令牌token

• 从请求参数中创建key值来获取redis中存储的令牌token
• 验证token是否与redis存储的是否相同
• 验证秒杀商品的限制：比如是否买过，数量是否正确
• 是否有库存【可提前加载到缓存中】
• 减库存【与上一步原子性操作】
• 创建订单

3. 秒杀令牌的缺陷

​ 秒杀令牌的生成是耗性能的。比如有 1亿个用户下单，就会生成 1 亿个秒杀令牌；即便 1 亿个用户都得到了秒杀令牌，也不是 1 亿个用户都能秒杀成功，因此可以使用 秒杀大闸 技术优化系统性能；

二、秒杀大闸

依靠秒杀令牌的授权原理，定制化发牌逻辑，实现大闸功能；
根据秒杀商品初始库存，颁发对应数量的令牌，控制大闸流量。
将用户的风控策略，前置到秒杀令牌的发放中（之前的令牌发放中已经完成了）；
将库存售罄判断前置到秒杀令牌的发放中

1. 秒杀大闸原则

• 通常设置大闸阈值在秒杀库存的3~4倍数左右，根据机器性能而定
• 大闸与令牌获取机制联动
• 在创建该秒杀活动时随秒杀商品信息一同做热备。分布式情况下考虑放入缓存

2. 秒杀大闸的实现

2.1 秒杀大闸的创建

BoundHashOperations boundHashOperations = redisTemplate.boundHashOps(SUKKILL_CACHE_PREFIX);//redission绑定hash值
// 设置sku的秒杀信息  seckillSkuRedisTo 需要热备到redis中的商品信息和活动起始信息
//保存到redis
String s = JSON.toJSONString(seckillSkuRedisTo);
Long ttl = session.getEndTime().getTime() - new Date().getTime();
boundHashOperations.put(seckillSkuVo.getPromotionSessionId() + "_" + seckillSkuVo.getSkuId().toString(), s);//缓存活动信息 key：活动_场次_skuId

//秒杀的数量作为信号量
RSemaphore semaphore = redissonClient.getSemaphore(SKU_STOCK_SEMAPHORE + seckillSkuVo.getPromotionSessionId() + "_" + seckillSkuVo.getSkuId().toString());
semaphore.trySetPermits(seckillSkuVo.getSeckillCount());
//秒杀大闸的阈值作为信号量
RSemaphore semaphore = redissonClient.getSemaphore(SKU_STOCK_THRESHOLD_SEMAPHORE + seckillSkuVo.getPromotionSessionId() + "_" + seckillSkuVo.getSkuId().toString());
semaphore.trySetPermits(seckillSkuVo.getSeckillCount()*(1+LOAD_FACTOR));

2.2 秒杀大闸的使用

/**
* 获取令牌
* @param userId 用户id
* @param activityId 活动id
* @param skuId 商品id
* @return 令牌token
*/
public String getToken(String userId,String activityId,long skuId) {
    //验证活动的合法性-----省略
    RSemaphore semaphore = redissonClient.getSemaphore(SKU_STOCK_THRESHOLD_SEMAPHORE +activityId + "_" + skuId);
    boolean b = semaphore.tryAcquire();//快速获取 大闸的流量限制
    if (b) {
        //大闸未打开，创建token 存储并返回
        UUID token = UUID.randomUUID();
        BoundHashOperations<String, String, String> operations = redisTemplate.boundHashOps(SKUKILL_USER_TOEKEN);
        operations.put(activityId+"_"+userId+"_"+skuId,token.toString());
        return token.toString();
    }
    //令牌已经发放完毕
    return null;
}

3. 存在的问题

如果一个网站做秒杀活动，有10个商品秒杀，每个有1000件，那么就要发放30000多个令牌，这样的数量仍然很大，所以我们采取了队列泄洪来解决此问题 

三、队列泄洪

队列化泄洪就是把访问的用户分成批次，来减轻同时巨大的访问量造成的压力，

队列化泄洪

• ExecutorService线程池， 通过这个可以从队列中每次获取一定数据量的请求进行处理，处理的速度取决于下游的窗口的处理速度。这个方法应注意线程数

泄洪的方法还有令牌桶算法和漏桶算法

上篇的线程池的技术就是类似于令牌桶算法

1. 令牌桶算法

令牌桶算法可以达到限流的目的。它注重于一段时间内的处理流量。

请求必须拿到令牌才可以继续进行请求。而令牌的数量是一个均衡增长的过程。

假设我们设置平均流速为r/s，则我们会每1/r秒创建一个令牌放到桶中，当请求到达时如果有令牌空余，则拿到令牌继续处理，如果没有则执行其他对应的处理逻辑，比如快速拒绝

适应场景：令牌桶算法能够处理突然的一个高并发流量，因为在高流量之前一段时间可能存在很多的令牌剩余，这样当请求到达时就能够获取更多的令牌来处理更多的请求

2. 漏桶

漏桶容量是有一定固定容量的，出口存在流量限制。就跟一个存在一个洞的漏桶，从洞流出来的水是匀速的，我们的请求被当作水，请求到达时水就到了桶中，如果桶中存在剩余的空间，我们就会将其放到桶中表示正在执行；否则则拒绝该请求。另外水的流出是按照规定的流速进行流出的。比如计算这次请求与上次请求的间隔时间，然后通过流出速率*间隔时间求出 这段时间内流出的水的量，再来判断桶是否已满。 漏桶算法能够强行限制数据的传输速率

区别

• 令牌桶算法在能够限制数据的平均传输速率外，还允许某种程度的突发传输

• 漏桶算法能够强行限制数据的传输速率

其他

• 限流的方式很多，可以在nginx层面进行限流，也可以在网关中进行限流，或者在实际的服务上进行限流。另外我们也可以通过在页面中增加验证码以时间分担压力
• 秒杀接口应该与下单接口分开
  • 秒杀请求处理时将验证后的秒杀信息交给下单接口进行
  • 可以在验证之后创建一个订单号，将信息发送给MQ，同时快速返回；下单接口监听MQ消息