秒杀活动的解决思路

秒杀活动
秒杀活动，是很考验qps的一种情况，当高并发的时候，响应时间会相应的增加很多，这时候每台机子的qps就会大大减少。会造成某台服务器的崩溃，因为该机器崩溃，负载到了其他机器，用户有一个很特殊的行为特点：当系统越不可用，用户的点击就会越多。有可能会造成雪崩。
其实正常的应用中也会遇到这种问题，当其中某个接口的响应时间过长，会逐渐的将web服务器的可用链接占满。
造成这种问题的几种原因:

Q1:很多人会为了秒杀，使用同一个账号，会去大量的刷接口。
AN:可以在redis中让其写入一个标志位（只允许写入一个，类似乐观锁），成功写入才能继续参加

Q2：多个账户同时请求，例如火车票黄牛
AN:判断如果某个ip的请求次数过多，就禁止掉这个ip（不友好）。或者是弹出验证框。

Q3:多个账户多个不同ip去请求
AN:这种其实就很难分别了，只能通过提高用户参加活动的门槛了。例如：活跃度，等级等。

Q4:例如火车票抢票的黄牛,会使用自己的账户购买，然后退票，使用用户的抢。
AN:对于节假日经常买票退票的,做进一步的甄别，限制认证。

高数据并发下的数据安全：
超发问题：比如100个商品，已经发了99个了，最后一个同时被多个人读了，就会去生成多个订单。
解决方案:

1、悲观锁，锁住数据库。但是这种不太好，在高并发下，会因为请求太多被阻塞而使得系统陷入异常。
2、队列的思想。将请求都放入队列中，先进的先出嘛。问题是，当高并发的时候，一瞬间队列空间会被撑爆。或者说，因为队列太大，最终处理时间还是会变长。这两种情况都会导致系统异常。
3、乐观锁：比较适合。当数据来访问的时候，都可以修改数据，但是给加上version，只有在version最前的时候，最终才能够执行成功，其他的用户回滚。