秒杀系统设计

限流

秒杀场景短时间内有很高的并发量，秒杀的难点主要是超卖和限流。业务流程分验库存，较少库存，生成订单三个步骤。十几万的用户同时抢十几件商品，可能会达到几十万的qps，这么大的请求量可能会打垮服务器和数据库。而且99.9%的请求是无效的。

redis限流

做的第一件事是限流，在分布式条件下，一个限流方案是采用redis限流，比如限流到100qps，当前秒作为key。每次key自增，如果大于100之后的超过快速失败。这样能保证每次进入后续请求qps不超过100，但是redis集群的压力会很大。

消息队列削峰

另外一种方案是使用消息队列削峰，请求进入放到消息队列中，同时设定消息队列中消息最大值，如果消息大于这个值，直接抛弃掉，消费端拿到消息后去做处理，这种方案能够保证系统安全。

前端限流

也可以在前端做限流，比如只有偶数秒的请求才能发送出去，方法有多种多样，目的都是减少后段服务器的压力。

乐观锁

前端限流和后端限流在加上消息队列削峰，能够保证服务器不被宕机。但是还会存在并发。采用分布式锁或数据库乐观锁，性能方面考虑采用数据库乐观锁实现。数据库乐观锁是库存表有个版本号，先查询版本号，更新的时候where条件带上版本号。同时版本号自增，只有版本号一致才会更新，表示在这段时间内，数据没有被更新。