思考
由于疫情，我们做的是互联网教育类，所以今年我们的产品流量增加了两倍，但是通过扩容加机器资源的方式完全扛住了，突然想到如果是爆发式的，假如流量突增10倍甚至20倍该如何处理呢？仔细思考了了一下这个问题，加上查找资料，就想简单写写有哪些方案。
场景
假如一个系统最大只能接受10w的并发访问量，现在我们有一个秒杀活动，秒杀活动开始的时候预计并发访问量可以达到100w。很明显100w远远超过系统正常的承载量，该怎么解决这突增的流量呢？从用户访问开始，其实请求要经历好几个阶段，我们可以针对每个阶段来做层层限流。
合法性限流
首先我们思考就是这100w包括正常访问的用户，也存在恶意刷单的用户，甚至某些机器人，那么我们肯定是要拦截刷单和机器人的请求的，因为这些请求严重影响正常用户的购买需求。那么怎么在这一层限流呢，首先非常简单其实，就是加一个验证码，首先，验证码可以拦截掉机器人的请求，其次可以拉长用户的访问时间。然后可以使用ip限制，如果通过网络技术发现了某些下单请求只需要几毫秒，或者是重复购买同一种商品，就能认为该请求用户不是合法用户或者是机器人，这样我们可以将这个ip加入黑名单限制禁止访问。最后，不是必须的情况下，不到秒杀开始的时间我们不开放秒杀地址入口。
负载限流
现在，经过第一层合法性限流之后，还是有大概50w的流量进来了，我们可以使用nginx转发流量到服务端集群里，假如我们集群有3台机器，每台机器只需要处理大概17w的并发访问量。再者，我们知道根据网络七层模型，nginx处于第七层，我们也可以在其它的网络层进行负载，比如说我们在第二层的数据链路层进行mac地址的负载，我们可以生成一个虚拟mac，然后将这个地址映射到其它3台服务器上，同样的可以在第三层通过网络ip进行负载，在第四层通过端口号进行负载。大多数我们通常使用nginx，或者nginx+lvs进行负载即可。
服务限流
前两层都是请求达到服务器的时候进行的限流，那么请求到了服务器的时候我们该如何处理呢，首先比如我们常用的tomcat服务器可以限制连接数，超过连接数会放弃掉多余的请求，我们还可以使用令牌桶算法，每秒只生成1000个令牌，抢到令牌的请求才能抢购秒杀商品。考虑到每个服务器处理请求能力的不同，我们还可以使用消息队列来进行限流，可以使用补偿通知的手法告知用户抢购成功。如果我们使用前后端分离的架构，用户访问的html和js代码可以直接缓存在浏览器里面，大点的图片可以保存在nginx或者oss云服务器上，体积特别大的视频可以部署在cdn上面，利用区域就近访问的特点来提高用户的访问速度，当然上面的缓存可以相互补充，比如oss服务器可以作为cdn的回源服务器。而数据业务的动态缓存就是服务端程序员去考虑的了，一般使用本地缓存+redis，但是我们不是使用越多的缓存就越好，缓存使用的越多，数据的一致性得到保障的可能性就越低。
