.net每隔几秒去请求接口怎么做_「原创」实战|用手写一个骚气的请求合并，演绎底层的真实...

20大进阶架构专题每日送达

• 冬来冬往&＃xff0c;越来越喜欢软绵绵的被窝了。

• 厌倦了夏天的酷热&＃xff0c;秋天的浮躁&＃xff0c;来一首冬天的安静。

老板说&＃xff0c;他要做个现场营销活动&＃xff0c;线上线下都要参与推广&＃xff0c;这个活动参与人数可能很大哦··· 果然&＃xff0c;由于不是我写的代码&＃xff0c;所以那天服务器就崩了&＃xff0c;崩的时候很安静&＃xff0c;写代码的那个人一个人走的&＃xff0c;走的时候很安详。

: 当请求量到达百万级时候&＃xff0c;为啥会崩溃呢&＃xff1f;

微服务中是通过接口去向服务提供者发起http请求或者rpc(tcp)请求去获取数据&＃xff0c;事实上大量请求中&＃xff0c;服务端能处理的请求数量有限&＃xff0c;服务中充斥着大量的线程&＃xff0c;以及数据库等的连接也会被占用完&＃xff0c;导致请求响应速度也越来越慢。

&＃xff1a;

• 响应速度和我们的数据层有关系吗&＃xff1f;

• 能不能去添加服务端服务器呢&＃xff1f;

• 如果能减少客户端向服务端的请求就好了&＃xff1f;

• 限流吗&＃xff1f;当前场景能限流吗&＃xff1f;

• 每个线程去查询数据&＃xff0c;每次都只查询某一个结果&＃xff0c;是不是太浪费了&＃xff1f;

• 我们能不能想办法&＃xff0c;提升我们系统的调用性能&＃xff1f;

上面的一些思路可以用加缓存&＃xff0c;加MQ的方式去解决。但是缓存有限&＃xff0c;MQ是个队列&＃xff0c;有限流的效果。那么&＃xff0c;如何才能提高系统的调用能力&＃xff0c;我们学习一下&＃xff0c;请求合并&＃xff0c;结果分发。

• 正常的请求都是一个请求一个线程&＃xff0c;到后台触发相关的业务需求&＃xff0c;去调用数据获取业务。

• 当请求合并后&＃xff0c;我们要将多个多个请求合并后统一去批量去调用。

大概的设计思路便是如下图所示&＃xff1a;

常规请求

请求合并

说下我们的思路

• 解决请求调用多&＃xff0c;比如调用商品数据&＃xff0c;经过的服务多&＃xff0c;调用链很长&＃xff0c;所以查询数据库的次数也就非常多&＃xff0c;数据库连接池很快就被用光&＃xff0c;导致很多请求被阻塞&＃xff0c;也导致应用整体线程数非常高。虽然通过增加数据库连接池大小可以缓解问题&＃xff0c;并且可以通过压力测试&＃xff0c;但这治标不治本。

• 查询商品信息的时候&＃xff0c;如果同一商品同一时刻有100个请求&＃xff0c;那么其中的99次查询是多余的&＃xff0c;可以把100个请求合并成一个真实的后台接口调用&＃xff0c;只要控制好线程安全即可。我的想法是使用并发计数器来实现再配合本地缓存&＃xff0c;计数器可直接用JDK提供的AtomicInteger&＃xff0c;线程安全又提供原子操作。

• 以获取商品信息为例&＃xff0c;每个商品id对应一个计数器&＃xff0c;计数器初始值默认是0&＃xff0c;当一个请求过来后通过incrementAndGet使计数器自增1并返回自增后的值。当该值等于1&＃xff0c;表明该线程在这个时间点上是第一个到达的线程&＃xff0c;然后就去调用真实的业务逻辑&＃xff0c;在查询到结果后放入到本地缓存中。当该值大于1的时候&＃xff0c;表明之前已有线程正在调用业务逻辑&＃xff0c;则进入等待状态&＃xff0c;并循环的查询本地缓存中是否已有数据可用。获取到结果后都调用decrementAndGet使计数器减1&＃xff0c;计数器被减到0的时候就回到了初始状态&＃xff0c;并且当减到0(代表最后一个线程)时清除缓存。

• 那还有在1000次请求中&＃xff0c;请求的数据id不同&＃xff0c;但是使用的服务接口相同&＃xff0c;都是查询商品库的商品id从1~1000的数据&＃xff0c;都是从表里面查询&＃xff0c;queryDataById(dataId),那我也可以合并这些请求&＃xff0c;改为批量查询&＃xff0c;然后将数据分发返回。思路就是设计每个请求携带一个请求唯一的traceId,有点像链路跟踪的感觉&＃xff0c;简单点可以使用查询的id进行最为跟踪id&＃xff0c;将请求放入一个队中&＃xff0c;使用定时任务&＃xff0c;比如每隔10ms去扫描队列&＃xff0c;将这些业务合并请求统一去请求数据库层。

• 此方案有个数据延迟的地方&＃xff0c;就是每次循环时的等待状态的时间。因为一次包含多次查库的业务调用&＃xff0c;耗时基本都在几十毫秒&＃xff0c;甚至是上百毫秒&＃xff0c;可以把该等待睡眠设置小一点&＃xff0c;比如10毫秒。这样即不会浪费CPU时间&＃xff0c;实时性也比较高&＃xff0c;但然也可以通过主动唤醒等待线程的方式&＃xff0c;这个操作起来就比较复杂些。在这其中还可以添加一些异常处理、超时控制、最大重试次数&＃xff0c;最大并发数(超时最大并发数就快速失败)等。

• 模拟一个远程调用接口


import org.springframework.stereotype.Service;

import java.util.*;

/**
* 模拟远程调用ShopData接口
* &＃64;author Lijing
*/
&＃64;Service
public class QueryServiceRemoteCall {

/**
* 调用远程的商品信息查询接口
*
* &＃64;param code 商品编码
* &＃64;return 返回商品信息&＃xff0c;map格式
*/
public HashMap queryShopDataInfoByCode(String code) {
try {
Thread.sleep(50L);
} catch (InterruptedException e) {
e.printStackTrace;
}
HashMap hashMap &＃61; new HashMap<>;
hashMap.put("shopDataId