记一次公司的秒杀抢购活动

1、背景

公司前段时间搞了一个送红包送现金券的活动，由于这活动系统已经上线很久了，但并没有稳定运行，运营反馈，每次活动开始系统都会出现响应超时，礼品送多了，甚至出现系统挂掉的情况，因此由我这边主导重新设计，完工之后，感触颇多，于是记录一下。有啥问题也希望各位朋友多多指正。

2、分析

像这种秒杀抢购流量暴增的业务场景主要解决两个问题

a、系统的稳定与高可用，简单来说你的系统不会被暴增的流量给击垮。

b、数据一致性，就是不会出现这种超卖现象。

3、架构设计

分析一波后已经明确我们要解决的问题了，思路如下。

a、当活动开始后一大批用户的请求涌入我们的系统，但是奖品数量毕竟有限，所以一大部分的流量都是没有必要的，因此限流是必须的，

业界限流的方式无非就4种。

1、简单计数器法，使用redis中的INCRBY指令，请求开始的时候+1，请求结束的时候-1，如当请求数达到1000的时候，以后的请求直接返回，但是有个问题就是不能防止恶意请求，redis某一时刻被恶意请求塞满，其他用户则无法访问系统。

2、滑动窗口，比如一分钟有60秒，我们设定当前时间的秒数能被5整除的请求就能访问系统，其余的请求直接被拒，但是如果所有的请求的当前时间的秒数能被5整除，那这一时刻我们的系统也会被压垮，所以存在一个临界值。

3、漏桶算法，这种方式和第1种有点类似，维护一个恒定大小的队列，初始化好这个队列，当请求进来的时候申请一个token，请求结束的时候归回token，没有拿到token的请求直接返回。

4、令牌桶原理，这种方式是对漏桶算法的改进，就是以恒定的速率生产令牌，控制令牌的生产速率等于控制了请求速率，没有拿到令牌的请求直接返回。

b、对于数据一致性问题，使用mysql的事务一致性的特性就能控制。

c、如上所述就可以得到如下架构图