如何设计秒杀服务的限流策略？

对于秒杀业务，你们应该比较熟悉了。好比，“某商品原价 1299 元， 双十一整点秒杀价仅 500 元，限量 100 件，先到先得” 等等。经过这段文案咱们可以发现，参与秒杀活动商品的价格都比平时低不少，所以会吸引大量的用户来抢购。从而不难发现，对于秒杀系统的挑战就是：在流量瞬时突增的状况下，如何作依旧可以保证系统的稳定性。

​ 一、基于合法性限流。

​ 二、基于负载限流。

​ 三、基于服务限流。

​ 四、基于监控限流。

那举个例子来讲，好比说我如今横轴是时间轴，纵轴是用户的并发访问量，在横轴的 S 点就是秒杀的开始时刻。

那通常而言，在秒杀开始以前，用户的访问量是一条比较平滑的曲线，但随着秒杀活动的开始，用户的访问量会急剧的增大，而且随着秒杀的结束，访问量又会急剧的降低。

咱们假设在初始时用户的访问量在 1 万左右浮动，秒杀服务器可以承受的极限是 5 万，但在秒杀活动期间，用户的实际访问量可能达到了 100万。

那么很明显，100 万的访问量已经远远超过了系统可以正常承载的 5 万并发量，所以这时候就可能会致使秒杀系统的不稳定，甚至宕机的状况。

因此咱们如今不得不提到刚才所说的了，秒杀系统面临的最大挑战就是如何要保证在流量突增的状况下，仍然保证系统的稳定性。

那么在实际开发中，其实有不少方案均可以保证系统的稳定性。 而咱们本场 Chat 要分享的重点就是说如何要经过限流策略抵御秒杀期间的流量峰值，从而实现稳定性，那一块儿来看一下具体怎么操做。

当海量请求到来时，咱们能够对请求进行层层设卡、层层拦截，最终将海量请求削减成服务器可以处理的请求。

屡次限流

那举个例子来讲，好比秒杀开始时，可能有 100万的请求同时扑向服务器。若是从多层限流的角度来讲，咱们就能够在第 1 层把流量先削减成 30 万，而后在第 2 层减到 10 万，再在第 3 层减到 5 万，而后直接将这 5 万直接处理就能够了。

不难发现，在限流时，咱们既要层层限流，也要尽早限流，由于上游拦截的请求越多，下游的流量就越少。

那接下来咱们就一块儿看一看到底如何进行层层限流。

基于合法性限流

先看一下低层限流又是合法性限流，为了更好的解决这个问题，咱们先须要看一下到底什么是合法性限流？

合法性限流指的是仅仅限制那些合法的用户请求可以抵达到秒杀服务器，而将一些非法的请求所有进行拦截掉。那所以这里就须要注意了，在请求合法性限流之前，就得先知道哪些请求是合法的，哪些是非法的。

举一些非法的例子。好比在秒杀活动期间，那实际参与秒杀活动的用户多是人，也多是机器人，而且还可能存在同一用户反复购买同一件商品的行为，也是咱们说的刷单行为。

那么显然机器人和用户刷单都是一种不合理的行为，这种行为会影响到其余正经常使用户的购物体验，所以就属于不合法的请求。

合法性限流解决方案

而关于如何限制这些不合法的请求，那么就得具体问题具体分析和讨论了。

经过验证码的方式

好比说，若是非法请求的发起者是机器人，那么最容易想到的方法就是使用验证码。而且验证码还有一个做用，它能够拉长用户的访问时间。

举个例子，假设某一秒钟有 100 万个用户同时下单，但若是使用了验证码，那么用户从输入验证码到整个下单的整个过程就可能须要三秒钟，也就是说下单量仍然是 100 万不变，但下单的整体时间可能从 1 秒钟拉长到了 3 秒，那么原来须要 1 秒的时间，如今就须要 3 秒的世界，原来 100 万的请求，如今每秒钟就只须要处理 33 万，所以也能够下降流量的峰值。

经过 IP 的方式

再来看一下IP限制，若是经过网络技术监测到了某个 IP 下的下单频率在毫秒级别，或者反复购买同一件商品，那么就能判定下单的是机器人或者是不合法的用户，这样咱们就能够将这个 IP 加到黑名单之中，从而减小不合法的流量。

那还有一种作法是隐藏秒杀的入口地址，它指的是在秒杀开始以前，服务器并不会向外界暴露秒杀服务的地址，当秒杀服务开始以后才开放地址。

那到这里，第 1 层合法性线路就讲解完了，接下来咱们再看一下第二层限流，也就是负载限流。

