秒杀系统

Description

秒杀和抢购系统是比较常见的，从技术的角度来说，这是对web系统的一个巨大的考验，在一个高并发的场景下，系统的优化，稳定性和安全性尤为重要

秒杀带来的挑战

1.请求接口的设计

实现秒杀的接口每秒的请求次数可能达到5W或者更高，这个接口不仅要能支持高并发的请求，而且为了增强用户体验，最重要的还是准确，快速，为了在最短的时间内返回用户请求结果，后端存储一般使用内存级别的操作，如果业务场景比较复杂，建议采用异步写入。而静态资源一般是通过CDN部署，压力不大。

2.快速响应与实际问题

假设一个业务请求的响应时间为100ms，系统内有20台负载均衡服务器，配置最大连接数为500，那么我们的理想峰值为

20 * 50  / 0.1 = 10W

看起来每秒可以支撑10W此请求，这个系统似乎很不错，但是这是理想状态，在高并发的场景下，机器都处于高负载状态，此时的响应时间会大大增加，就web服务器而言，Apache打开了越多的连接进程，CPU需要处理的上下文切换也越多，额外增加了CPU的消耗，增长响应时间，那么我们来看下实际情况

20 * 50  / 0.25 = 4W

每秒差了1W次请求，可想会造成多大的拥堵，满负荷工作状态下却还有如此多的请求没有可用连接，服务器异常也接踵而至，如果用户频繁操作，甚至会导致雪崩，就是一台服务器挂了流量分散到其他正常工作的机器上，导致正常的机器也异常，从而导致整个web系统瘫痪

3.重启与过载保护

如果发生雪崩，直接重启服务是无法解决问题的，很有可能重启回来又立马挂掉，这个时候最好在入口层将流量拒绝掉，然后再重启，如果是redis/memcache这种服务也挂了，重启的时候需要预热。
秒杀和抢购的场景，流量往往是超乎我们系统的准备和想象的，所以过载保护也是很有必要，如果检测到系统满负载状态，拒绝请求也是一种保护措施，在前端设置过滤虽然简单，但是用户的体验下降，更合适的就是将过载保护设置在CGI入口层，快速将客户的请求直接返回

4.作弊与反作弊

通常这种业务场景会有很多请求是来自作弊手段，比如刷票工具，自动脚本等，有效的拦截这些作弊手段，也能大大提高系统的稳定性

• 同一个账号，一次性发出多个请求

部分用户通过浏览器插件等，在秒杀期间使用自己的账号，短时间内发起成百上千个请求，若不处理，很有可能出现严重的安全问题。在高并发场景下，若用户秒杀成功，在写入记录期间，请求了很多次，而此时尚未写入完成，请求到的都是未参与秒杀，那么就出现了严重的问题。
我们可以在秒杀入口限制一个账号只允许接受一个请求，其他的将被过滤，可以通过redis这种内存缓存服务，写入一个标志位，成功写入的则可以继续参加，类似于JAVA对象头monitor有没有？

• 多个账号，一次性发出多个请求

这个就是我们常说的僵尸账号，通常对于这类作弊我们常用的手段就是发现某个ip请求频率很高，则弹出一个验证码，为了避免自动脚本轻易识别验证码，我们需要将验证码设计的稍微巧妙一点，验证码的作用就是识别僵尸账号与真实账号

• 多个帐号，不同IP发出多个请求

这种场景就非常类似真实用户的业务场景了，想做分辨已经非常困难，我们可以通过数据分析，用户活跃信息等来做判断，或者设置等级门槛，这也是一个很好的方法。

5.如何保证高并发下的数据安全

在秒杀商品还剩最后一个时，如果来了非常多的请求，那么他们获取的信息都是还有一件商品，这就有可能产生超发的问题，我们可以尝试解决

1.悲观锁思路
在修改数据的时候，采用锁定状态，排斥外部请求的修改，遇到锁的状态就必须等待。再回到高并发的场景，这种方法很可能造成系统异常，因为会有很多的请求在等待锁，有可能很多请求都没有机会去获得锁，这种等待的请求越来越多，不仅会影响响应时间，还会用尽连接数，导致系统异常。

2.FIFO队列思路
我们直接将请求放入队列中，采用先进先出原则，将多线程变成单线程的感觉，有没有？这样似乎解决了悲观锁的问题，但是在高并发场景下，有可能一个队列被瞬间塞满，甚至撑爆，系统处理队列中请求的速度根本比不上涌入队列的速度，队列中的请求会积累的越来越多，响应时间还是会变长，导致系统异常

3.乐观锁思路
与悲观锁不同，所有请求都有权限去修改数据，但是会获得一个该数据的版本号，只有版本号符合才能操作成功，否则操作失败，虽然会增大CPU的计算开销，但是综合来说这个方法还是比较好的，redis中的watch就是其中之一。

高并发下面临的问题是非常严峻的，我们需要做好一系列保护措施，设计出一个安全稳定高效的系统，来满足用户的需求，接下来需要学习秒杀系统的设计优化和实践。