秒杀技术

没有做过秒杀相关的功能，为了面试，做一个技术预演。

---

一句话：秒杀就两个问题，削峰限流和减库存。

       大量的请求过来，用redis抗，单机1s/10w的吞吐量。在redis里面做秒杀商品的增减，redis是单线程的，保证线程安全。redis库存扣减成功，就去后台更新数据库，仅此！不会对数据库造成任何的压力，你有1000个商品参与秒杀，也就1000个请求去更新数据库了，库存没有，直接返回失败。秒杀问题解决！！！一句话的事情。

参考文章：老王 双十一 秒杀架构

1：用户的请求，点击秒杀到后台，这个请求不用变成异步的，直接redis抗即可。老王的方案是，用户的提交请求直接入队列，同步变成异步。但是，这里会放入大量的“无效”请求，都放入MQ蓄水池里面了。客户端要发送两次请求，提交请求和查询请求。客户端直接提交，然后就弹个进度框等结果即可。一种是直接抗，一种是先诱敌深入放进来。我觉得就抗吧！扛不住再放。

抗的方式，保证了数据库DB不会承受压力。但是，如果有10000个秒杀商品，redis不会成为瓶颈，瞬间10000都来操作数据库，这里肯定还要引入一个MQ，缓冲一下，避免击穿DB。

12306应该就是放的方式，redis也扛不住在大并发的时候，做减库存操作。比如redis做一个MQ，就直接放，不要做运算了。比如一个车次1000张车票，放1000个进来，其他的都直接拒绝。 这1000个，可以看到一个弹框在不断的查询，还会报有多少人在等待，排队中等，这些都是在查询自己的请求的状态信息，在MQ中那就是排队，在数据库里面那就是出票成功。

但是，看到你前面多少人在排队，当前排队人数已经超过了余票？按理说不应该出现这种情况，并发控制的好，就放进来1000个，只要能到这里，就应该订票成功呀。可能是他们的业务吧，多放些进来，或者出现并发问题？多跑进来了些？数据库处理的时候，发现没票了。不知道是不是故意的。

他人

当然，感觉很简单，终究纸上谈兵！