基于负载限流

先看一下负载限流的理论基础是什么？一个是集群，一个是网络 7 层模型。

咱们在搭建集群时常常会用到一些工具，好比说 Nginx 和 LVS，那这些均可以用于负载限流。

基于软件实现限流

假设通过了第 1 层合法性限流之后，还剩 33 万的请求，若是经过集群搭建了三台服务器，那么每台服务器也就只须要承载 11 万的请求量了，那这样也能下降请求的并发量。

可是根据网络 7 层模型，Nginx 处于第 7 层。那除此之外，在网络 7 层模型之中的其余层也能够进行负载。

比方说咱们在第 2 层的数据链路层，也能够经过 MAC 地址进行负载。好比咱们能够生成一个虚拟 MAC ，而后将这个 MAC 地址映射到其余三个真实的服务器上。一样的，也能够在网络第 3 层经过 IP 进行负载，在第 4 层经过端口号进行负载。

那看到这里，有同窗可能会问了，可否进行级联负载呢？

咱们假设当请求到来时，可否先在第 2 层进行负载，而后再在第 3 层、以后再在第 4 层、第 7 层分别都进行一次负载？

若是这样作，在功能上确定是能够实现的。但这种级联的作法也会同时增长请求的路径，由于咱们知道每增长 1 次负载，就会增长 1 个转发路径，而每增长 1 个转发路径，就可能带来网络延迟问题，所以太多的接连负载也是不推荐的。

那么对于既然负载，常见的作法有哪一些呢？我认为单独的是由 Nginx 或者使用 Nginx 和 LVS 来实现二级负载就已经对于大部分系统足够了。

刚才提到的 LVS 是处于第 4 层，它是经过网络端口进行的复杂，而 Nginx 是第 7 层应用级别的负载。

那还有就是咱们这里说的负载，都是经过软件进行的负载，也就是软负载。

基于硬件实现限流

那除此之外，咱们还能够购买一些硬件工具进行负载，也是硬负载。常见的应用负载工具备 F5 或 Array 等。

好，你们可能已经发现了啊，前两层限流都是想办法将请求拦截在抵达服务器以前，可是若是请求已经抵达到了服务器，又该如何进行限流呢？

基于服务限流

那这个其实就是咱们立刻要讲的第 3 层限流优点，服务限流。

首先咱们能够经过 Web 服务器自己进行限流，比方说 Tomcat 是一款比较熟悉的 Web 服务器，若是链接 Tomcat 的数量太多，就可能形成 Tomcat 的不稳定，那该怎么办呢？

咱们能够把 Tomcat 的最大连接数，设置为一个合理的值，比方说咱们能够设置单 Tomcat 的最大连接数只为 300，那若是超过 300 的连接请求就会被 Tomcat 的无条件拒绝，那这样就能够保证谈不开的稳定性了。

那再好比，咱们也能够在服务器的内部，经过编写一些算法来进行限流，那常见的算法有哪一些呢？

基于算法实现限流

好比说令牌桶算法、漏洞算法都是的。那对于这些算法，若是你的编写有些困难，咱们也能够直接调一些类库里边儿已经存在的 API。

public class RateLimiter {
    //令牌桶限流:每秒只生成100个令牌，只有抢到令牌的线程才能抢购。
    static RateLimiter tokenRateLimiter = RateLimiter.create( 100.0) ;
    public static void miaoShaController () {
        //每次抢购操做，都会持续尝试l秒
        if (tokenRateLimiter.tryAcquire(1，TimeUnit.SECONDS)) {
            //开启抢购线程
        }
    }
}
复制代码

那么这就是使用 Google Guava 类裤的令牌桶算法，create() 的方法能够限制每秒钟最多有 100 个线程能够同时参与抢购，tryAcquire 方法能够用于设置每秒的抢购动做会持续 1 秒钟，实现起来很是简单。

基于消息队列实现限流

那除了刚才讲的服务器配置参数以及限流算法之外，咱们在服务器之中还可使用队列来进行限流，这里说的队列主要是消息队列。

这里咱们拿一个例子来讲，假设每秒钟有 10 万的请求量，而且系统里边有三个子系统 A、B 和 C，那三个子系统每秒钟可以处理的极限分别是 2 万请求、3 万请求和 4 万请求。

在不使用消息队列的状况下，若是这 10 万请求分别平均分给这三个子系统，那么每一个子系统就须要处理 3.3 万的请求。那很显然，在每秒钟以内，系统 A 只能处理 2 万请求，若是接收到了 3.3 万请求，就可能致使系统 A 延迟甚至崩溃的状况。

