乐趣区

关于后端:HTTP调用你考虑到超时重试并发了吗

jiezi

明天，咱们一起聊聊进行 HTTP 调用须要留神的超时、重试、并发等问题。

与执行本地办法不同，进行 HTTP 调用实质上是通过 HTTP 协定进行一次网络申请。网络申请必然有超时的可能性，因而咱们必须思考到这三点：

  • 首先，框架设置的默认超时是否正当；
  • 其次，思考到网络的不稳固，超时后的申请重试是一个不错的抉择，但须要思考服务端接口的幂等性设计是否容许咱们重试；
  • 最初，须要思考框架是否会像浏览器那样限度并发连接数，免得在服务并发很大的状况下，HTTP 调用的并发数限度成为瓶颈。

Spring Cloud 是 Java 微服务架构的代表性框架。如果应用 Spring Cloud 进行微服务开发，就会应用 Feign 进行申明式的服务调用。如果不应用 Spring Cloud，而间接应用 Spring Boot 进行微服务开发的话，可能会间接应用 Java 中最罕用的 HTTP 客户端 Apache HttpClient 进行服务调用。

接下来，咱们就看看应用 Feign 和 Apache HttpClient 进行 HTTP 接口调用时，可能会遇到的超时、重试和并发方面的坑。

1、配置连贯超时和读取超时参数的学识

对于 HTTP 调用，尽管应用层走的是 HTTP 协定，但网络层面始终是 TCP/IP 协定。TCP/IP 是面向连贯的协定，在传输数据之前须要建设连贯。简直所有的网络框架都会提供这么两个超时参数：

  • 连贯超时参数 ConnectTimeout，让用户配置建连阶段的最长等待时间；
  • 读取超时参数 ReadTimeout，用来管制从 Socket 上读取数据的最长等待时间。

这两个参数看似是网络层偏底层的配置参数，不足以引起开发同学的器重。但，正确理解和配置这两个参数，对业务利用特地重要，毕竟超时不是单方面的事件，须要客户端和服务端对超时有统一的预计，协同配合方能均衡吞吐量和错误率。

连贯超时参数和连贯超时的误区有这么两个：

  1. 连贯超时配置得特地长，比方 60 秒。一般来说，TCP 三次握手建设连贯须要的工夫十分短，通常在毫秒级最多到秒级，不可能须要十几秒甚至几十秒。如果很久都无奈建连，很可能是网络或防火墙配置的问题。这种状况下，如果几秒连贯不上，那么可能永远也连贯不上。因而，设置特地长的连贯超时意义不大，将其配置得短一些（比方 1~5 秒）即可。如果是纯内网调用的话，这个参数能够设置得更短，在上游服务离线无奈连贯的时候，能够疾速失败。
  2. 排查连贯超时问题，却没理清连的是哪里。通常状况下，咱们的服务会有多个节点，如果别的客户端通过客户端负载平衡技术来连贯服务端，那么客户端和服务端会间接建设连贯，此时呈现连贯超时大概率是服务端的问题；而如果服务端通过相似 Nginx 的反向代理来负载平衡，客户端连贯的其实是 Nginx，而不是服务端，此时呈现连贯超时应该排查 Nginx。

读取超时参数和读取超时则会有更多的误区，我将其演绎为如下三个。

第一个误区：认为呈现了读取超时，服务端的执行就会中断。

咱们来简略测试下。定义一个 client 接口，外部通过 HttpClient 调用服务端接口 server，客户端读取超时 2 秒，服务端接口执行耗时 5 秒。

@RestController
@RequestMapping("clientreadtimeout")
@Slf4j
public class ClientReadTimeoutController {private String getResponse(String url, int connectTimeout, int readTimeout) throws IOException {return Request.Get("http://localhost:45678/clientreadtimeout" + url)
                .connectTimeout(connectTimeout)
                .socketTimeout(readTimeout)
                .execute()
                .returnContent()
                .asString();}

    
    @GetMapping("client")
    public String client() throws IOException {log.info("client1 called");
        // 服务端 5s 超时，客户端读取超时 2 秒
        return getResponse("/server?timeout=5000", 1000, 2000);
    }

