电商秒杀系统可能遇到的坑及思路

电商秒杀系统设计：
秒杀系统分为2个部分，一个是静态的HTML等内容，另外一个参与秒杀的Web后台请求接口。
静态HTML等内容，直接上cdn，压力通常不会大，瓶颈基本在后台请求接口上，必须可以支持高并发请求。

高并发下的数据安全问题：
假设只剩下一件商品状况，高并发请求致使多让一我的得到了商品。

1.悲观锁
在修改数据的时候，采用锁定状态，排斥外部请求的修改。遇到加锁的状态，就必须等待。

在“高并发”场景下，会不少的修改请求，每一个请求都须要等待“锁”，某些线程可能永远都没有机会抢到这个“锁”，请求就会死在那里。
这种请求会不少，瞬间增大系统的平均响应时间，容易使可用链接数被耗尽，系统陷入异常。

2.FIFO队列
直接将请求放入队列中的，采用FIFO（先进先出），这样就不会致使某些请求永远获取不到锁。
可是高并发场景下请求不少，可能一瞬间将队列内存“撑爆”，而后系统又陷入到了异常状态。囧

那么就得设计一个极大的内存队列。
可是，队列请求的速度根本没法和疯狂涌入队列中的数目相比。队列内的请求越积累越多，最终Web系统平均响应时候仍是会大幅降低，系统仍是陷入异常。囧

3.乐观锁
全部请求都有资格去修改数据，但会得到一个该数据的版本号，只有版本号符合的才能更新成功，其余的返回抢购失败。
这样的话，就不须要考虑队列的问题。我的建议这个方案。
缺点：它、会增大CPU的计算开销。

做弊的手段：进攻与防守

1.同一个帐号，一次性发出多个请求
应对方案：
在程序入口处，一个帐号只容许接受1个请求，其余请求过滤。
同一个uid，限制访问频度，作页面缓存，x秒内到达站点层的请求，均返回同一结果。

2.多个帐号，一次性发送多个请求
应对方案：
(1).弹出验证码，分辨出真实用户。
(2).直接禁止IP，简单粗暴实用,可能会有“误伤“。

3.多个帐号，不一样IP发送不一样请求
经过木马黑掉普通用户的电脑，不影响电脑正常运行，只是转发IP包，普通用户电脑被变成了IP代理出口。这种作法，黑客就拿到了大量的独立IP，而后搭建为随机IP服务，就是为了挣钱。

应对方案：
和真实用户的行为，已经基本相同，只能设置业务门槛过滤。

前端层设计1.浏览器层请求拦截用户点击“抢购“后，按钮置灰。2.JS限制用户在x秒以内只能提交一次请求。