---

设定一个场景，假如一个商品接口在某段时间突然上升，会怎么办？

生活中的例子来说，假设冰墩墩在当天晚上上热搜之后，迅速有十几万人去淘宝下单购买，此时并没有做好对该商品的缓存预热以及准备，如何操作？

对于这个问题，在电商高并发系统中，对接口的保护一般采用：缓存、限流、降级 来操作。

假设该接口已经接受过风控的处理，过滤掉一半的机器人脚本请求，剩下都是人为的下单请求。

服务限流

限流 主要的目的是通过对并发访问/请求进行限速，或者对一个时间窗口内的请求进行限速，一旦达到限制速率则可以拒绝服务、排队或等待、降级等处理。

限流算法

1. 漏斗算法

漏桶算法 是当请求到达时直接放入漏桶，如果当前容量已达到上限（限流值），则进行丢弃或其他策略（触发限流策略）。漏桶以固定的速率（根据服务吞吐量）进行释放访问请求（即请求通过），直到漏桶为空。

漏斗算法的思想就是，不管你来多少请求，我的接口消费速度一定是小于等于流出速率的阈值的。

可以基于消息队列来实现。

2. 令牌桶算法

令牌桶算法 是程序以v（v = 时间周期 / 限流值）的速度向令牌桶中增加令牌，直到令牌桶满，请求到达时向令牌桶请求令牌，如果获取成功则通过请求，如果获取失败触发限流策略。

令牌桶算法和漏斗算法的思想差别在于，前者可以允许突发请求的发生。

3. 滑窗算法

滑窗算法 是将一个时间周期分为N个小周期，分别记录每个小周期内访问次数，并且根据时间滑动删除过期的小周期。

如下图所示，假设时间周期为1分钟，将1分钟再分为2个小周期，统计每个小周期的访问数量，则可以看到，第一个时间周期内，访问数量为75，第二个时间周期内，访问数量为100，如果一个时间周期内所有的小周期总和超过100的话，则会触发限流策略。

Sentinel的实现 和 TCP滑窗。

接入层限流

Nginx限流

Nginx 限流采用的是漏桶算法。

它可以根据客户端特征，限制其访问频率，客户端特征主要指 IP、UserAgent等。使用 IP 比 UserAgent 更可靠，因为 IP 无法造假，UserAgent 可随意伪造。

limit_req模块基于IP：

http://nginx.org/en/docs/http/ngx_http_limit_req_module.html

tgngine：

http://tengine.taobao.org/document_cn/http_limit_req_cn.html

本地接口限流

Semaphore

Java 并发库 的 Semaphore 可以很轻松完成信号量控制，Semaphore 可以控制某个资源可被同时访问的个数，通过 acquire() 获取一个许可，如果没有就等待，而 release() 释放一个许可。

假如我们对外提供一个服务接口，允许最大并发数为40，我们可以这样：

private final Semaphore permit = new Semaphore(40, true);

public void process(){

    try{
        permit.acquire();
        //TODO 处理业务逻辑

    } catch (InterruptedException e) {
        e.printStackTrace();
    } finally {
        permit.release();
    }
}

具体的 Semaphore 实现参考源码。

分布式接口限流

使用消息队列

不管是用MQ中间件，或是Redis的List实现的消息队列，都可以作为一个 缓冲队列 来使用。思想就是基于漏斗算法。

当对于一个接口请求达到一定阈值时，就可以启用消息队列来进行接口数据的缓冲，并根据服务的吞吐量来消费数据。