    @GetMapping("server")
    public void server(@RequestParam("timeout") int timeout) throws InterruptedException {log.info("server called");
        TimeUnit.MILLISECONDS.sleep(timeout);
        log.info("Done");
    }

}

调用 client 接口后，从日志中能够看到，客户端 2 秒后呈现了 SocketTimeoutException，起因是读取超时，服务端却丝毫没受影响在 3 秒后执行实现。

[11:35:11.943] [http-nio-45678-exec-1] [INFO] [.t.c.c.d.ClientReadTimeoutController:29] - client1 called
[11:35:12.032] [http-nio-45678-exec-2] [INFO] [.t.c.c.d.ClientReadTimeoutController:36] - server called
[11:35:14.042] [http-nio-45678-exec-1] [ERROR] [.a.c.c.C.[.[.[/].[dispatcherServlet]:175 ] - Servlet.service() for servlet [dispatcherServlet] in context with path [] threw exception
java.net.SocketTimeoutException: Read timed out
  at java.net.SocketInputStream.socketRead0(Native Method)
  ...

[11:35:17.036] [http-nio-45678-exec-2] [INFO] [.t.c.c.d.ClientReadTimeoutController:38] - Done

咱们晓得，相似 Tomcat 的 Web 服务器都是把服务端申请提交到线程池解决的，只有服务端收到了申请，网络层面的超时和断开便不会影响服务端的执行。因而，呈现读取超时不能随便假如服务端的解决状况，须要依据业务状态思考如何进行后续解决。

第二个误区：认为读取超时只是 Socket 网络层面的概念，是数据传输的最长耗时，故将其配置得十分短，比方 100 毫秒。

其实，产生了读取超时，网络层面无奈辨别是服务端没有把数据返回给客户端，还是数据在网络上耗时较久或丢包。

但，因为 TCP 是先建设连贯后传输数据，对于网络状况不是特地蹩脚的服务调用，通常能够认为呈现连贯超时是网络问题或服务不在线，而呈现读取超时是服务解决超时。确切地说，读取超时指的是，向 Socket 写入数据后，咱们等到 Socket 返回数据的超时工夫，其中蕴含的工夫或者说绝大部分的工夫，是服务端解决业务逻辑的工夫。

第三个误区：认为超时工夫越长工作接口成功率就越高，将读取超时参数配置得太长。

进行 HTTP 申请个别是须要取得后果的，属于同步调用。如果超时工夫很长，在期待服务端返回数据的同时，客户端线程（通常是 Tomcat 线程）也在期待，当上游服务呈现大量超时的时候，程序可能也会受到连累创立大量线程，最终解体。

对定时工作或异步工作来说，读取超时配置得长些问题不大。但面向用户响应的申请或是微服务短平快的同步接口调用，并发量个别较大，咱们应该设置一个较短的读取超时工夫，以避免被上游服务拖慢，通常不会设置超过 30 秒的读取超时。

你可能会说，如果把读取超时设置为 2 秒，服务端接口须要 3 秒，岂不是永远都拿不到执行后果了？确实是这样，因而设置读取超时肯定要依据理论状况，过长可能会让上游抖动影响到本人，过短又可能影响成功率。甚至，有些时候咱们还要依据上游服务的 SLA，为不同的服务端接口设置不同的客户端读取超时。

2、Feign 和 Ribbon 配合应用，你晓得怎么配置超时吗？

方才我强调了依据本人的需要配置连贯超时和读取超时的重要性，你是否尝试过为 Spring Cloud 的 Feign 配置超时参数呢，有没有被网上的各种材料绕晕呢？

在我看来，为 Feign 配置超时参数的简单之处在于，Feign 本人有两个超时参数，它应用的负载平衡组件 Ribbon 自身还有相干配置。那么，这些配置的优先级是怎么的，又哪些什么坑呢？接下来，咱们做一些试验吧。

为测试服务端的超时，假如有这么一个服务端接口，什么都不干只休眠 10 分钟：

@PostMapping("/server")
public void server() throws InterruptedException {
    // 睡眠 10 分钟
    TimeUnit.MINUTES.sleep(10);
}

首先，定义一个 Feign 来调用这个接口：

@FeignClient(name = "clientsdk")
public interface Client {@PostMapping("/feignandribbon/server")
    void server();}

而后，通过 Feign Client 进行接口调用：

@GetMapping("client")
public void timeout() {long begin=System.currentTimeMillis();
    try{client.server();
    }catch (Exception ex){log.warn("执行耗时：{}ms 谬误：{}", System.currentTimeMillis() - begin, ex.getMessage());
    }
}

在配置文件仅指定服务端地址的状况下：

clientsdk.ribbon.listOfServers=localhost:45678

后果如下：

[15:40:16.094] [http-nio-45678-exec-3] [WARN] [o.g.t.c.h.f.FeignAndRibbonController    :26] - 执行耗时：1007ms 谬误：Read timed out executing POST http://clientsdk/feignandribbon/server

从这个输入中，咱们能够失去论断一，默认状况下 Feign 的读取超时是 1 秒，如此短的读取超时算是坑点一。

咱们来剖析一下源码。关上 RibbonClientConfiguration 类后，会看到 DefaultClientConfigImpl 被创立进去之后，ReadTimeout 和 ConnectTimeout 被设置为 1 s：

**
 * Ribbon client default connect timeout.
 */

public static final int DEFAULT_CONNECT_TIMEOUT = 1000;

/**
 * Ribbon client default read timeout.
 */
public static final int DEFAULT_READ_TIMEOUT = 1000;

@Bean
@ConditionalOnMissingBean
public IClientConfig ribbonClientConfig() {DefaultClientConfigImpl config = new DefaultClientConfigImpl();
   config.loadProperties(this.name);
   config.set(CommonClientConfigKey.ConnectTimeout, DEFAULT_CONNECT_TIMEOUT);
   config.set(CommonClientConfigKey.ReadTimeout, DEFAULT_READ_TIMEOUT);
   config.set(CommonClientConfigKey.GZipPayload, DEFAULT_GZIP_PAYLOAD);

   return config;
}

如果要批改 Feign 客户端默认的两个全局超时工夫，你能够设置 feign.client.config.default.readTimeout 和 feign.client.config.default.connectTimeout 参数：

feign.client.config.default.readTimeout=3000
feign.client.config.default.connectTimeout=3000

可见，3 秒读取超时失效了。留神：这里有一个大坑，如果你心愿只批改读取超时，可能会只配置这么一行：

feign.client.config.default.readTimeout=3000

测试一下你就会发现，这样的配置是无奈失效的！

论断二，也是坑点二，如果要配置 Feign 的读取超时，就必须同时配置连贯超时，能力失效。

关上 FeignClientFactoryBean 能够看到，只有同时设置 ConnectTimeout 和 ReadTimeout，Request.Options 才会被笼罩：

if (config.getConnectTimeout() != null && config.getReadTimeout() != null) {builder.options(new Request.Options(config.getConnectTimeout(),
         config.getReadTimeout()));
}

更进一步，如果你心愿针对独自的 Feign Client 设置超时工夫，能够把 default 替换为 Client 的 name：

feign.client.config.default.readTimeout=3000
feign.client.config.default.connectTimeout=3000
feign.client.config.clientsdk.readTimeout=2000
feign.client.config.clientsdk.connectTimeout=2000

能够得出 论断三，独自的超时能够笼罩全局超时，这合乎预期，不算坑：

[15:45:51.708] [http-nio-45678-exec-3] [WARN] [o.g.t.c.h.f.FeignAndRibbonController    :26] - 执行耗时：2006ms 谬误：Read timed out executing POST http://clientsdk/feignandribbon/server

论断四，除了能够配置 Feign，也能够配置 Ribbon 组件的参数来批改两个超时工夫。这里的坑点三是，参数首字母要大写，和 Feign 的配置不同。

ribbon.ReadTimeout=4000
ribbon.ConnectTimeout=4000

能够通过日志证实参数失效：

[15:55:18.019] [http-nio-45678-exec-3] [WARN] [o.g.t.c.h.f.FeignAndRibbonController    :26] - 执行耗时：4003ms 谬误：Read timed out executing POST http://clientsdk/feignandribbon/server

最初，咱们来看看同时配置 Feign 和 Ribbon 的参数，最终谁会失效？如下代码的参数配置：

clientsdk.ribbon.listOfServers=localhost:45678
feign.client.config.default.readTimeout=3000
feign.client.config.default.connectTimeout=3000
ribbon.ReadTimeout=4000
ribbon.ConnectTimeout=4000

日志输入证实，最终失效的是 Feign 的超时：

[16:01:19.972] [http-nio-45678-exec-3] [WARN] [o.g.t.c.h.f.FeignAndRibbonController    :26] - 执行耗时：3006ms 谬误：Read timed out executing POST http://clientsdk/feignandribbon/server

论断五，同时配置 Feign 和 Ribbon 的超时，以 Feign 为准。这有点反直觉，因为 Ribbon 更底层所以你会感觉后者的配置会失效，但其实不是这样的。

在 LoadBalancerFeignClient 源码中能够看到，如果 Request.Options 不是默认值，就会创立一个 FeignOptionsClientConfig 代替原来 Ribbon 的 DefaultClientConfigImpl，导致 Ribbon 的配置被 Feign 笼罩：

IClientConfig getClientConfig(Request.Options options, String clientName) {
   IClientConfig requestConfig;
   if (options == DEFAULT_OPTIONS) {requestConfig = this.clientFactory.getClientConfig(clientName);
   } else {requestConfig = new FeignOptionsClientConfig(options);
   }
   return requestConfig;
}

但如果这么配置最终失效的还是 Ribbon 的超时（4 秒），这容易让人产生 Ribbon 笼罩了 Feign 的错觉，其实这还是因为坑二所致，独自配置 Feign 的读取超时并不能失效：

clientsdk.ribbon.listOfServers=localhost:45678
feign.client.config.default.readTimeout=3000
feign.client.config.clientsdk.readTimeout=2000
ribbon.ReadTimeout=4000

3、Ribbon 会主动重试申请，理解吗？

一些 HTTP 客户端往往会内置一些重试策略，其初衷是好的，毕竟因为网络问题导致丢包尽管频繁但持续时间短，往往重试下第二次就能胜利，但肯定要小心这种自作主张是否合乎咱们的预期。

之前遇到过一个短信反复发送的问题，但短信服务的调用方用户服务，重复确认代码里没有重试逻辑。那问题到底出在哪里了？咱们来重现一下这个案例。

首先，定义一个 Get 申请的发送短信接口，外面没有任何逻辑，休眠 2 秒模仿耗时：

@RestController
@RequestMapping("ribbonretryissueserver")
@Slf4j
public class RibbonRetryIssueServerController {@GetMapping("sms")
    public void sendSmsWrong(@RequestParam("mobile") String mobile, @RequestParam("message") String message, HttpServletRequest request) throws InterruptedException {
        // 输入调用参数后休眠 2 秒
        log.info("{} is called, {}=>{}", request.getRequestURL().toString(), mobile, message);
        TimeUnit.SECONDS.sleep(2);
    }
}

配置一个 Feign 供客户端调用：

@FeignClient(name = "SmsClient")
public interface SmsClient {@GetMapping("/ribbonretryissueserver/sms")
    void sendSmsWrong(@RequestParam("mobile") String mobile, @RequestParam("message") String message);
}

Feign 外部有一个 Ribbon 组件负责客户端负载平衡，通过配置文件设置其调用的服务端为两个节点：

SmsClient.ribbon.listOfServers=localhost:45679,localhost:45678

编写一个客户端接口，通过 Feign 调用服务端：

@RestController
@RequestMapping("ribbonretryissueclient")
@Slf4j
public class RibbonRetryIssueClientController {
    @Autowired
    private SmsClient smsClient;
    @GetMapping("wrong")
    public String wrong() {log.info("client is called");
        try{
            // 通过 Feign 调用发送短信接口
            smsClient.sendSmsWrong("13600000000", UUID.randomUUID().toString());
        } catch (Exception ex) {
            // 捕捉可能呈现的网络谬误
            log.error("send sms failed : {}", ex.getMessage());
        }
        return "done";
    }
}

在 45678 和 45679 两个端口上别离启动服务端，而后拜访 45678 的客户端接口进行测试。因为客户端和服务端控制器在一个利用中，所以 45678 同时表演了客户端和服务端的角色。

在 45678 日志中能够看到，29 秒时客户端收到申请开始调用服务端接口发短信，同时服务端收到了申请，2 秒后（留神比照第一条日志和第三条日志）客户端输入了读取超时的错误信息：

[12:49:29.020] [http-nio-45678-exec-4] [INFO] [c.d.RibbonRetryIssueClientController:23] - client is called
[12:49:29.026] [http-nio-45678-exec-5] [INFO] [c.d.RibbonRetryIssueServerController:16] - http://localhost:45678/ribbonretryissueserver/sms is called, 13600000000=>a2aa1b32-a044-40e9-8950-7f0189582418
[12:49:31.029] [http-nio-45678-exec-4] [ERROR] [c.d.RibbonRetryIssueClientController:27] - send sms failed : Read timed out executing GET http://SmsClient/ribbonretryissueserver/sms?mobile=13600000000&message=a2aa1b32-a044-40e9-8950-7f0189582418

而在另一个服务端 45679 的日志中还能够看到一条申请，30 秒时收到申请，也就是客户端接口调用后的 1 秒：

[12:49:30.029] [http-nio-45679-exec-2] [INFO] [c.d.RibbonRetryIssueServerController:16] - http://localhost:45679/ribbonretryissueserver/sms is called, 13600000000=>a2aa1b32-a044-40e9-8950-7f0189582418

客户端接口被调用的日志只输入了一次，而服务端的日志输入了两次。尽管 Feign 的默认读取超时工夫是 1 秒，但客户端 2 秒后才呈现超时谬误。显然，这阐明 客户端自作主张进行了一次重试，导致短信反复发送。

翻看 Ribbon 的源码能够发现，MaxAutoRetriesNextServer 参数默认为 1，也就是 Get 申请在某个服务端节点呈现问题（比方读取超时）时，Ribbon 会主动重试一次：

// DefaultClientConfigImpl
public static final int DEFAULT_MAX_AUTO_RETRIES_NEXT_SERVER = 1;
public static final int DEFAULT_MAX_AUTO_RETRIES = 0;

// RibbonLoadBalancedRetryPolicy
public boolean canRetry(LoadBalancedRetryContext context) {HttpMethod method = context.getRequest().getMethod();
   return HttpMethod.GET == method || lbContext.isOkToRetryOnAllOperations();}

@Override
public boolean canRetrySameServer(LoadBalancedRetryContext context) {return sameServerCount < lbContext.getRetryHandler().getMaxRetriesOnSameServer()
         && canRetry(context);

}

@Override
public boolean canRetryNextServer(LoadBalancedRetryContext context) {

   // this will be called after a failure occurs and we increment the counter
   // so we check that the count is less than or equals to too make sure
   // we try the next server the right number of times
   return nextServerCount <= lbContext.getRetryHandler().getMaxRetriesOnNextServer()
         && canRetry(context);
}

解决办法有两个：

  • 一是，把发短信接口从 Get 改为 Post。其实，这里还有一个 API 设计问题，有状态的 API 接口不应该定义为 Get。依据 HTTP 协定的标准，Get 申请用于数据查问，而 Post 才是把数据提交到服务端用于批改或新增。抉择 Get 还是 Post 的根据，应该是 API 的行为，而不是参数大小。这里的一个误区是，Get 申请的参数蕴含在 Url QueryString 中，会受浏览器长度限度，所以一些同学会抉择应用 JSON 以 Post 提交大参数，应用 Get 提交小参数。

  • 二是，将 MaxAutoRetriesNextServer 参数配置为 0，禁用服务调用失败后在下一个服务端节点的主动重试。在配置文件中增加一行即可：

    ribbon.MaxAutoRetriesNextServer=0

看到这里，你感觉问题出在用户服务还是短信服务呢？

在我看来，单方都有问题。就像之前说的，Get 申请应该是无状态或者幂等的，短信接口能够设计为反对幂等调用的；而用户服务的开发同学，如果对 Ribbon 的重试机制有所理解的话，或者就能在排查问题上少走些弯路。

4、并发限度了爬虫的抓取能力

除了超时和重试的坑，进行 HTTP 申请调用还有一个常见的问题是，并发数的限度导致程序的解决能力上不去。

我之前遇到过一个爬虫我的项目，整体爬取数据的效率很低，减少线程池数量也杯水车薪，只能堆更多的机器做分布式的爬虫。当初，咱们就来模仿下这个场景，看看问题出在了哪里。

假如要爬取的服务端是这样的一个简略实现，休眠 1 秒返回数字 1：

@GetMapping("server")
public int server() throws InterruptedException {TimeUnit.SECONDS.sleep(1);
    return 1;
}

爬虫须要屡次调用这个接口进行数据抓取，为了确保线程池不是并发的瓶颈，咱们应用一个没有线程下限的 newCachedThreadPool 作为爬取工作的线程池（再次强调，除非你十分分明本人的需要，否则个别不要应用没有线程数量下限的线程池），而后应用 HttpClient 实现 HTTP 申请，把申请工作循环提交到线程池解决，最初期待所有工作执行实现后输入执行耗时：

private int sendRequest(int count, Supplier<CloseableHttpClient> client) throws InterruptedException {

    // 用于计数发送的申请个数
    AtomicInteger atomicInteger = new AtomicInteger();

    // 应用 HttpClient 从 server 接口查问数据的工作提交到线程池并行处理
    ExecutorService threadPool = Executors.newCachedThreadPool();

    long begin = System.currentTimeMillis();
    IntStream.rangeClosed(1, count).forEach(i -> {threadPool.execute(() -> {try (CloseableHttpResponse response = client.get().execute(new HttpGet("http://127.0.0.1:45678/routelimit/server"))) {atomicInteger.addAndGet(Integer.parseInt(EntityUtils.toString(response.getEntity())));
            } catch (Exception ex) {ex.printStackTrace();
            }
        });
    });

    // 等到 count 个工作全副执行结束
    threadPool.shutdown();
    threadPool.awaitTermination(1, TimeUnit.HOURS);
    log.info("发送 {} 次申请，耗时 {} ms", atomicInteger.get(), System.currentTimeMillis() - begin);
    return atomicInteger.get();}

首先，应用默认的 PoolingHttpClientConnectionManager 结构的 CloseableHttpClient，测试一下爬取 10 次的耗时：

static CloseableHttpClient httpClient1;

static {httpClient1 = HttpClients.custom().setConnectionManager(new PoolingHttpClientConnectionManager()).build();}

@GetMapping("wrong")
public int wrong(@RequestParam(value = "count", defaultValue = "10") int count) throws InterruptedException {return sendRequest(count, () -> httpClient1);
}

尽管一个申请须要 1 秒执行实现，但咱们的线程池是能够扩张应用任意数量线程的。按道理说，10 个申请并发解决的工夫根本相当于 1 个申请的解决工夫，也就是 1 秒，但日志中显示理论耗时 5 秒：

[12:48:48.122] [http-nio-45678-exec-1] [INFO] [o.g.t.c.h.r.RouteLimitController        :54] - 发送 10 次申请，耗时 5265 ms

查看 PoolingHttpClientConnectionManager 源码，能够留神到有两个重要参数：

  • defaultMaxPerRoute=2，也就是同一个主机 / 域名的最大并发申请数为 2。咱们的爬虫须要 10 个并发，显然是默认值太小限度了爬虫的效率。
  • maxTotal=20，也就是所有主机整体最大并发为 20，这也是 HttpClient 整体的并发度。目前，咱们申请数是 10 最大并发是 10，20 不会成为瓶颈。举一个例子，应用同一个 HttpClient 拜访 10 个域名，defaultMaxPerRoute 设置为 10，为确保每一个域名都能达到 10 并发，须要把 maxTotal 设置为 100。
public PoolingHttpClientConnectionManager(

    final HttpClientConnectionOperator httpClientConnectionOperator,
    final HttpConnectionFactory<HttpRoute, ManagedHttpClientConnection> connFactory,
    final long timeToLive, final TimeUnit timeUnit) {

    ...    
    this.pool = new CPool(new InternalConnectionFactory(this.configData, connFactory), 2, 20, timeToLive, timeUnit);
   ...
} 

public CPool(

        final ConnFactory<HttpRoute, ManagedHttpClientConnection> connFactory,
        final int defaultMaxPerRoute, final int maxTotal,
        final long timeToLive, final TimeUnit timeUnit) {...}}

HttpClient 是 Java 十分罕用的 HTTP 客户端，这个问题经常出现。你可能会问，为什么默认值限度得这么小。

其实，这不能齐全怪 HttpClient，很多晚期的浏览器也限度了同一个域名两个并发申请。对于同一个域名并发连贯的限度，其实是 HTTP 1.1 协定要求的，这里有这么一段话：

Clients that use persistent connections SHOULD limit the number of simultaneous connections that they maintain to a given server. A single-user client SHOULD NOT maintain more than 2 connections with any server or proxy. A proxy SHOULD use up to 2*N connections to another server or proxy, where N is the number of simultaneously active users. These guidelines are intended to improve HTTP response times and avoid congestion.

HTTP 1.1 协定是 20 年前制订的，当初 HTTP 服务器的能力强很多了，所以有些新的浏览器没有齐全听从 2 并发这个限度，放开并发数到了 8 甚至更大。如果须要通过 HTTP 客户端发动大量并发申请，不论应用什么客户端，请务必确认客户端的实现默认的并发度是否满足需要。

既然晓得了问题所在，咱们就尝试申明一个新的 HttpClient 放开相干限度，设置 maxPerRoute 为 50、maxTotal 为 100，而后批改一下方才的 wrong 办法，应用新的客户端进行测试：

httpClient2 = HttpClients.custom().setMaxConnPerRoute(10).setMaxConnTotal(20).build();

输入如下，10 次申请在 1 秒左右执行实现。能够看到，因为放开了一个 Host 2 个并发的默认限度，爬虫效率失去了大幅晋升：

发送 10 次申请，耗时 1023 ms

5、总结

明天，我和你分享了 HTTP 调用最常遇到的超时、重试和并发问题。

连贯超时代表建设 TCP 连贯的工夫，读取超时代表了期待远端返回数据的工夫，也包含远端程序处理的工夫。在解决连贯超时问题时，咱们要搞清楚连的是谁；在遇到读取超时问题的时候，咱们要综合思考上游服务的服务规范和本人的服务规范，设置适合的读取超时工夫。此外，在应用诸如 Spring Cloud Feign 等框架时务必确认，连贯和读取超时参数的配置是否正确失效。

对于重试，因为 HTTP 协定认为 Get 申请是数据查问操作，是无状态的，又思考到网络呈现丢包是比拟常见的事件，有些 HTTP 客户端或代理服务器会主动重试 Get/Head 申请。如果你的接口设计不反对幂等，须要敞开主动重试。但，更好的解决方案是，听从 HTTP 协定的倡议来应用适合的 HTTP 办法。

最初咱们看到，包含 HttpClient 在内的 HTTP 客户端以及浏览器，都会限度客户端调用的最大并发数。如果你的客户端有比拟大的申请调用并发，比方做爬虫，或是表演相似代理的角色，又或者是程序自身并发较高，如此小的默认值很容易成为吞吐量的瓶颈，须要及时调整。

本文由 mdnice 多平台公布

退出移动版