高并发场景基本介绍

高并发场景下的作弊与反作弊手段

对于秒杀或者抢购等的海量请求，其实有很大一部分属于不正当的请求。不少用户，为了抢到“商品”，可能会采用一些类似刷票软件的工具，或者自己制作自动请求脚本，短时间发送大量的请求到后端服务，这些都属于作弊手段。有作弊，肯定就会有反作弊，长江的一些场景如下：

1、同一个帐号，一次性发送大量请求。

这些请求如果没有被处理，就会造成系统的数据请求的破坏，甚至导致一些逻辑被错误处理。解决办法是：先判断用户是否已经参与过抢购，如果没有，写入记录中；如果有，直接返回已经抢购中。并且在程序的入口，对用户做限定，一个用户只会有一个正常的请求处理，其他过滤，这样能防止负载均衡将用户的请求发送到不同的内部服务器上。

2、多个帐号，一次性发送大量请求

这种场景出现在业务早期，对用户的注册要求比较低，导致一些人随机注册了大量的帐号。这种场景可以检测用户的ip，发现某个ip频率较高，可以采取验证码或者直接决绝的方式保护系统。

3、多个帐号，不同ip发送

这个时候和真是用户的请求几乎区分不出来了，一方面可以提高业务的准入门槛来限制请求，另一方面可以结合数据挖掘，对用户的ip和帐号行为进行分析，比如帐号信息较少，只在一些特定的时候比i叫活跃等，都是僵尸号的一些特点。

高并发场景下的优化思路

1、请求接口的合理设计

秒杀或者抢购页面，通常分为2个部分，静态页面和后端请求接口。通常，静态网页HTML等文件，可以通过CDN服务部署，不会有太大的压力，瓶颈在于后端的服务接口。要求后端接口尽量的快，一般建议后端接口尽量进行逻辑拆分，涉及到的存储使用内存等。

2、过载与保护

如果系统发生雪崩，贸然重启服务是不能解决问题的，这个时候，最好在流量入口进行控制。如果是缓存等服务也挂了，需要进行缓存的预热。当然，检测服务是否过载才是关键，若是服务满载，需要在业务顶层做服务拒绝处理。

高并发场景下的数据安全

多线程一定需要考虑线程数据安全，比如抢购环节，最后库存只剩一个，但是请求读取到的数据可能大于1，从而导致超发。解决思路有：

1、悲观锁的思路

在修改数据的时候，先锁定数据，保证只会有一个请求到达。但是，高并发下，每个请求都需要等锁，某些线程甚至可能永远等不到锁，请求就会死在那里。这些请求会很多，瞬间增大系统的平均响应实践，连接数被沾满，系统陷入异常。

2、FIFO队列思路

将请求发乳队列中，就不会造成有些请求永远等不到锁。但是，高并发下，很可能一瞬间将队列内存撑爆，或者说队列处理的速度远低于进入的速度，仍热会增大系统的响应时间，系统异常。

3、乐观锁的思路

每个请求的数据被处理之前，都会加上一个版本号，满足条件的版本号的请求被正确处理，其他请求直接拒绝返回。这个思路能解决前面两个的缺点，但是会增加CPU的运算量，设计上也稍微复杂一些。

参考:

高并发