而若是使用消息队列就能够很好地解决这种问题。那消息队列本质是一种缓冲区，当 10 万请求到来时，消息队列能够将这 10 万请求临时存储，而后三个子系统再分别根据本身的性能，分别去消息队列中针对性的去拉取特定数量的请求。

比方说系统 A 的极限是 2 万，那么他每次最多就只须要从队列之中取 2 万数据就够了，那这样就能够避免超额请求对系统 A 形成的压力的状况了。

除了前面介绍的服务器限流以及队列限流之外，咱们还可使用第 3 个服务限流，也就是缓存限流。

缓存限流

限流的本质是为了避免断地削减请求的数量，而缓存的做用是为了减小用户请求服务端的数量，所以缓存也能够做为限流的一种实现方案。

但为了有效地使用缓存进行限流，咱们须要先将系统设计成先后端分离或者动静分离的结构，而后分别的对静态以及动态缓存进行限流。

静态缓存实现限流

先看一下对静态请求如何进行缓存。那当客户端第 1 次请求服务端的时候，服务端会将网页的基本结构代码想给客户端。

好比咱们第 1 次访问某个网站时，网站服务器就会将搭建此网站的 HTML、JavaScript 脚本等代码响应给客户端，那么客户端就能够将这些 HTML 和 JavaScript 代码缓存到客户端浏览器之中。那么这样一来，当用户之后再次访问这个网站时，就能够直接从本地浏览器的缓存中获取 HTML 和 JavaScript 代码了。

对于 HTML 这种体积比较小的代码，咱们能够直接将其缓存在浏览器之中，可是若是体积较大的图片，咱们最好将它们缓存的 Nginx，或者经过 Nginx 转发在 OSS 等于服务器之中，而若是是视频等一些体积特别大的静态资源，也能够将它缓存在 CDN 中，利用 CDN 区域部署就近访问的特色来提升用户的访问速度。

而且咱们知道各个缓存并非独立的，也能够相互补充，好比说 OSS 也能够做为 CDN 的回源站点。

动态缓存实现限流

接下来再看一下动态缓存，那对于动态缓存，通常先建议缓存在本地的服务器之中，若是本地服务器的缓存失效，咱们再缓存到由 Redis 组成的远程集群之中，进行二次的查询。也就是说咱们能够搭建本地缓存以及二远程缓存组成的二级结构，进行动态请求的缓存。

须要注意的是，缓存的级别也并非越多越好。有同窗可能也会想到，他说缓存既然这么好用，那么干脆多来几级缓存。咱们能够在CPU、内存、硬盘、网络等节点上分别设置缓存，而且每一个节点里边还能够再次细分出多级缓存。

那若是这样作，就必需要考虑多级缓存带来的一致性问题了，缓存的级别越多，一致性的问题就越严重，而解决这种一致性问题又会增长系统的开发成本以及系统的额外开销。

还要知道的是，咱们缓存的级别越多，请求在系统内部的跳转路径也会越长，这也就相似于多级负载带来的问题。因此说咱们学技术必定要懂得权衡，不要盲目的进行技术的堆砌。

那么对于大部分项目而言，咱们使用静态缓存加上二级动态缓存已经彻底足够了。

那总得来讲，咱们静态缓存能够将大量的静态资源缓存在服务器之外的地方，而动态缓存能够很大程度上减小请求抵达数据库的次数。

基于监控限流

那最后咱们再来看一下监控限流。咱们知道 CPU、内存、并发量等都是衡量系统稳定性的重要指标，若是他们的使用频率太高，也可能形成系统的不稳定。

所以咱们也能够建议建立一些线程，专门用于监控这些指标。比方说咱们能够创建一个线程，专门用于监控 CPU 的利用率，若是 CPU 利用率达到了极限，就能够临时性地采起服务降级或拒绝策略。

那这里说的服务降级实际上与精兵简政的思想相似，它指的是当系统资源不足时，咱们就能够把查看三个月之前的历史订单、历史评论等一些非核心的服务临时关闭，从而为系统节约出一部分的资源来。

那在采用服务降级或拒绝策略一段时间以后，CPu 等资源利用率就会恢复到正常状态，那以后咱们就能够从新接收并处理新的请求了。

总结

好的，咱们今天分享的主题是如何设计秒杀服务的限流策略。这里我介绍了合法性限流、负载限流、服务限流。其中合法性限流能够拦截大量的非法请求，而负载限流能够经过集群技术抵抗大规模的流量冲击服务，下流则是经过对服务器的参数配置、限流算法、MQ 缓存以及监控等手段进行限流。