通达信数据接口费用-海量请求下的接口并发解决方案

令牌桶算法

一般服务降级应该用来对一些不重要或不紧急的服务或任务进行服务的延迟使用或暂停使用。

接入层限流

Nginx限流

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

读写分离

在缓存数据后，如果所有请求都来缓存中操作这个库存，不管是加悲观锁还是乐观锁，并发率都很低，此时我们可以对这个库存进行拆分。

漏斗算法

假设我们操作的是一个库存接口，此时数据库中只有100个库存。

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

服务限流

恢复方案

漏桶算法是当请求到达时直接放入漏桶，如果当前容量已达到上限，则进行丢弃或其他策略。漏桶以固定的速率进行释放访问请求，直到漏桶为空。

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

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

在接口请求并发量大于阈值，或是接口出现大量失败请求等等突发情况，可以拒绝一些访问请求。

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

负载均衡

滑窗算法

随机拒绝：随机拒绝超过阈值的请求。拒绝旧请求：按照请求的时间，优先拒绝更早收到的请求。拒绝非核心请求：根据系统业务设置核心请求清单，将非核心清单内的请求拒绝掉。

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

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

缓存问题

使用消息队列

拒绝策略

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

服务降级

在实现服务降级之后，对于突增流量我们可以继续注册多个消费者服务来应对并发量，之后我们再对一些服务器进行慢加载。

数据缓存

海量请求下的接口并发解决方案

Sentinel的实现和TCP滑窗。

停止边缘业务

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

对访问请求使用分布式锁进行阻塞。在这个短时间中，我们可以将对应操作行的热点数据，缓存在缓存中间件中。放行请求后，让所有请求优先操作缓存数据。再将操作的结果通过消息队列发送给消费接口慢慢消费。

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

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

public void process(){

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

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