电商秒杀系统设计：
秒杀系统分为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秒之内只能提交一次请求。